游戏热更新自动化

游戏服务器后端这边对前端的热更心大包流程不是很熟悉，国内app上线之后，原来后端这边只定义了一个热更新资源版本号，客户端每次发热更之后，我这边配合修改下这个资源版本号，当客户端登录进游戏之前会向后端获取一些配置信息，后端这边就会将最新的资源版本号返回给前端，前端会比较本地当前热更版本号和从服务器拿到的资源版本号，当检查到有新资源是，客户端这边会从cdn下载新资源。 但是随着项目上线之后，版本管理就很混乱了，主要问题有以下几个方面：

1.客户端每次打完热更资源包之后，都要通知服务器修改以下资源版本号，前期bug多，热更资源包打的很频繁，每次都要我这边手动更新后端配置表。

2.上线之后，发给应用商店的包，需要定期更新，不然累计的热更资源越来越多，新玩家在应用商店下载新包之后，还没进游戏可能又要下个几十M甚至更大的更新包，这样对玩家体验也不好。重要的是，前期上线之后，有一些bug设计到底层修改，必须要出整包才能解决问题，出完这个整包之后，前一版本的整包还能继续支持热更新吗？如果要支持热更新，就需要针对每个整包出各自的一份热更新。这样程序和qa的工作量会非常大。

3.整包更新之后，程序如何做到自动化提示玩家更新下载呢？

针对上面出现的问题，后端这边梳理了下整体流程，我们这样规定，每一个整包有两个版本控制，大版本号+资源热更版本号，资源热更版本号是3位数，取资源版本号的前两位数作为大版本号，每一次出整包的时候，大版本号的第二位加1，资源版本号从0开始，大版本整包出了之后，上一个整包就不再支持热更新了。每个月的前3个星期每周四发例行资源更新包，月底那一周的周四发整包，整包包含这一个月的更新功能，前一个整包就不再支持更新维护了，但是玩家仍然可以继续用老包玩。

比如说：第一版整包 bigVersion: 1.0 assertVersion:1.0.0，在此基础上的热更资源包大版本不变，热更资源版本1.0.1->1.0.2->...->1.0.10

第二版整包 bigVersion: 1.1 assertVersion:1.1.0，在此基础上的热更资源包大版本不变，热更资源版本1.1.1->1.1.2->...->1.0.10

后端配置表这边有一个专门维护前端热更新相关的两张表Update.xml，Update_version.xml，Update.xml结构大致如下：

clientAssetsVersion：是控制线上的热更资源版本号，如果分渠道热更，可以将channelAssetsVersionSwitch设置为true，channelAssetsVersion配置各个渠道当前的资源版本号，资源版本号是3位数，前面两位是大版本号。

Update_version.xml结构大致如下：

每一行update_info就是代表bigVersion小于等于配置的值，它当前的最新热更资源版本号就是表里配的。

第一个问题的解决方案，给前端JenKins打包提供了两个http接口，查询当前的热更资源版本号和更新当前的热更资源版本号。

Jenkins打包脚本在执行打包之前，先向后端询问当前bigVersion+platform的最新热更资源版本号是多少，后端优先在update_version.xml中查找对应的热更资源版本，如果没有找到，然后再去拿update.xml中的clientAssetsVersion，Jenkins将拿到的资源版本号第三位加1作为本次打包的资源版本号，打完包上传到cdn之后，bigVersion+platform+newClientAssetsVersion通知后端将老的资源版本号替换成新的。

这样就实现了测试环境打包自动化，解放了后端程序员的双手，我们只需要在对面发热更之前，将最新的一个资源版本号合并到线上的update.xml，该资源就能面向玩家了。

同时，后端针对打包修改会做一个日志记录，便于追踪：

这里不传大版本号默认就是修改update_version.xml中的clientAssertVersion

第二个问题的解决方案，就是每出一个整包，在update_version.xml中新增一条记录。

上图中第一条记录表示苹果包大版本号<=1.0的整包，最新的热更资源版本号是1.0.3；

第二条记录表示所有包大版本号<=1.1的整包，最新的热更资源版本号是1.1.13；

第三条记录表示联想包大版本号=1.2的整包，最新的热更资源版本号是1.2.1

第四条记录表示所有包大版本号<=1.2的整包，最新的热更资源版本号是1.2.13

客户端在向服务器获取最新资源版本号时，会传一个bigVersion+platform参数，后端先在updateversion.xml中按id从小往大向下查找，如果有匹配到的，资源版本号读这里配置的，如果没有匹配到的，再去update.xml中拿。这样有效实现了版本隔离更新管理，每一次出整包之后，我们只需要在update_version.xml中新增一条上一整包的更新限制即可。

第三个问题的解决方案，每次出整包会升一个版本号，后端这边在update.xml中又定义了两个字段checkVersion，channelBigVersion。

checkVersion审核期间版本号，每次出完整包送去提审时，有些功能可能审核期间需要屏蔽，不然可能过审不了，这个字段里面定义的就是当前各个渠道正在提审的大包是那一版。

channelBigVersion线上当前最新的大版本号，审核通过，准备发上线时，设置当前各个渠道最新的大版本号，客户端在获取配置信息时，根据前端传过来的bigVersion与当前配置的bigVersion做比较，如果有新版本更新了，弹窗提示客户端下载新包，下载新包有两种形式，渠道包审核通过之后，有一些渠道会给新包下载的apk地址，小米的不同版本apk地址始终都是固定的，华为是不提供apk下载地址的，还有一些渠道每一个包的apk下载地址是不一样的，后端这边新建了一个channel_cdn.xml表如下：

后端检测到有新包更新，后返回给前端该渠道的apk下载地址或者商城的网址，然后玩家可以直接下载覆盖安装，或者跳转到应用商城的app下载页面去。