引擎裁剪建议

最好的应该是根据引用代码和组件自动裁剪,而不是用户自己来选择,还容易导致错误裁剪

1赞

384 和 385 都会有 包体压缩的计划,大家的想剔除那些模块可以具体 讨论下

比起这个,我更期待tree shaking,目前自己做这个有点太复杂,改引擎编译方式过于冒险

所以颜色渐变类放3d。2d就不渐变了? :wink:

我觉得这个不现实,官方不会抽出那么多时间去搞这个,能更细化一点设置裁剪就很不错了。

感谢大佬关注小白痛点!
不过确实呀,我想小游戏的开发者对“启动速度””包体大小“比较敏感。
从3.x版本2MB开始,到现在6MB,官方显然是奔着大型游戏引擎去的。
但是我猜测绝大多数的开发者都是小游戏吧,而且很多小白,自己改引擎确实难度太大啦 :rofl:


可以到这边去参与讨论。。

一般我们会提供裁剪的能力,不会自动帮用户去做,来覆盖更多用户的需求。

那要不反过来,像我说的,提供最小化的游戏引擎,其他的以插件形式加入,像uinty那样

为什么自动化裁剪不满足用户的需求?不引用的组件及功能模块就不会被使用?有什么问题?

有的用户,他需要全模块,但是他只有一个壳,通过加载各种bundle去加载各种内容。

自己手动引用一下 U也是这么做的 向行业老大学习才能少走弯路

所以不得不提下unity的自动裁剪,怎么解决这种问题了。哈哈

哈哈哈,向大佬学习~

-0-那就加个判断啊,是否自动裁剪,如果勾上了,没引用到的就全干掉,没勾上,就不管,让用户自己去做裁剪的操作~同意的举手!!!!! :mask:

2赞

自动裁剪其实意义不大,因为即便是web平台,也需要做引擎dll化,也就是公用引擎文件,这种情况下会使用全量包,顶多区分2D版本和3D版本。小游戏平台开启引擎插件也是全量,NA的话也不在乎那个体积。

这个看下像隐藏规则,不明所以的人容易踩坑

可以的话,希望加上资源brotli、zip的压缩选项吧,应该能减少不少体积,和请求数

默认去掉啊,让明白规则的人去操作~

wasm brotli 384有了