一、背景

1.1 为什么要搭建热修复平台

随着公司的快速发展，需求的快速增加，App迭代也越来越频繁，如果移动应用出现问题，不仅仅影响用户体验，还会影响公司口碑，甚至可能造成资损。需要快速修复线上问题，对比常规的开发流程而言，热修复更加灵活方便，优势很多：

无需重新发版，实时高效修复bug；
用户无感知修复，无需下载新的版本，代价小；
修复成功率高，能把损失降到最低；
因此热修平台愈加重要，需要搭建一个高效，好用且安全的热修复平台。

1.2 思考

搭建热修复平台，首先要考虑热修方案的选择，但这不是本文的重点，我们这里不做过多讨论。目前有赞 Android 侧的热修是基于 Tinker 自建的后端服务 + Android SDK 实现的。

下图简要描述了热修的主要过程：

看似简单的流程，在多人开发团队中，其实存在很多问题：

每次版本打包发布，如何保存基准包及mapping等文件用于后续热修生成补丁？
热修代码的分支如何规范管理？
如何构建补丁包，构建了如何保存？
补丁包如何快速高效的本地验证？
补丁发布策略，发布审批等
补丁下发数据如何统计？
针对特定用户怎么查询热修状态？
热修出了问题怎么定责，怎么对热修代码追溯？

1.3 热修平台定义

针对以上问题，我们认为热修平台应具备以下特点：

支持打包文件保存
定义标准的热修分支规范
支持补丁包的构建保存
支持方便的本地验证测试
支持权限审批
支持补丁全量，灰度及条件发布
支持热修状态查询，数据统计
支持历史热修代码查看

二、热修复平台

2.1 写在前面

在后面介绍热修复平台的过程中，会多次提到 MBD 及 APUB，这里先做下说明，便于下文理解：

MBD(Mobile Build): 有赞的移动应用构建平台, 支持App构建, 热修构建及SDK构建。
APUB(App Publish): 应用及热修等发布平台，APUB 的上游为 MBD，承接了 CI 系统的产物。下游则是 C 端用户，作为应用发布生命周期的最后一环，为所有应用补全了热修复和灰度分发相关的能力。

同时为了讲清楚热修复平台，本文以Android为例按照热修过程，顺序介绍。

2.2 打包文件保存

Android 侧使用 Tinker 首先要考虑的是构建产物及 mapping 等文件的保存，用于后续打补丁包

由于有赞内部 App 发版构建, 热修构建，SDK构建等都是通过 MBD 构建平台，且MBD 本身已支持打包产物的自定义上传，因此借助 MBD 构建平台就可以做到保存 apk&mapping 文件。MBD 构建平台打包是在运行着 GitLabRunner 的黑苹果上进行的， GitLabRunner 是 GitLab 基于 Go 实现的脚本解释器，如果感兴趣可以自行了解下，这里不再展开。

App 使用 MBD 打包需要先指定打包脚本，脚本为 yaml 格式，其中 artifacts 指定哪些文件要上传到 CDN , 配置中的 paths 中指定了 Tinker 构建产物目录 bakApk&mapping ，因此Tinker 产物会上传到 CDN, 脚本如下：

build:Git API
    artifacts:
        untracked: false
        name: "out"
        preview_pattern: "app-full-release.apk"
        cdn_path: "xxxxxxxx"
        paths:
            - app/build/bakApk
            - app/build/outputs/apk/
            - app/build/outputs/mapping/full/release/
    script:
        - env
        - ./gradlew clean assembleFullRelease -PTINKER_ID=$CI_BUILD_ID -PBAK_PATH=$CI_PROJECT_DIR/app/build/bakApk -Paar=$JOB_COMPONENT_DEPENDENCIES -PMBD_RELEASE=$JOB_BUILD_RELEASE -PMBD_TEST_VERSION=$JOB_COMPONENT_VERSION -PMBD_BRANCH_NAME=$CI_COMMIT_REF_NAME --no-daemon

2.3 热修分支规范

MBD 操作拉取分支修复问题

移动团队达到一定规模后，需要同步制定相应的分支规范，其中热修相关的分支管理需要考虑两个问题：

1. 应该从哪个分支拉取代码修改打补丁？
2. 修复问题后热修代码合并问题？

这里有必要简单说明下：

有赞每次发版都会有开车的概念，所有待发布的功能都会上车合并到一个从master 分支拉出的 bus/${version}-${date}的分支，在 bus/${version}-${date}分支打出包后，开发同学自测然后交由项目的测试回归，没问题后，最后经App的测试同学回归，回归通过后开发同学会将 bus/${version}-${date} 分支合入master 构建 release 包。

由于考虑到也可能会拉分支对老版本发布热修，因此上述MBD构建成功后也会入库记录该 release版本构建时的 commit hash。

基于以上两点我们规定每个 release版本都有一个固定的热修分支为 hotfix/${version}-mbd，热修分支的管理也是直接由MBD构建平台统一规范处理的如图所示：

MBD 构建平台每个App构建，热修构建，SDK构建都是一个集成单（多次构建行为的集合，每次正式构建前都可能会有若干次测试构建），举例来说如 App2.3.5 版本发现问题需要热修复：

首先要在MBD 构建平台搜索 2.3.5版本的 release集成单， release集成单中包含一个热修复按钮
点击热修复按钮判断 2.3.5 版本是否已经存在 hotfix/2.3.5-mbd 分支？
存在直接创建热修复集成单，不存在MBD平台调用 GitLabAPI 创建 hotfix/2.3.5-mbd 分支
开发者在 hotfix/2.3.5-mbd 拉取创建修改问题的分支，如 hotfix/xxx_bugfix

至此解决了 应该从哪个分支拉取代码修改打补丁？ 的问题，合并到哪个分支的问题，暂且不表，下文会讲到。

2.4 补丁构建及保存

如上所述，热修构建也是在MBD平台完成的，由于之前app发版构建的产物已经打包
上传到了 CDN，再次构建时 MBD 平台只需把产物下载解压到 Tinker 基准包路径，
同App打包逻辑，热修构建也是通过 yaml脚本配置，指定要上传补丁文件的相对路径，补丁构建命令执行结束后会上传补丁文件到 CDN,用于后续补丁下发，简要过程如图：

补丁构建脚本

patch:
    artifacts:
        untracked: false
        name: "patch"
        preview_pattern: "patch_signed.apk"
        paths:
          - app/build/outputs/apk/full/tinkerPatch/full/release/patch_signed_7zip.apk
          - app/build/outputs/apk/full/tinkerPatch/full/release/patch_signed.apk
    script:
        - env
        - pwd
        - mv app/build/bakApk base/
        - ls base/
        - ./gradlew clean tinkerPatchFullRelease -Paar=$JOB_COMPONENT_DEPENDENCIES --no-daemon -POLD_BUILD_FLAVOR=$CI_PROJECT_DIR/base
        - rm -rf base

2.5 验证热修

补丁上传到CDN 后，为了确保下发的补丁没问题，需要验证补丁，这是至关重要的一步。那怎么加载补丁呢？Tinker 也提供了加载本地补丁包的 API ：

TinkerInstaller.onReceiveUpgradePatch(context, 补丁包的本地路径);

因此我们只需要把 CDN 文件下载到特定路径，在App重启时检测补丁文件是否已下载，如果已下载直接加载补丁即可。

验证补丁首先要考虑怎么方便开发者使用，步骤越少越快越好，因为通常发布热修本身就是非常紧急的问题，由于有赞内部有移动助手App（支持常用的开发功能，开发环境切换，抓包等）移动同学都会使用，因此可以把热修验证功能放在移动助手App。

从使用简便程度上来说，二维码似乎是不错的选择，因此我们定下的方案是，移动助手App 扫码获取二维码信息，二维码中包含：

补丁MD5 安全校验、签名
补丁 CDN 地址
补丁对应App版本及基准包 CDN 地址
补丁对应App包名

其中第[3]点用于检测验证热修的手机当前安装的版本是否是基准包，如果不是提示下载安装补丁对应基准包版本，避免浪费时间。

第[4]点用于补丁合成后，根据包名重启App，主要是考虑到 Tinker 的机制补丁本地合成后，需要再次冷启动使补丁生效。

移动助手App 扫码上图中的二维码后，请求补丁信息，执行拉取补丁本地合成补丁，如果合成成功后被热修App启动后会看到热修合成成功页面，否则不能明确的知道是否已热修合成，开发者会比较迷惑，同时为了方便多次合成测试的场景，比如第一次补丁问题没有修复，需要再次合成，也支持了清除补丁功能。如图所示：

2.6 发布策略

验证补丁没问题后，需要根据情况选定发布策略，目前支持三种热修发布策略

2.6.1 全量发布

全量发布，不用解释，补丁对应版本App所有用户都可拉取补丁

2.6.2 灰度发布

灰度下发支持按人数灰度与按比例灰度，按照人数灰度相对简单，因此这里只说下按比例灰度，灰度如果按照总人数的百分比进行下发，有可能会下发到不活跃用户的设备上，让百分比下发失去意义。目前一个简单的方式是实现哈希碰撞算法，概率可调，当App端请求补丁时，根据设备的唯一标识进行碰撞，落到概率区间内则下发补丁。

2.6.3 条件发布

很多时候在发布一个补丁时，需要在小范围内进行验证，比如特定某个系统版本或者特定某个用户；在验证通过后再进行全网用户的下发，这中场景下可以使用条件下发。

Apub 平台在发布补丁时可以选择使用条件下发，除上传补丁外，还可以填写条件语句，只有满足条件的设备才会执行修复补丁。

其中条件语句由 key/value/运算符 组成，条件语句的规则与代码中的条件表达式一致，支持 “==、!=、>、<、>=、<=、&&、||” 等运算符，如：

userId == 10023451 && roleType == 1

后端对DSL解析引擎可参考：https://developer.mozilla.org/zh-CN/docs/Mozilla/Projects/Rhino

另外特定版本的App 可能会发布多个补丁，如果结合使用多种下发补丁也会遇到些新的问题，举例来说如果先条件发布了一个补丁，再全量发布了另一个补丁App应该怎么处理？因此制定了App补丁使用规则：

若第一次下发补丁，包含了条件值，不符合条件的设备补丁不会生效。
若非第一次下发补丁，上一个补丁版本是全量下发，不符合条件的设备会请求上一个版本补丁。
若非第一次下发补丁，上一个补丁版本非全量下发(灰度/条件/开发)，不符合条件的设备若之前请求过补丁，会保留执行之前的补丁，若没有请求过补丁(新用户)，不会请求到补丁。

2.7 发布审批

在确定了补丁使用哪种发布方式后，还需要由指定人（通常为TL）统一收敛权限，同时对热修代码做二次检查（Code review） ，有赞不会允许未经复核检验的热修代码随意的发布线上，万一出了问题，可能会影响大量用户。

对于有赞权限管理感兴趣读者的可以看这篇文章《有赞权限与审批流程的标准化》

引用上文中举的例子说明：如果 A 同学需要修改 App2.3.5 版本的问题，发布热修复。

开发者需要从 hotfix/2.3.5-mbd拉取 hotfix/xxx_bugfix 分支
在 hotfix/xxx_bugfix分支修改问题并构建补丁
接着申请发布补丁，在审批通过之后，发布热修的同学在 Apub平台上操作下发在 MBD平台构建并上传到 CDN的补丁

仔细想想，是不是遗漏了什么？还记得上文说到热修分支规范时，修复问题后热修代码的合并问题么？

为了避免开发者在修改问题后直接发布补丁，代码忘记合并导致后续版本也有问题的情况，同时也为了规范管理热修分支。如图：

Apub 发布平台在 A 发起审批时，自动创建了 hotfix/xxx_bugfix->hotfix/2.3.5-mbd 的 MR 并自动写入审批单申请理由中。
在 A点击下发补丁时调用 GitLabAPI 获取 MR 状态，如果 MR 已合并则允许下发，否则提示 A 催促审批人合并代码才可下发补丁
最后下次发版时将 hotfix/2.3.5-mbd 分支添加到下一趟发版列表中，将 bug 修复代码带到下一趟车中，最终合入 master

2.8 热修数据统计

补丁下发后，还需要实时观察热修生效情况，如果有问题要及时暂停下发或回滚补丁，有赞热修提供了基础的数据统计，包含已修复设备数量，合并失败错误统计等。

2.9 设备热修状态查询

在某些场景下，可能需要查询特定用户或特定用户账号的热修状态

常见的一种情况是：

用户反馈了个线上问题，开发同学确认问题并修改发布补丁后，悻悻的回复用户已经修复了，重复杀掉App打开几次即可。用户说好我试试，过了一段时间，又反馈说还是有问题啊，但是明明已经发布热修复了（头皮发麻），这时就可以根据用户账号信息查询热修状态了，如下图。

2.10 热修代码回溯

还有一些特殊情况，历史版本里发布的热修复导致了新的问题，需要确认问题责任人，或者排查特定问题，需要排除热修代码的影响，需要查看该版本发布的热修复代码。

针对该情况，我们把上文中发起审批时创建的MR落库记录，并提供了查看代码变更按钮，点击按钮直接跳转记录的 GitLabMR, 即可查看代码变更。

三、平台架构及流程

3.1 热修平台架构

上面讲的内容比较多也比较杂，可以结合热修平台架构图来看，有个全局的视角：

3.2 热修流程梳理

最后我们还以上文中的例子回顾下分享的内容，有赞发布热修复的流程：

Android 发布热修流程

开发者在 MBD平台搜索需要热修版本的集成单，点击热修复按钮，MBD会创建 hotfix/2.3.5-mbd 分支，同时创建一个热修集成单（MBD 构建平台每个App构建，热修构建，SDK构建都是一个集成单）
开发者需要从 hotfix/2.3.5-mbd拉取创建 hotfix/xxx_bugfix 分支
在 hotfix/xxx_bugfix分支修改问题提交代码并在MBD平台创建的热修集成单上操作构建补丁
然后使用有赞移动助手App 扫码验证补丁
接着在Apub发布平台选择热修发布方式，填写申请发布理由申请发布补丁，Apub 平台会自动创建 hotfix/xxx_bugfix -> hotfix/2.3.5-mbd 的 MR，并把 MR地址自动填充到申请理由中，开发者等待审批，审批通过之后，确认 MR合并，即可发布操作下发补丁

iOS 发布热修流程

上文很少提及iOS 热修复，主要是因为iOS 热修相对简单，没有 Android基准包等复杂逻辑：

根据具体问题，编写热修脚本，通过iOS 热修SDK，本地运行调试
调试通过后在 Apub平台上传热修脚本，并选择热修发布方式，填写申请发布理由申请发布补丁，iOS 侧由于修复机制等原因，没有自动创建 MR 等逻辑
审批通过之后，即可下发补丁

四、总结

本文主要介绍了有赞的热修复平台，及在搭建过程中遇到的一些问题。热修平台实现了高效、稳定、可靠的热修复补丁上传、验证、分发、权限管理等功能，并提供补丁基本数据统计，可以直接复用到各业务线，避免重复建设。

有赞热修复平台，是结合有赞移动团队实际开发过程遇到的问题，逐步解决逐渐完善的，读者可以结合自身团队打造合适的热修复管理平台，希望有赞热修复平台的建设经验可以对你有所帮助。

如果你有比较好的建议，可以评论回复，如有任何问题，欢迎指正。

本文转载自公众号有赞coder（ID：youzan_coder）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455761058&idx=1&sn=e7296c9a1e0f3e9a72fd4a0b8b246d06&chksm=8c687687bb1fff91faf37ca84044bb90a5ddbe55dd80bbccef30f361549ecf1f81364d9516ac&scene=27#wechat_redirect

创作场景

有赞移动热修复平台建设