|
目前市面上常见cocos2dx游戏的更新有两种做法：
- 散文件更新即单个文件更新；
- zip包更新，然后本地解压；
两种方式各有优缺点，下面就分别来分析一下。
散文件更新
做法就是客户端存放一份所有文件与对应的校验值（md5或者crc）列表, 每一次更新都生成一份新的文件名与校验值对应的列表存放在web服务器上，客户端启动的时候拉取最新的校验值列表与本地的对比，发现哪些文件有更新直接下载即可。
优势：
- 无论当前客户端处于哪一个版本，都能快速更新到最新版本；
- 更新逻辑比较简单，只需要简单对比文件的校验值即可；
劣势：
- 大部分的更新逻辑都是采用的
http，下载每一个文件都会创建一个连接，比较耗时和流量； - 每次更新都要推送所有的文件到
web服务器，如果项目资源比较大的话，这里花费的时间较长；
Zip包更新
每次更新时，将更新的文件打包成一个zip包，然后推送到web服务上，客户端启动的对比本地的版本号和服务器上的版本号，然后依次下载对应的更新包，然后本地解压即可，例如当前客户端版本处于版本1，服务端的版本是3，则需要下载2，3版本对应的更新包。
优势：
zip包里面只包含差异部分的文件，所以打出来的包比较小，推送到web服务器比较快；- 少了很多
http的创建的时间，也节省了玩家的流量；
劣势：
- 如果跳版本的话，玩家需要分别下载中间版本对应的更新包；
- 服务端需要维护很多个版本对应的更新包，不能清除，而且一直在增长;
当然，现在5G时代，流量的因素已经可以不用考虑了；而且大部分的更新都采用了多线程的方式，所以创建http的耗时也可以不用考虑了。
这里有个场景很常见，在完成一个资料片后，希望在资料片维护的同时上新的iOS包，运营配合着做推广，而iOS需要审核，所以会出现打包的时候需要将最新的内容一起打包进去提审。
采用zip的方式的时候就需要将生成一个新的版本，但是这个版本还不能外放，而且如果想在iOS提交审核和正式维护期间想要更新就比较麻烦了；而采用散文件方式就没有这个问题。
上面的例子并不是说散文件更新方式要比zip好，两种方式没有那种方式一定好于另外一种方式，选择合适自己项目的方式就好了。
|