火速留名等待大神
mark!!!
支持…
期待大神成功，然后让官方看到，然后官方换方案
cocos这种更新模式是最节省的吧，文件只跟最新的对比，而跟版本过程无关，热更回滚也是支持的，zip也是支持的。
3赞
希望可以支持so包，java代码的热更
zip包更新是 cocos 最原始方案, md5对比这种更适合频繁更新, 每次对比完只是下载md5值不一样的文件.
这个md5的api，如果拓展为 可手动调用检查文件是否被篡改就好了，可防止修改器作妖。
战术插眼mark
增量zip是原cocos2dx的热更方案，浪费流量，日活上万的项目CDN费用能让你抓狂
现在的热更方案才是正道，何必倒退回原始社会呢
1赞
不太理解zip为何浪费流量？ 我的理解应该是更小啊，因为如果是现在的方案当你项目迭代文件有几百个文件待更新时，可能文件总下载大小有20M, 如果走了ZIP可能只要5M下载。
1赞
json能http gzip压缩的。。。
散文件更新最大问题还是请求数过多的问题
你说的是传统端游用的增量patch吗？长时间不上，下载的更新比重装游戏还大
我觉得我们说的不是一个东西，还是打住吧
这个问题如果assetbundle在原生端也支持zip就不存在了，现在只有小游戏支持zip，原生官方不知道有计划没
官方方案是好，但是变动文件数量比较多情况下，下载比较慢
对于长时间不上或跨度版本较大的，可以指定版本下载整包解决。
1赞
那要看下载模块怎么写了，用原生接口可以开多线程，最终瓶颈还是在带宽上，文件多不成问题
http 是能用 gzip 的。用了 zip 就算能省一点点，但也是增量更新啊？你不是说你的项目版本迭代比较频繁吗？你确定增量更新不会包含大量无用的中间版本资源？
1赞
http gzip 我再尝试下，对比一下效果。之前主要是在下载连接数过多的情况下比较糟糕。 我们项目属于中大型，资源量也是大的，数据表sheet数量已经有1000+，为了控apk大小，resources动态资源没有打在包里,采用动态下载 , 其他资源打在包里（热更），我的现有想法是，如果版本跨度很大，可以走下载APK流程，这样可以避免无用中间版本下载。
官方的大部分东西 都是想象着来，没做过东西，就想着能用，没太想着更细节的方向。热更新为啥会做成散文件的方式，不光大小有问题，而且每个链接的建立和断开对手机资源的消耗 下载速度 有很严重的影响
2赞