【引擎组】引擎包体优化信息收集

换用更短的变量名这种会不会太短期和牺牲可维护性了…

我有几个长期的建议:

1.引擎转向函数式编程以利于 tree-shaking 或者自研 tree-shaking 算法

这个方法应该是所有治本的方法(比如进行压缩就是治标,删除无用代码就是治本)中理论效果最好的,而且是纯自动的。

比如在理想情况下,如果用户只使用了 audio.play 方法,那么 stoppauseresume 等方法的代码都可以自动剔除,这个程度是任何方法都比不上的。

之所以要函数式是因为 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 这类工具可以借鉴,这也是竞品的小游戏代码分包所用的东西。
11赞

每次的功能都是,能搞,但只能搞一点点:pinching_hand:🏻

可能每次烂尾都是因为人走茶凉 :sneezing_face:

1赞

bundle支持压缩配置啊

以上的一些建议我们都会认真考虑,会分优先级逐步优化。

bundle支持单独生成md5版本

能否拆分动画模块为单独的插件,例如帧动画、缓动动画、骨骼动画;这样可以应用于H5的动画开发,相对于css动画而言,可以减少开发工作量、提升性能、丰富动画复杂度;

Prefab构建时能否编译转化为二进制格式, 自定义格式或采用Flatbuffer

2赞

真正的大佬

+1
这样加载会快很多

第三方js插件脚本可以通过设置成bundle,供开发者延迟加载吗?好像预览的时候不可以,时间久了有点忘了

第二点手写缩短变量名是很笨的办法。其实意图很明显,让私有成员名字更短,因为外部引用不到。但是做法不好,降低了调试的可读性。比较好的处理方式是在编译期间扫描ptivate成员然后替换类里面的引用。

1赞

虽然不是包体优化建议,但是这个Bundle在开发阶段加载逻辑不一样的问题确实难受,希望引擎组可以让其逻辑一致。

KYT5NW1PA98(UPQS7$WH3T
包体中包含internal中散列的图可否合并一下

默认模版搞个helloworld运行微信小程序的时候,最好构建完启动就用,不需要自己再优化折腾配置半天还跑不了真机

能不能优化一下打包,,明明啥都没改,但是打包出来的文件md5都变了。。

也小很多s

这个有复现的 demo 和测试流程信息吗?我们每个版本都有做这类型的测试,但可能没有覆盖到你遇到的情况。

构建速度是不是也可以优化下, :rofl:不过按优先级的话还是启动速度>包体>构建速度