举个例子来说，比如build后目录下有很多json文件，你把其中某个手工压缩成ZIP， 原json删除 该怎么打包还怎么打包，如果这个文件需要更新 ，那引擎会替你下载并解压这个文件 和非ZIP效果一样 然后剩下的就是你管理每个原文件和对应ZIP文件关系的逻辑问题了
把其中某个手工压缩成ZIP ，这个怎么量化，
修改 version_generator.js，引入ZIP包，批量改
不适用这里吧。 热更包或者bundle包主要是散文件比较多，有些场合这么多文件下载还是比较浪费IO，如果能zip一次下载会比较好。
官方目前asset bundle 不支持zip包方式，只有微信小游戏才支持。其他原生那些基本上就只能自己另外写下载解压来解决这个了。
支持的吧，在仔细看看文档
文档写着的支持类型有zip。 但是实际上只有选择微信小游戏类型才有zip 选项给你支持
刚好做热更，来挖坟，
我看见命令行打包参数compressed，设为true可以支持zip解压，是不是相当于把所有散文件各自打成zip就好了
例如:
assets/ui/a.png —>assets/ui/a.zip
这样这个参数为true就可以生效？散文件浪费io确实有点影响下载速度 zip会快一点把
看下这个参数是不是这个意思，虽然说这样要干预脚本去写一个批量打包成zip 如果能有效果也挺好
我用的2.4.x 命令行打包倒是没写 但是有资料显示有这个compressed参数支持zip解压 能用在native环境吗？是要把每个散落文件打成zip形式吗
是 ZIP可以是对应单文件 也可以是对应目录
对应目录的话不好弄吧，因为可能热更的文件只是单纯某个目录下的一个文件，所以写个脚本把文件夹所有文件(非目录)做成zip
刚才亲自测试后发现把文件打成zip会更新失败，冒出ASSET_UPDATED提示字样后就没下文了 然后我把zip还原回png又可以。不知道是忽略了什么细节
manifest里文件名的后缀 用错了吧
是的，我发现后来我改了，但是发现散文件通过zip方式加载还多了解压步骤，比之前更慢了，因为我只针对目录下的png做了zip测试了下对比两者，对于下载速度更多应该是下载io问题吧 散文件多的情况下无论是png还是Zip都没有本质的下载速度提升，但是如果针对文件目录，那么是不是意味着我得知道热更的这个文件所属目录是谁，把目录打成zip，那为了一个文件的不同得把整个zip下下来 好像又得不偿失 全量热更方案用不用zip好像都有一些缺点
另外补充问一下，如果要把文件夹打成zip，如何去对应文件夹目录下的文件所属文件对应关系，是不是要在version_generator.js里边做文章
改打包流程：
- 打好包内资源后，先复制一份资源，用来准备上传cdn。
- 根据配置规则，对这份上传用资源，某些目录进行打zip，并删除对应散文件。
- 改manifest的generator，对上传用资源进行manifest生成。
判断是zip，就写入compressed。这时候manifest里面就记录这个zip的信息，不用记录对应散文件信息。 - 把生成的manifest 放到包内。连带包内资源打包。
- 把带zip的那份资源，连带manifest上传cdn。
热更流程：
如果有一个文件被修改了，那么该文件所在文件夹zip的md5就会修改。
对比manifest发现该zip被修改，就下载该zip进行解压。
当然最好的方案，既可以仅下载差异，又能下载合并zip。还是我另外一个回帖里面提到过的那个方案：
客户端上传差异列表，由后台服务器进行差异文件压缩成少量zip分发下载。大部分客户端的zip是一样的可以预热。
怎么做到一个文件被修改，这个文件所在文件夹目录打成的对应zip包的md5会被改
这不是明显的嘛，文件内容变了，这个zip文件包含变化的文件，里面内容都变了啊。计算出来md5不就是改了啊。
不知道你有没有理解我的意思，cdn上只有文件夹打成的zip，没有散文件。manifest里面也只有记录zip。
散文件只在打出的包里面有。某个散文件变了，对应文件夹的zip包就要重新打了传上去cdn啊，当然md5就变了。
我描述一下流程
原本通过干预构建过程插入main.js头插入热更代码，然后利用version_generator.js构建的manifest，目前需要对generator进行改造，让散文件对应好所在的文件夹目录，并且顺便把这个目录压缩成zip输出，用大白话说就是改写官方给出的generator进行代码改造对吧
在前面需要再单独写一个脚本，你可以叫它zip_cdn_assets.js。内容是在打包后，进行资源拷贝和zip压缩处理。可以通过读json配置，描述压缩文件夹的规则，哪些要压，哪些不压，哪些压到什么子文件夹层次。
为什么要单独写一个zip_cdn_assets，因为其实这个并不是生成manifest的流程，而是生成上传用cdn资源的流程。当然你要写在一起也可以。
generator确实是要改造，不过其实只需要改一个地方，判断文件是否后缀为zip，并设置compressed标志就可以。
generator处理的资源目录，已经是做好zip的资源了。在这里generator就不知道散文件是哪些了。
这里资源的关键点就是：
- manifest文件只记录zip包不记录散文件。
- 打到包内的资源是散文件 + manifest。
- 上传cdn的资源是zip包 + manifest。
这样热更的时候，下载变化的zip，解压到用户目录，自然就可以覆盖出散文件了。在zip层级对比差异，而不需要在散文件层级进行对比差异。
我感觉已经说的比较清楚了。就不再多描述了。
很清楚 感谢
最后想确认一点，整个方案下来，由于散文件已经被整理成一个个zip，而散文件的变更必然也会导致zip包的md5变更，因此优化了下载io数量，也相当于减少了manifest的对比时间(从单个文件对比变成了文件夹对应zip包的对比)
那么这个方案实际上是不是，用户会为了单个文件更新需要付出两个代价
1.只是费点流量(单个文件导致一整个zip包的下载)
2.因为单个文件的变化，需要把整个目录进行一次解压后，把目录下所有文件重新拷贝到执行目录(因为没有了单个文件的md5变化记录 且这个热更过程是先下载到remote_temp 最后下载完成解压后再拷贝到执行目录)
不谈论优缺点和优化，只是单论付出的代价就这俩是吧
是的，基本上就这2个代价。
如果你按bundle文件夹打zip的话。适当调整分细一点bundle，控制一下大小，应该可以减轻一点代价。