经过测试，4G内存realme 4G内存Oppo 8G内存vivo 分别测试官方加载，当包体达到150M左右，第一次安装或者重新安装包，热更临近版本，资源却几乎需要完全对比，而且需要加载很久，看了下LOG主要在复制remote_temp到romote仓库，是什么原因造成，资源变化其实不大
文件数量是多少？
我看调试后台显示
js xxx/466 xxx/12252821
前边的466是文件数量？
实际我对比两个版本改动过的资源其实就几十个图集 是因为依赖关系导致meta都变了么
但是整个包大小才150M 热更速度要半小时起步 还不如直接下包快
cocos的方案，需要全量的在程序运行的时候完全比对，然后一个一个的下载，然后从临时的下载文件复制到可执行的目录。正常复制的过程是看文件数量，大小而定的。我们没有采用他的方案。因为整体性能表现无法达到预期。如果项目比较小可以直接用，项目大的话，比较建议将比对提前到打包的阶段，然后将差异内容打包成zip。这个优化效果非常明显。这边需要注意的是zip包的完整校验。还有大文件zip的流式解压。
2.4.9版本 5年前的手机下载1G热更资源也才2分钟不到，也是拿官方改的
文件数量可以直接通过project.mainfest得知。150M应该有2000多的文件。
你说的是增量更新吗？是命令行打包开启compressed这个参数 然后把差异文件上传 相当于记录者每一个版本的差异文件信息 而每一个版本信息都携带者各自的manifest文件 是这个意思吗？那么是否意味着久远的用户会需要把版本一个个更新上来，又回到了老生常谈的问题
我目前想知道能否依然用官方方案 然后单纯把ab包或者某个文件做成zip 但依然是整个包文件上传 目录结构不变 只是文件名打包成了zip 也可以通过manifest来做对比 但只需要开启compressed参数即可
我初步想法是这样 但不知道支不支持 毕竟下载zip要快那么一丢丢吧
比对的过程很漫长 150M的比对 我也拿5年前的千元机测 oppo A32
另外就是从remote_temp临时文件复制到可执行目录这个过程也蛮久(估计依赖资源改动多) 总体体验下来已经半小时 用vivo Y35M 8G运行内存 也要20分钟
我的前五感 告诉我 是你程序的问题，目前我还没有第六感 不好说第六感的结果
更新方案你要自己顶，比如说，1-10的版本每个独立，1-20的版本，就可以1-10一个包，11-20独立一个包。1-100的版本可以1-90一个包，91-100一个包。这块是你打包的时候的策略决定的，计算机程序，所有的优化都是有代价的，这些东西自己取舍。
我想确认一个问题，就是官方这个全量方案，是不是无论更新的资源差异大不大，只要版本号不同就要把所有资源下载到临时文件，然后才通过manifest去比对各个文件md5，把不同码的文件拷到可执行目录
还是说一开始先用manifest比对好文件里不同的md5码的资源，只针对这些资源进行在在到临时文件，再拷贝的可执行目录
是哪种？
你都不看代码的？先比对，然后下载差量到临时目录，然后拷贝到正式目录，然后拷贝正式的版本信息，然后更新完成，有断点续传。对这块要求不高的，直接用官方的没毛病。
我们是直接用官方方案的，但是我可以分享一个另外的方案，既能做差异，下载又快，在我和朋友交流的时候他们的方案。
方法是：
差异散文件列表可以由客户端产生，然后客户端发送差异散文件列表到服务后台，由服务后台来根据这个列表，返回实际下载的文件列表。
服务后台下发的实际下载的文件列表，就是由几个zip组成的，中间还可以带部分散文件，这些zip是根据差异文件列表，由服务后台压缩产生的。
是不是看上去由后台压zip包，会占用不少资源？ 其实不是的：
由于大多数客户端的差异文件列表是一样的。都是从版本X升级到最新版本，所以一个zip包在服务后台产生后被cache住分发到cdn上，zip包名使用md5这些hash来避免重复产生。后面的客户端请求的时候，这个zip就不需要服务后台重新压了。也方便进行预热处理。
1赞
刚才试了下故意把版本号调成不一致，但文件都一致，单纯测试比对的时间还是很快，可能问题出在了文件的下载与拷贝 ，因为这一块涉及文件量和带宽以及用户机器性能本身的问题，我想基于这个全量把文件换成zip要怎么一个步骤，就是把文件换成zip下载后自动解压
我看打包命令参数有一个compressed，设为true后，是否将ab包打成zip还是？
有偿求助，对情怀游戏的改造。请加我wx:huachengzou
之前有个编辑器bug是,同一份资源构建两次,md5不一样.所以哪怕没有任何修改 都走了更新,不知道你这种是不是