背景

最近我们要在一个新的 App 上增加热更新的能力，按照以往的设计思路，需要后台一起参与，并提供对应的接口，具体的接口如下：

接口	参数	返回值	备注
uploadBasePkg	appVersion：App版本号；baseFile：基础包文件		上传基础包，发布流水线打包之后自动上传
uploadUpdatePkg	appVersion：要发布到的App版本；hotVersion：热更新版本号；updateFile：热更包		上传热更包，上传完成之后，需要与指定的基础包和该基础包的历史热更包生成diff文件
requestUpdate	appVersion：本地的App版本号；hotVersion：本地的热更新版本号；uin：用户id；platForm：系统（Android，iOS）	hasUpdate：true/false；updateFile：热更新文件下载地址；md5：校验；fileLength：文件长度；msg：热更新说明；HotVersion：热更新版本号；versionType：更新类型（1静默，2推荐，3强制）	请求热更新，若有，则返回热更新配置，若无，则hasUpdate返回false

相当于是把 diff 的计算放在后台，然后每次客户端请求后台去获取到对应的 diff 包，并在本地进行合并，就完成了一次热更新。可以参考：
Cocos热更新的非官方解决方案

这是个很好的解决方案，但是后台同学的工作量比较大，而当前后台的人力又比较紧张，因此在综合考量需求和现状之后，我们决定使用配置系统+流水线的方案来实现热更新的能力。

方案调研

当前我们 App 已经拥有配置系统的能力，可以根据系统，用户id，版本号等参数下发不同的配置，而热更新就是需要基于这些参数去获取到不同的 diff 包。

而生成 diff 包的能力，我们可以放到流水线上去执行，生成的产物自动上传到 cos，然后获取到下载链接，并组合成配置。我们拿到这个配置之后，就可以根据我们的需要，将其发布到对应的版本或者用户上了。

具体方案

流水线的流程如下图所示：

我们每次打包完，都需要将旧包保存。在生成 diff 包的流水线上，我们只需要输入升级分支，便可以生成 diff 包。diff 包包含两部分，分别是old.zip 和 new.zip 的差分文件，以及 update.manifest 文件，这个文件包含了 new.zip 的全部文件及其对应的 md5 值，可用于合并校验。

手机端的流程如下图所示：

其中，检查热更新是直接从配置系统获取最新的配置，然后和本地的热更新版本号进行对比，若配置系统的版本号高于本地的版本号，则需要进行热更新。

方案优缺点

优点	缺点
简单，不需要后台的介入	依赖于配置系统的能力，比较难实现一些个性化的需求；需要在流水线上进行一些开发