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

Creator 3.x
#105

别闭门造车了，现代化构建工具用起来！ babel、webpack、vite、rollup、npm等等

5赞
#106

十分同意！！！

#107

目前只有 3.8.0 的版本能打包出可以直接发布微信小游戏（4M 以内），以上的版本都不可以，默认打包出来引擎就超 4M了，需要优先解决这个问题

#108

这个版本打出的包会 <= 380

#109

支持crunch和basis universal纹理超压缩

#110

我怎么感觉原生的feature愈来愈少了…是我的错觉吗

#111

384 里程碑版本了，用了新管线，基于这个，原生上后续更多后效和光追会逐渐迭代

3赞
#112

6，引擎组加油，靠这玩意养家糊口。

#113

谢谢回覆，
喵前辈加入引擎组了吗@@

#114

我是奶茶组的 :stuck_out_tongue_closed_eyes:

1赞
#115

@property(Layout)
oLayout: Layout = null;

有没有人观察过，这个装饰器在构建后的js代码有多少个字节。约是80个左右。
那么一个项目的业务代码里面，有百分之多少是这个装饰器展开的代码量呢？
反正我们的约是10分之1

1赞
#116

希望3.x h5 构建出来的引擎文件继续变小，现在只要基础的部分，也要2m了

#117

等下最新版的包，一定会比 380小

#118

增加个开关，只要打开的话，就会根本代码自动去裁剪引擎，没有打开的话，就需要用户自己去裁剪。
刚需!!! 当然，默认的是关闭的，让需要的人去开~

#119

那个天天修改cocos命名方式的人是不是你

#120

我可没办法代表整个引擎团队，你也可以去看我提交的 PR。你如果是想吐槽这方面的话，建议单独建个帖子。

#121

看我说的看我说的！

#122

做到代码自动裁剪需要做很大调整吧？另外，也很难做到两种并存，这样维护起来很困难。

#123

在构建的时候判断一下就可以了吧，大概~

#124

直接通过脚本依赖没法做到精确。依赖的模块有些是通过场景数据来决定依赖哪些模块的。当然，也可以做到构建时去分析场景数据，自动分析依赖哪些模块，不过这种也不是代码级别的依赖，而是模块级别。所以后续我们要做的第一步是把模块拆得更细些。