共能裁剪
主要占空间的地方：
肥肠不合理
别想了，3.7之后，cocos也只能和unity一样，引擎作为分包了
主要是包含了 wasm 3D 物理，比较大，而且我看 2D 物理也包含了，还有 2D 的粒子和 DragonBones，都不小，考虑进一步剪裁一下不需要的模块
不合理
对于引擎来说，优化空间其实很大，此处只提点自己的一点看法，如雷纯巧
-
Dom，对应的EventTarget、Node、Element… 这一块东西很杂，整体占了也不少包体。但是除了引擎（引擎可能是为了方便纹理加载和CanvasAPI处理统一），外部几乎没开发去操作这个虚拟化的Dom，保留一个document，其他的可以去掉。
-
cocos可以考虑预制体除了json格式以外，增加二进制格式的预制体构建（类似spine），json字符串耗费大量的内存空间，里面有大量的类型定义和字段属性命名，远不如二进制对包体友好。随着引擎功能增强，以后的节点属性只会越来越多。
为什么二进制可以小？ 比如json中一个数字
3.14159265，按UTF8编码字符串保存，占用10个字节，而换成二进制只占4个字节（float32）且只要在精度范围内（注意看上图json中有很多高精度的浮点数）用二进制，在原生上如果内存对齐足够好，可用c++内存映射到结构体，解析都免了，实在不行Probuf借来一把梭。
至于json中铺天盖地的类型定义，可以生成一份全局的id和类型枚举表，其他表直接引用这个id即可。
4赞
是 只能分包了
为什么要勾选物理
把2D物理去掉了，龙骨也去掉了。还是超了4M。。。
我测试过二进制数据格式，可能资源包体会小一些，但是性能并没有提升，因为 JSON 的解析在绝大多数平台上是 C++ 完成的。二进制的话只能用 JS 去解析……
启用 json 合并后，类型定义就会跟着被合并了。如果要再进一步合并，提升到全局对资源的包体是有帮助，但是仍然可能导致内存占用增多、访问 cache miss 加大。而且相当于一启动项目就要对整个项目可能用到的所有类型进行一次加载…… 可能项目启动时间也会受到影响。
相比之下其实提升的幅度远不如项目 JS、图片体积的优化来得强烈。
effect编译成json，贼大。能不能优化呀
有空的话可以考虑加个可选的原生用 C++ 跨平台用 WASM 的二进制格式？
在尝试了，之后会逐步加大 wasm 模块的占比，3.8 会先把 Spine 做成 wasm
1赞
核心底层最好都倾向到c++，性能肯定无压力。
跨平台使用wasm。
就如同unity一样，底层都是c++，c#调用dll的形式。
wasm就是web平台使用的dll。
加油
能把物理引擎放入分包吗？ 游戏在启动的时候，是可以不要物理引擎的。 比将引擎全部放入分包，流程更简单。
Spine 等库，也建议能够作为分包加载。
看一眼internal里面那json文件吧，官方材质一堆没用到的材质占着977kb。这合理吗？
2赞