换用更短的变量名这种会不会太短期和牺牲可维护性了…
我有几个长期的建议:
1.引擎转向函数式编程以利于 tree-shaking 或者自研 tree-shaking 算法
这个方法应该是所有治本的方法(比如进行压缩就是治标,删除无用代码就是治本)中理论效果最好的,而且是纯自动的。
比如在理想情况下,如果用户只使用了 audio.play
方法,那么 stop
、pause
、resume
等方法的代码都可以自动剔除,这个程度是任何方法都比不上的。
之所以要函数式是因为 JavaScript 的动态性,在现在的 tree-shaking
实现下,class
的所有成员,无论是否使用都不能被剔除,并且也不能被压缩混淆库自动处理长名称。
当然这还是要在不影响用户体验的情况下去做,暴露给用户的那么该是类还是类。
除了转向函数式,我们可以自研 tree-shaking 算法,做一些理想化的假设,比如用户永远不会动态访问某个类成员,这样就可以对大部分情况进行静态分析剔除了。
看一下竞品的 Managed Stripping Level,实际用起来,大部分时候甚至需要自己去标记哪些代码是不用剔除的,所以我们也不用追求完美。
可以让用户标记哪些类或者方法是保留的,并且给出几个剔除等级来执行不同程度的剔除。
2.无论引擎还是用户代码,都彻底地模块化
我看到在去年 10 月的时候,引擎还在做分成多个子 package 的模块化工作,现在不继续做了吗?
现在 Cocos Creator 有一个很大的问题,现在的情况是引擎把用户代码作为一整个模块进行处理,只要是在项目里的代码就肯定进行立即的隐式导入。
这完全发挥不出 ESM 可以静态分析进行代码剔除的能力,在未来,也不可能兼容 JavaScript 的众多模块相关的提案。
我强烈建议尽快着手处理这个问题,除了引擎代码,其实用户代码才是在不断迭代后最容易冗余的,且对加载等其它方面都有好处。
3.使功能裁剪做得更加细致
这也是为什么要彻底模块化,因为模块化后这部分显然是可以通过自动生成工具来完成的,要多细致就能有多细致。
那有了 tree-shaking 的语句级别的剔除机制,为什么还需要手动勾选?
- 一个是可以保证不引入某些模块,比如我项目不想用 Button,所以去掉勾选,如果意外用到了就警告或者其它什么,这些都是可以自动做的。
- 一个是为了以后的热更新,现在不使用,不代表在项目不断迭代后不会使用,所以我可以选择强行保留某个模块的代码。
4.自动名称优化
彻底模块化之后显然可以进行静态分析了,那么我们可以通过自研工具自动缩短用户未使用或者不会被动态使用的接口名称,和其它更多可能的优化,比手动不是好多了吗?也不会影响维护性。
5.一些现代的东西
虽然我们是做游戏的,好像跟 Web 前端技术并没什么关系,但是我们共用着一个语言和生态。
在 Web 前端开发中,除了执行性能确实可以说几乎不关注,但其它很多方面都和我们有一样的需求,现有的解决方案也很值得我们借鉴和学习,根本就不需要自己闭门造车:
- 预览与打包速度:Vite、RSPack、Mako 等等…
- 包体和启动速度:ESM 和 tree-shaking、defer import 提案、动态代码分块且自动加载 等等…
- 对于 Wasm 代码,还有 emscripten module-splitting 这类工具可以借鉴,这也是竞品的小游戏代码分包所用的东西。