优化打包结构

[PastGone]

在arch linux上跑起来了。
不过跑起来的过程中并不顺利。
有以下几个建议。

• 压缩包的层数太多了，建议缩减
• linux打包。可以不带jre。让用户自己装。
• 原来的打包结构下，jar包分了太多，实际上一个jar包就够了。

[PastGone]

哦，对了，还有可以给linux的包添加一个启动脚本。
大概类似于下面这样。通过 -Djava.library.path=lib/natives
可以指定原生库的位置。

#!/bin/bash
cd "$(dirname "$0")"
java -Djava.library.path=lib/natives -jar RWX-1.0.0-all.jar "$@"

我对JAVA，kotlin的掌握很少。vibe coding的时候吧。做的变更又很乱，就不放具体代码献丑了。

[PastGone]

再再再补充一下。
我去看了一下，mindstry。
他的打包结构，事实上他是把所有的原生厍，素材也打包进jar里。
只是不带jre而已。
压缩的好的话，原生库其实也就几兆大小。
通用性却大大增强，一个文件跑桌面全平台。

[eam2539]

1.gradle任务只有一层打包，你说的应该是actions构建的产物吧，那是workflow自己打包的，可以改，但没必要。release发行版是正常的。
2.gradle任务:assembleDist/distTar/dist/Zip，不带jre
3.我个人不喜欢全部依赖都塞一起的fat jar。而且面向用户的产物主要是用jpackage打包的产物。不过fat jar确实更适合分发。之后可以考虑增加fat jar的gradle任务

[eam2539]

哦，对了，还有可以给linux的包添加一个启动脚本。
大概类似于下面这样。通过 -Djava.library.path=lib/natives
可以指定原生库的位置。

#!/bin/bash
cd "$(dirname "$0")"
java -Djava.library.path=lib/natives -jar RWX-1.0.0-all.jar "$@"

我对JAVA，kotlin的掌握很少。vibe coding的时候吧。做的变更又很乱，就不放具体代码献丑了。

distTar/distZip/assembleDist 打包的产物自带windows启动脚本和linux启动程序。
linux平台:

./bin/RWX

[PastGone]

1.gradle任务只有一层打包，你说的应该是actions构建的产物吧，那是workflow自己打包的，可以改，但没必要。release发行版是正常的。
2.gradle任务:assembleDist/distTar/dist/Zip，不带jre
3.我个人不喜欢全部依赖都塞一起的fat jar。而且面向用户的产物主要是用jpackage打包的压缩包。不过fat jar确实更适合分发。之后可以考虑增加fat jar的gradle任务

• 这个我还真没注意。我只看了一下workflow action跑出来的那个包。不过这个workflow构建产物好像还有个问题。那就是字体文件，占的体积太大了。差不多占了一半，还多的大。
  另外说起release，请问什么时候才能有他的正式版release呢?

[eam2539]

1.gradle任务只有一层打包，你说的应该是actions构建的产物吧，那是workflow自己打包的，可以改，但没必要。release发行版是正常的。
2.gradle任务:assembleDist/distTar/dist/Zip，不带jre
3.我个人不喜欢全部依赖都塞一起的fat jar。而且面向用户的产物主要是用jpackage打包的压缩包。不过fat jar确实更适合分发。之后可以考虑增加fat jar的gradle任务

• 这个我还真没注意。我只看了一下workflow action跑出来的那个包。不过这个workflow构建产物好像还有个问题。那就是字体文件，占的体积太大了。差不多占了一半，还多的大。
  另外说起release，请问什么时候才能有他的正式版release呢?

我去看了一下，字体文件体积没有问题吧，就是60mb。
关于release发行版，主要是因为rw的跨平台做的很烂，android端适配很费力。在没有跨平台的基础上写的话，很多feature都是白写。所以我打算用Kool引擎重写底层渲染和统一ui。
kool分支复刻完所有行为就会发布Release.(随缘)

[PastGone]

1.gradle任务只有一层打包，你说的应该是actions构建的产物吧，那是workflow自己打包的，可以改，但没必要。release发行版是正常的。
2.gradle任务:assembleDist/distTar/dist/Zip，不带jre
3.我个人不喜欢全部依赖都塞一起的fat jar。而且面向用户的产物主要是用jpackage打包的压缩包。不过fat jar确实更适合分发。之后可以考虑增加fat jar的gradle任务

• 这个我还真没注意。我只看了一下workflow action跑出来的那个包。不过这个workflow构建产物好像还有个问题。那就是字体文件，占的体积太大了。差不多占了一半，还多的大。
  另外说起release，请问什么时候才能有他的正式版release呢?

我去看了一下，字体文件体积没有问题吧，就是60mb。
关于release发行版，主要是因为rw的跨平台做的很烂，android端适配很费力。在没有跨平台的基础上写的话，很多feature都是白写。所以我打算用Kool引擎重写底层渲染和统一ui。
kool分支复刻完所有行为就会发布Release.(随缘)

我这里没有表达清楚。
目前含jre的这个包。也就是这个workflow打包出来的Linux zip包。这个包的大小是180兆。解压之后是300兆。
然后我自己fork了一个分支。主要就改了一下打包的相关东西，乱改了一下。然后去掉jre之后。又把多个jar包合一之后。重新打包之后是120兆。压缩包和解压之后都差不多是这个大小。
因为字体是60兆。占到了这个包的一半。
另外这些字体我看了一下，主要是安卓系统的字体。当打包成apk的话时候，实际上也不会带这些字体。
而且这些字体实际上没有什么特殊的（并不是什么艺术字体，既然如此，为什么不使用系统字体呢。
这是完全可行的，而且如此的话，我们只需要60m或70m大小，桌面端就够了。

[eam2539]

1.gradle任务只有一层打包，你说的应该是actions构建的产物吧，那是workflow自己打包的，可以改，但没必要。release发行版是正常的。
2.gradle任务:assembleDist/distTar/dist/Zip，不带jre
3.我个人不喜欢全部依赖都塞一起的fat jar。而且面向用户的产物主要是用jpackage打包的压缩包。不过fat jar确实更适合分发。之后可以考虑增加fat jar的gradle任务

• 这个我还真没注意。我只看了一下workflow action跑出来的那个包。不过这个workflow构建产物好像还有个问题。那就是字体文件，占的体积太大了。差不多占了一半，还多的大。
  另外说起release，请问什么时候才能有他的正式版release呢?

我去看了一下，字体文件体积没有问题吧，就是60mb。
关于release发行版，主要是因为rw的跨平台做的很烂，android端适配很费力。在没有跨平台的基础上写的话，很多feature都是白写。所以我打算用Kool引擎重写底层渲染和统一ui。
kool分支复刻完所有行为就会发布Release.(随缘)

我这里没有表达清楚。 目前含jre的这个包。也就是这个workflow打包出来的Linux zip包。这个包的大小是180兆。解压之后是300兆。 然后我自己fork了一个分支。主要就改了一下打包的相关东西，乱改了一下。然后去掉jre之后。又把多个jar包合一之后。重新打包之后是120兆。压缩包和解压之后都差不多是这个大小。 因为字体是60兆。占到了这个包的一半。 另外这些字体我看了一下，主要是安卓系统的字体。当打包成apk的话时候，实际上也不会带这些字体。 而且这些字体实际上没有什么特殊的（并不是什么艺术字体，既然如此，为什么不使用系统字体呢。 这是完全可行的，而且如此的话，我们只需要60m或70m大小，桌面端就够了。

• 所以打包有啥问题，我没get到
• 当前主分支主要目标是复刻原本rw的外观和行为，所以这些字体就是必需的。

[PastGone]

• 所以打包有啥问题，我没get到
• 当前主分支主要目标是复刻原本rw的外观和行为，所以这些字体就是必需的。

还真是，我去看了一下铁锈
Windows的包其实就是带了这几个字体的。
只不过我个人感觉
采用pc系统字体可以减少包的体积。
另外铁锈原本apk的打包。其实是依赖于安卓系统自己的字体。
但是这些字体在不同的安卓上其实表现也不一定相同。一些厂商为了保持系统整体的一致性可能会对这些东西进行一定修改。
既然如此，那桌面端也没必要硬绑死字体吧。同样使用自带字体不也行吗。
不过这个等到以后再考虑吧。

[eam2539]

• 所以打包有啥问题，我没get到
• 当前主分支主要目标是复刻原本rw的外观和行为，所以这些字体就是必需的。

还真是，我去看了一下铁锈 Windows的包其实就是带了这几个字体的。 只不过我个人感觉 采用pc系统字体可以减少包的体积。 另外铁锈原本apk的打包。其实是依赖于安卓系统自己的字体。 但是这些字体在不同的安卓上其实表现也不一定相同。一些厂商为了保持系统整体的一致性可能会对这些东西进行一定修改。 既然如此，那桌面端也没必要硬绑死字体吧。同样使用自带字体不也行吗。 不过这个等到以后再考虑吧。

原本的代码就是依赖的这些字体，我也懒得改(也没必要改)
而且依赖系统字体不是一个好的习惯，这样可能会导致在不同平台的字体不一致。而且各平台的字体文件获取也很复杂，会引入不必要的复杂性