感觉你说的就是u的ab
哈哈哈，向标杆学习
缩短 属性 成员变量 的名称这种事情 我们的项目也有做.
但是不会修改源码里的内容 否则代码的可读性可就太弱了.
我们的作法是:
先用正常流程编译.
然后 用 ast工具(我们用的 @babel/parser’ ) 对编译后的js文件进行解析, 提取出所有需要"缩短名称"的变量(函属性 成员变量 方法 函数 等等).
然后根据配置文件 对这些内容进行重命名.然后从ast重新生成新的代码.
配置文件也是机器自动生成的 然后人工后期微调.
我们这么做的缺点是 “用正常流程编译” 后生成的 source-map 不再适用于我们二次处理的新js了. 我们用其他方式间接解决了这个问题(不太好). 但是理论上我们也可以对source-map做二次处理的. 只是目前团队还没时间研究source-map的修改和二次生成.
3赞
lz4、http range、streaming
1赞
后续会加入 bundle zip 功能。但是引擎不太适合做你说的这种方案。是否 zip，哪些 zip 是留给游戏项目自己处理。引擎也会研究模块的延迟加载。
通过 ast 处理后的 js 定位到 ts 我目前是这样做的：
- ast generator 的时候输出 sourceMap
- 根据 行列 输入信息用 source-map 包解析上边的 sourceMap 文件，得到 行、列、source
- 重复上边，得到 ts 行列，然后 vscode goto
其实可以把json，图片，声音，spine资源进行压缩成为一个zip包，类似u3d的ab包一样，加载的时候直接从内存一一还原，已在多个项目使用（2.4.x + 3.8.x）。游戏体量，资源大小在1G，总文件数量4w+，平台：web + 小游戏 + 原生（同一套）。 在微信小游戏，单纯利用 jszip 压缩整合 import 目录下的json文件，性能也能提升30%+(文件数减少2w+，仅有250+文件)。native资源，图片采用astc(不支持的平台使用png，jpg)，如 atc 5x4，2048 * 1024 （原图 1890k， astc 1679k，压缩 666k），下载速度大大提升，解压耗时大概在30-50ms，同理.ccon那些也一样可以进行性压缩处理，还方便自定义加密。至于代码，可以编译成bytecode（可参考 [原创] 给"某音"的js虚拟机写一个编译器-Android安全-看雪-安全社区|安全招聘|kanxue.com
不过内存管理不好，内存会炸掉，处理好，性能提升飞跃
6赞
66666.。
非常酷！
官方不是说小游戏不支持吗？我以为不能实现呢
官方是不支持，不过代码开源，自己动手魔改一下就行了，只要把数据解析还原为引擎需要的数据就行了。然后再写个配套工具，build完运行一下就OK了
如果是在浏览器上，这个大 zip 包的资源要一直缓存住？如果是，那不是内存会比散文件模式高很多？
除了包体，插件生态什么时候也能完善下，插件生态架子搭好了能事半功倍的发挥社区的力量
原来是字面的意思啊，这。。。。谁提出来的啊。我以为是有什么深层次的意思。
原生平台热更怎么弄？
每次都重新下载整个zip吗？？？ 
如果bundle包很小，把整个资源合成一个zip，倒也没什么，太大就不行了，不然每次更新都是等于下了一个整包。举个例子，可以按照文件夹来压缩，如import，native目录来，压缩成import/01.xxx.zip，c1.xxx.zip等等，native也一样，热更的时候下载有差异的文件就行了，不会很大。至于怎么压缩，也可以按照游戏目录结构来，假如你一个目录就是一个功能，那就把它压成一个zip，换了图，就热更整个。如果想像处理得更复杂精细一点，母包压缩，热更就更散资源就行了，至于怎么处理，全看你怎么去管理压缩这个配置。我这里的做法是，把压缩对应的信息都写在bundle的config里面，主要记录zip包md5，热更走的就是官方那一套。至于怎么拿那些信息，build出来后，config 有path，有uuid字段，写个工具解析一下，就可以得到文件原有路径，uuid，版本信息了，想怎么压缩都可以。
小游戏可以热更新吗
可以，不过脚本得另开僻径，这里不宜多说，原理可参考
https://zhuanlan.zhihu.com/p/539725089?utm_id=0
https://bbs.kanxue.com/thread-261414.html
也还有个办法，像u3d那样，开个wasm虚拟机