[Cocos2dx] 游戏更新方式对比

目前市面上常见cocos2dx游戏的更新有两种做法：

1. 散文件更新即单个文件更新；
2. zip包更新，然后本地解压；

两种方式各有优缺点，下面就分别来分析一下。

散文件更新

做法就是客户端存放一份所有文件与对应的校验值（md5或者crc）列表, 每一次更新都生成一份新的文件名与校验值对应的列表存放在web服务器上，客户端启动的时候拉取最新的校验值列表与本地的对比，发现哪些文件有更新直接下载即可。

优势：

1. 无论当前客户端处于哪一个版本，都能快速更新到最新版本；
2. 更新逻辑比较简单，只需要简单对比文件的校验值即可；

劣势：

1. 大部分的更新逻辑都是采用的http，下载每一个文件都会创建一个连接，比较耗时和流量；
2. 每次更新都要推送所有的文件到web服务器，如果项目资源比较大的话，这里花费的时间较长；

Zip包更新

每次更新时，将更新的文件打包成一个zip包，然后推送到web服务上，客户端启动的对比本地的版本号和服务器上的版本号，然后依次下载对应的更新包，然后本地解压即可，例如当前客户端版本处于版本1，服务端的版本是3，则需要下载2，3版本对应的更新包。

优势：

1. zip包里面只包含差异部分的文件，所以打出来的包比较小，推送到web服务器比较快；
2. 少了很多http的创建的时间，也节省了玩家的流量；

劣势：

1. 如果跳版本的话，玩家需要分别下载中间版本对应的更新包；
2. 服务端需要维护很多个版本对应的更新包，不能清除，而且一直在增长;

当然，现在5G时代，流量的因素已经可以不用考虑了；而且大部分的更新都采用了多线程的方式，所以创建http的耗时也可以不用考虑了。

这里有个场景很常见，在完成一个资料片后，希望在资料片维护的同时上新的iOS包，运营配合着做推广，而iOS需要审核，所以会出现打包的时候需要将最新的内容一起打包进去提审。

采用zip的方式的时候就需要将生成一个新的版本，但是这个版本还不能外放，而且如果想在iOS提交审核和正式维护期间想要更新就比较麻烦了；而采用散文件方式就没有这个问题。

上面的例子并不是说散文件更新方式要比zip好，两种方式没有那种方式一定好于另外一种方式，选择合适自己项目的方式就好了。