热更新后日谈——多渠道安卓热更

之前写了 CocosCreator 下的热更。 CocosCreator 3.7.x 一步步给你的项目增加热更新 - bakabird1998 - 博客园 (cnblogs.com)

 

当我在某家养恐龙游戏公司担任主程时，我研究了项目中前人实现的热更逻辑。

针对原生平台，我们的方法是将游戏打包成H5网页，然后通过打开特定网址的方式让Android和iOS包进入游戏。(*1)

此外，我们还实现了一套便捷的热更逻辑用于配置和UI。在打包时，我们将配置和UI打包成一个zip文件，并生成相应的清单（manifest）文件。这套热更方案在原生和小游戏平台上都能使用，非常方便。

为了方便开发使用，前人为项目创建了一套简化的批处理执行文件，通过一系列命令如"ver make"、"ver list"、"ver publish"等来完成热更打包、版本管理和发布等任务。

然而，我们发现这个工具很难进行拓展，这在后续的业务中给我带来了问题。

 

在后续的业务中，我需要将游戏上架到多个应用商店平台，并接入相应平台的SDK。

在此之前，项目通常只通过广告下载的方式分发应用，因此只需要维护一个安卓包。

然而，一旦游戏上架到多个应用商店，我发现之前提到的热更逻辑(*1)会带来麻烦。每次进行热更时，所有渠道包都会进行相应更新，这导致了一些问题。

 

开发不便：在开发过程中，我们不仅需要适配不同的包版本，还必须应对不同的渠道要求，这导致我们需要编写大量的条件判断代码和适配逻辑。这种情况增加了开发的复杂性，给我们带来了不少困扰。

var channel = Plat.inst.channel;

var pkVersion = Plat.inst.packageVersion;

if (channel == Channel.vivo) {

　　if (pkVersion >= 3) {

　　　　JSBKit.me.playTemplateAd(...);

　　} else {

　　　　console.warn("该包版本不支持模板广告")

　　}
} else if (channel == Channel.mi) {

　　// ......

}

// ......

测试不便：在进行发布前的测试阶段，由于即将发布的代码需要在所有渠道的包上运行，即使我们的代码只针对某个渠道，我们也需要测试所有渠道的包。这增加了测试的负担和复杂性。

影响玩家使用体验：玩家可能由于其他渠道包的热更功能而在启动游戏时需要等待，这对玩家的使用体验产生了影响。

维护不便：意外情况往往会发生，一旦代码出现问题，针对某个渠道的代码更新可能会不慎"波及"到其他渠道，从而导致问题在 n-1 （n 为总渠道数量）个渠道上爆发。这带来了较低的收益和较高的风险。

 

总结

对于 不同的渠道 的安卓包，最好使用 不同的热更远程地址。