缩小软件体积

[LuSrackhall]

众所周知, electron项目的打包体积大是不可避免的。

并且由于本人只是一个电气行业的业余开发人员, 除了短暂半年的外包经历, 并没有太多开发方面的相关经验, 贸然对打包方面深入了解只会占用自己本就不多的业余时间, 且最主要的是我认为----对一个功能都不健全的应用浪费时间做优化是得不偿失的<不论是体积还是性能上的优化>, 因此在1.0.0版本之前, 暂时不会在打包体积和性能优化上面下太多功夫。

直到我认为这个应用真的达到标准, 或者能够帮助到大多数人时。我才会抽出时间进行这方面的尝试, 否则我仍旧会以实现功能优先。

当然, 我在本应用开始之前的其它小项目中, 有过框架选型的经历, 比如tauri和wails, 由于它们依赖与系统已经安装的webview, 因此打包体积会非常的小。 但是开发体验一言难尽

• 比如生态都不如electron, 相比之下
  • tauri生态稍微好点, 但构建时间太长, 影响开发体验。<可能是因为rust的原因, 每次构建都要很长时间>
  • wails虽然构建时间很短<甚至比electron快>, 但生态太差, 社区交流不太友好, 甚至连官方应该支持的很多功能都非常欠缺。(比如当时连最基础的多窗口功能都没有, 虽然半年前已经在预览版本中实现了), 在ipc通信方面, 虽然实现了go和前端的bind, 但反射的方式太浪费资源而且生成的时间太久了<这个时间我可以加到构建时间里吧, 毕竟也影响开发体验了, 不过wails3主要就是解决这一问题的>, 但我仍认为其还有一段路要走。

由于个人业余时间不多, 特别是能力偏弱, 因此还是比较偏向依赖已有生态来实现功能的, 因此electron成了本项目的唯一优先选择。因为不论需要实现的哪个功能, 在electron的大生态中一定可以做到最短时间内完成, 而不需要动太多的脑子。

不过, 在体积和性能优化方面, 请相信我并没有完全的放下不管, 至少这个issue就说明了这一点, 此外当本项目的进展到了1.0.0后

• 我会着手进一步研究electron的打包机制和配置, 以尽可能获得更小的体积。
• 如果那是wails3已经正式发版(或是有更好的有关go代替electron的方案或项目出现), 我会重新评估它们, 甚至不排除将本项目迁移框架, 或者两个框架下的开发同时进行。

  以在electron框架中确保功能优先的情况下, 还能在wails3<或其它更好>框架中使打包体积优化到最小<即使引入更多的开发成本>。

最后, 如果本项目对您提供了帮助, 请 Star 本项目。

如果您还愿意提供一些帮助, 那么可以是这些方面:

• 对本项目进行赞助<这很重要>。
• 协助本项目issues的处理, 给本项目pr。
• 将本项目介绍给朋友或是进行其它方式的推荐/推广。