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

在某家 养恐龙游戏 公司当主程的时候也研究过当时项目中，前人实现的热更相关逻辑。

在原生平台采取的是，游戏打包成H5网页，然后 Android/IOS 包通过打开某个网页的方式来进入游戏。(*1)

另外给 配置和UI 实现一套热更逻辑，打包时将 配置和UI 打包成 zip，并生成对应的 manifest 文件。这套配置和UI的热更，在原生和小游戏平台都能使用，非常方便。

为了方便开发使用，前人在项目中制作了 傻瓜式的批处理执行文件，通过 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 为 总渠道数量)。颇有些“低收益高风险”。

总结

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