背景

Cocos 官方提供了一套热更新的解决方案,但我们认为这套方案在以下方面不能完全适合我们的需求:

1. 必须要在 Cocos 引擎启动之后才能够开始热更新流程，而我们有些业务场景需要支持在 Cocos 引擎未启动的时候就能够开始热更新流程；
2. 文件下载效率低，官方提供的方案是在客户端本地对比本地的文件 manifest 和服务端的文件 manifest，找出其中的差异，然后再将差异的文件下载下来，并逐个校验，效率较低；
3. 没有回退兜底策略，若本地进行热更新之后出现异常导致用户无法使用，无法回退到上一个版本；

基于这些问题,我们给出了自己的 Cocos 热更新解决方案 TinyCocosFix。 TinyCocosFix 是基于 native 端实现，因此能够在 Cocos 引擎未启动时就开始热更新流程；我们将文件 diff 的逻辑放在服务端，服务端直接将两个版本的 diff 文件压缩成 zip 包返回给客户端，然后客户端再针对 zip 包做校验，整个 diff 的过程比官方的方案更加高效；另外，我们还在本地做了历史版本管理，当新的热更新版本出现异常，导致用户无法使用时，可以启动兜底策略，本地回滚到上一个版本，尽最大可能保证用户体验。

可行性分析

根据 Cocos 的官方文档，docs.cocos.com/creator/man… Cocos 所有的文件均通过 FileUtils 查找，而 FileUtils 会按照搜索路径的优先顺序查找文件，所以理论上，我们只需要将热更新的文件下载下来，放到指定的目录，并将该目录添加到 FileUtils 的搜索路径的前面，这样我们就可以实现热更新了。

经过 demo 测试，验证了我们的猜想。因此整个热更新的原理其实比较简单，客户端携带版本号等相关参数请求后台，后台收到App的请求之后判断是否有热更新，若没有，则返回无；若有，则返回热更新资源包。客户端下载完热更新资源之后，将对应的路径插入到 FileUtils 搜索路径当中，即完成了热更新的过程。

TinyCocosFix的总体设计

整个热更新的流程如下图所示，根据角色分为前端，后台和客户端； 当我们发布新的 App 版本时，需要告诉热更新管理平台，并上传当前 App 的资源包，这时候的资源包为 base 包； 当我们需要发布热更新的时候，此时需要上传热更新资源包，管理平台可以指定该热更新资源包能够更新到哪个App版本，并和之前的资源包生成 diff 包； 当对应版本的客户端请求后台时，便会返回相应的 diff 包给客户端。

1.后台

链式管理

管理后台使用链式的方式对 App 版本和热更新版本进行管理，具体如下图所示： 我们发布热更包的时候可以自由的指定这个热更包能够在哪个 App 版本上生效。 例如当我发布热更新1.0版本，指定在4.3.5和4.4.0上生效,则在其后追加1.0； 当发布2.0时,1.0自动过期； 当发布3.0，指定在4.4.0和4.4.5生效时，4.4.0的2.0热更包过期，4.3.5的2.0继续生效。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lodo8dFK-1670401126326)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b03c4e66ce574609851526c16e84e5f0~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.image)]

生成最近5个diff包

当我们在管理后台创建热更新包时,会找最近的5个热更包生成 diff 包,如下图所示: App 版本4.4.0已经发布了6个热更新版本，当我们创建7.0热更新版本时，会自动找最近的5个版本生成 diff 包， 此时，如果客户端的App版本是4.4.0，热更新版本为2.0 - 6.0，则会直接返回对应的diff包； 如果客户端的App版本是4.4.0，热更新版本为1.0，则第一次请求，后台会返回没有热更包，并触发对应1.0和7.0的 diff 包生成逻辑，下一次请求就会返回对应的热更包。

2.客户端

客户端的热更新流程如下：

热更新策略

我们定义了三种热更新策略

历史版本管理

TinyCocosFix 会在本地最多保留三个历史版本，并对外提供了回退到上一个版本的接口，业务方可根据自己的需求来定义触发回滚的逻辑。 如下图所示，为我们业务的回滚策略： 我们会在主要场景检测发生的异常，若在一分钟内发生超过50次异常，且本地发生过热更新，则触发回滚机制。 回滚完成之后 TinyCocosFix 内部会上报触发回滚的异常，并记录发生回滚的版本，若下次检测到相同的版本，则不会提示有热更新。

异常管理

TinyCocosFix 内部会对异常进行管理，主要分为热更新过程异常和业务方的热更包自身逻辑异常，具体的处理方式如下表所示：

断点续传

若热更新下载过程中进程突然被杀掉，下一次启动会从上次下载的地方继续下载。

3.热更管理平台

主界面

热更新管理平台界面如下：

目前管理平台包括四个部分：App 版本管理，热更包版本管理，灰度用户管理，开发者管理。 App 版本管理 创建App版本界面如下： 我们 App 每次发版时，需要在管理平台创建对应的App版本，这样发布热更新时，我们才能够指定热更新支持的版本，后台也能够根据每个版本生成 diff 包，我们需要提供 App 的版本号以及对应的资源包。 这一步可以在蓝盾上使用流水线自动实现。

热更包版本管理 创建热更包需要提供热更新的资源包，并选择热更新策略，在下一步可以选择热更新生效的App版本。

灰度用户管理 在这里配置的灰度用户适用于精确灰度，当我们的热更包还处于自测阶段时，只有灰度id才能够收到热更包。

开发者管理 只有拥有权限的用户才能够进入到管理平台。

热更新发布流程

我们规范了热更新的发布流程，如下图所示：

我们认为发布是一个很危险的操作，任何发布的热更包都必须要经过测试，因此新创建的热更包只能是灰度包； 精确灰度 管理后台有一个灰度账号管理，创建的精确灰度包能够匹配到这些账号，这一步主要用于我们内部测试； 批量灰度 当我们精确灰度没问题之后，便可以进行下一个步骤，批量灰度。目前支持尾号匹配和上传 excel 两种批量灰度规则。 尾号匹配，例如用户的id为12345678，尾号匹配为8或者78，均能匹配到该用户。有时我们发布热更包希望只有某些确定的用户能够收到，则可以使用上传 excel 的功能，excel 表格中包含所有批量灰度的用户。 发布 批量灰度一段时间之后，观察下热更新的成功率和失败率以及回滚率，如果没有问题，便可以发布了。 在批量灰度和发布期间均可以将热更包过期，一旦过期热更包立即失效，过期的热更包可以恢复到之前的状态。

4.上报统计

TinyCocosFix 会上报三类信息，具体如下

类别	备注
初始化上报	统计热更新版本存量用户
热更新结果上报	统计热更新成功率和失败率
回滚上报	统计回滚率
上报结果统计界面如下：

5.和官方热更新方案对比

本文转自(https://juejin.cn/post/7174219571816038414)，如有侵权，请联系删除。