有赞移动热修复平台建设

‍

作者：李子

部门：电商技术中心

一、背景

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, 脚本如下：

代码语言：javascript复制


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

代码语言：javascript复制

2.3 热修分支规范

MBD 操作拉取分支修复问题

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

代码语言：javascript复制

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,用于后续补丁下发，简要过程如图：

补丁构建脚本

代码语言：javascript复制

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 ：

代码语言：javascript复制

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

代码语言：javascript复制

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 等逻辑
审批通过之后，即可下发补丁

四、总结

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

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

cdn android sdk git ide

0 人点赞