之前cocos2dx 用的增量更新，多版本的问题就是类似用这种方式，但是我们是在本地打好各个增量包上传
最新小版本就采用逐个更新，类似1.4.1 升到 1.4.5，那就中间的包是要更新
但是大版本，我们会按情况重新出大版本更新包，比如1.4.0的时候，就会出1.0.x增量包,1.1.x增量包,1.2.x增量包，1.3.x增量包给更到1.4.0,是否重新打增量包，视更新内容定的
当然能用到服务端自动打包就更完美了
1赞
是的，我打算用这种方式。
服务器收集其实是将出问题的机率增加到下载时刻了，这样感觉更危险，而且对服务器性能有要求。
将这个过程提前做好，直接推cdn，下载的时候就简单的cdn下载解压完事，减少出错的机率
这种办法也太无脑了，我们技术评审阶段就放弃了，对于要长线维护不想强更的项目简直是运营噩梦。
假设某一天出了个紧急BUG，老板要几分钟更上去那种，你要对老板说：不好意思，要打99个差异包，至少要1个小时
本地很多手段可以加速的。。。
比如每个版本存一个md5sum文件记录，通过不同版本的md5sum对比结果提取文件。
比如对比工具支持多线程
比如提取好一个版本diff后就先推送一个版本
比如升级本地机器配置
等等。
只要在本地，就有很多办法加速。
这个倒不至于，紧急的就打紧急热更包，就更当前线上最新版本的就可以，旧版本的依旧更到线上的版本后再更修bug的。
灵活变动，等有时间了再去打旧版本的整合热更包
官方更新方式很好用，就是慢了点，不过可以通过多开点下载线程来改善这个问题。
我们项目也属于中大型游戏，资源量也差不多到这个量级，目前用的是官方的方案，已经平稳运行一年多了。
下面是我打算在新项目中用的方法，还是基于官方的方案，希望对你有所参考：
- AssetBundle有一个
压缩类型，选择合并所有JSON，这能巨大减少SpriteFrame产生的json文件的大小，我们新项目的json文件现在已经达到7000个，后面上线估计要上万个json文件，目前合并后是15M大小，zip压缩后是1.1M。 - 每个AssetBundle中的import和native按子文件夹打压缩包，比如
00, 0a, 0b这些文件夹打完之后就是00.zip, 0a.zip, 0b.zip等等。这样每个压缩包平均下来可能是几M，总共大概是几百个压缩包，project.manifest的大小就有效得到控制，且如果美术资源相对稳定，下载就量就不会太多。官方的方案是支持zip压缩的，多看一下官方相关文档。 - 资源服务器按版本来的，每次全量上传一个版本，这样服务器上可能就有版本1, 2, 3, 4的文件夹。每个版本是全量资源，也就是可能每次要上传上G的资源，等会说说怎么优化。最后CDN更新version.manifest和project.manifest，修改里面的版本指向最新的版本目录。这样能确保更新一定没问题，且CDN刷新也只需要刷新两个manifest文件。
上面说到每次要全量上传资源到一个新的版本文件夹，其实不用这么做，也不需要写工具去提取差异资源。只要用rsync就可以了，有两种方法：
- 用rsync上传到服务器的一个目录，比如叫asset，第一次传肯定是全量上传，但后面再传就直接利用rsync的增量上传了。上传完毕后，从asset拷贝一个新文件夹出来，名字为版本号；然后就是重新上传version.manifest和project.manifest，再刷新这两个文件夹的CDN。这个方法的坏处是比较费服务器的存储，假如你的资源是1G，每次更新就会增加1G的存储，不过这样也还行。主要是上传速度还挺快的，几秒就能搞定。
- 用rsync的一个比较高级的用法：基准目录，大概思想是第一次上传为基准目录，以后上传的目录只会有差异的资源，相同的资源都软链接到基准目录去了，这样就大大减少服务器的存储。具体用法看这个连接的教程rsync 用法教程。
热更新有一个注意点，文件下载来之后，一定要比较文件的md5和manifest记的md5是否一致，一致才算下载成功。以前就吃过这个亏，默认成功，导致有少数出现资源错误的情况。
11赞
嫌麻烦，客户端实现一个git得了，完美
3赞
增量zip方式，也可以实现差异化更新吧，用python写个工具，说下我在用的方案：
1、在出包时同步记录个1.0的的version文件列表（包含每个文件的md5）；
2、发第一个热更版本1.1时，根据version文件，用脚本把md5差异化文件压缩成1.1.zip；
3、发第二个热更版本1.2时，用脚本把差异化文件压缩成1.2.zip，同时清理往前版本如1.1.zip中重复的文件，避免重复下载浪费资源；
4、发第三个热更的时候同理；
这样实现，客户端只管负责zip热更就好了，把文件差异化放在本地，减少客户端的文件遍历校验，性能提高，传输的也少下载也快。
如果一直没有整包更新，你这种方式也没问题，问题是，我在1.1的时候，出了一个包，那么怎么处理1.0和1.1用户的更新问题呢?
是回复我上面的吗？如果你是在1.1的时候换包，首先得看更新方式吧，如果只是普通更新，就是替换包而已，也不影响1.0的旧包热更，后面的1.2,1.3也可以继续下载；
如果改动较大，那这个属于建议更新强制更新的范畴，通常我这会升级到2.0，而不是在1.1出个包，1.0系列的包是不会热更2.0相关资源，互相独立的（可以在外层以文件夹区分等方式实现）
看了这么多讨论，就会发现为什么官方用这种方式的原因了，不一定是最优解，但确实最通用的，任何需求都可以实现，且不会比其它方案差太多，各位讨论的几种方案（忽略存在服务器的情况下，不然jare提的当然最好）
第一种：每个版本跟以前的所有版本对比[quote=“510109407, post:40, topic:98218”]
我们公司采用的是客户端使用python工具,对比每个版本的差异文件,逐一更具版本号生成zip的方式,比如说:1.0版本文件:A,B2.0版本文件:A,B,C,D3.0版本文件:A,B,C,D,E,F最终生成的热更文件目录就是:update----dir_3.0_1.0.zip(包含文件:C,D,E,F)----dir_3.0_2.0.zip(包含文件:E,F)
[/quote]
前期还可控，版本一多，人都蒙了
第二种：增量更新（端游常用方案）[quote=“jasonmr.q, post:1, topic:98218”]
最近得空挤出点时间换种方案来做热更–增量版本包.zip，目前功能机制和上传发布工具已经完成，正在测试阶段。等测试完我会分享出来！有需要的可以留言〜
[/quote]
1.长期没有登录的用户，重复资源一大堆
2.官方热更zip是无序的（当然这可能是楼主主要解决的点）
第三种：简化的官方差异更新
如果每出一个热更包，就要出一个包（即老用户走更新，新用户走新包），那要兼容两个包的差异就很难，当然楼主说两个包的热更就分开做，那像我们这种一周一个版本的，也要疯。
所以，每层提出的都有可行性，但却不具备普片性，我还是觉得官方做的挺好的，永远是最新的跟包里面的比，唯一的是js合并了，太大了（2.4之后其实也基本没问题，但是如果直接来个支持不合并的选项就更好了）
1赞
楼上说了这么多理论，实际去用用，看看效果，官方案例简单，兼容性强。用了你就知道优点
针对这种方式，你说担心的确实存在，但一个项目如果采取了这样的方式进行热更新，会配合其它的手段来让这100个版本缩小再缩小，比如从100个缩小为只维护10个
没懂你里边说我的方案里边说老用户走更新，新用户走新包的方式？
我只是把差异化的内容都整合到zip进行增量更新，并且去重，最终下载的内容跟你们差异化对比更新没任何区别，该下的文件不多不少，你们多版本时用差异化方案怎么处理的，改用zip也可以一样处理方式吧。
至于分版本文件夹管理看项目需求非必须（另外不否认官方方案的普适性）
1.0 版本 出了 一个1.apk
1.1 做了一版热更 1.1.zip
1.2 做了一版热更 1.2.zip 并出了一个2.apk
1.3 做了一版热更 1.3.zip
请问2.apk 需要更新那些内容，
第一种方式如果只更新1.3.zip,那么你的2.apk的manifest就记录曾经zip的所有信息
第二种方式直接将1.1.zip，1.2.zip， 1.3.zip都下载，那么资源重复了
第三种方式每个apk走独立的热更，那多个版本的app的维护就很困难了
同时，因为你过往的zip都是动态变化的，势必不能做md5比较，那么资源的完备性，你也无法保证。
另外，如果使用了cdn，因为你过往的zip是动态变化的，cdn刷新时效性，也会造成问题，本质来讲，除了第三种方式解决问题外，另外两种处理方式还存在bug
第一种方式如果只更新1.3.zip,那么你的2.apk的manifest就记录曾经zip的所有信息
针对你说的3种方式，那我这里用的第一种吧
1.apk，2.apk都会下载1.3.zip，2.apk出包时是有包含以前发过的1.1,1.2的热更资源（因为每次出热更包，都会全部zip重新整理，并不存在重复资源，这点是区别于普通增量更新的点。）
我的apk并不存储manifest等文件，文件md5列表数据是存储在本地的，zip的整理也是在本地整理最后全部上传，游戏只是负责根据当前版本号拉取并下载解压zip就行，你的后半句我还是有点不太明白，包含了会有影响吗？
同时，因为你过往的zip都是动态变化的，势必不能做md5比较，那么资源的完备性，你也无法保证。
另外，如果使用了cdn，因为你过往的zip是动态变化的，cdn刷新时效性，也会造成问题，本质来讲，除了第三种方式解决问题外，另外两种处理方式还存在bug
至于zip动态变化，md5的比较，cdn刷新时效性问题，目前我游戏热更模块暂没用到cdn可能没发现这问题，但这些通常可以辅以方法，修改zip名字，加字段参数，动态参数等强制刷新吧（我是还有个json字段记录全部版本文件信息），这点也不是zip独有的吧，可能还有其它我没发现的问题？
非强更下，普通换包我的1.apk跟2.apk都是运营的同一套热更资源，也比较好维护，公司项目也平稳运行几年了，热更模块一直正常，可能你的是完全不同的多版本在同时运营？所以版本多了热更麻烦？
你所说的这几点，我是好奇用官方差异化更新方案不也存在同样的问题吗，能适用你的项目吗，除了下载的内容不同，不也是一样的处理方式？
1赞
1, md5.bin 是项目构建后成生的res , src 所有文件的md5, md5.bin仅供工具生成差异文件使用，游戏不下载些文件, 在生成zip的时候会自动生成wconfig.json文件。 在打apk时会带上这个wconfig.json版本配置文件，每次更新后会下载CDN最新的wconfig放在缓存目录下。
2,远程检测版本文件是提供热更地址和其他下载信息的文件
/*
file:checkVersion.json
- {
“download”:true, //下载安装包开关
“hot”:true, //热更开关
“version”:“8.4.1”, //低于此版本的安装包,则会下载APK安装包(内部进度条下载)
“fixVersion”:“5.0.0”, //低于此版本的安装包,通过外部浏览器下载整包(特别情况解决不兼容问题)
“size”:77614126, //安装包文件大小(字节)
“url”:“remote/path/to/apk”, //远程安装包（商店）地址
“hotUrl”:“remote/path/to/hot/channel/”, //远程热更目录
“whitelist”:[“0.0.0.0”] //IP白名单,测试用,可以在关闭热更、下载开关时，更新、下载 - */
楼主的思路跟我在用的差不多，md5.bin（我这里叫其它名字）在出apk包时同步构建的，仅供工具生成差异文件使用，游戏不下载这些文件，后续每次发热更时都会同步有一个cache文件夹记录发的热更文件（在你这是bin文件）
不知你的增量更新有做清理重复文件吗，当你发热更最新到8.5.0.2时，可以与该版本对比，清理往前版本如8.5.0.1版本zip中重复的文件，若清理后zip为空则删掉zip，json里边同步好就行。
1赞
支持mark