移动热修复产品白皮书

第一章 产品简介

移动热修复（Hotfix）系统主要针对已上线的APP，出现产品问题，通过服务端下发修复包到客户端，客户端进行安装修复。此过程中，无需用户额外操作，可快速达成紧急问题修复的目的。热修复是基于Tinker框架，通过对修复包与基准包进行差异化对比，自动并下发补丁包到客户端，当客户端加载修复后的包后，完成修复目的。进而实现无需发版即可快速修复，用户无任何感知。

第二章 产品特性

2.1 修复无需发版

后台配置修复包，下发成功后，客户端将在运行到修复业务时自动进行安装修复，客户端无需发版，业务用户无感知即可修复问题。

2.2 方案稳定合规

热修复系统基于Tinker框架进行实现，技术实现可靠，系统运行稳定。整体方案对接入方业务无影响，测试正常上线审核无违规。

2.3 多重修复策略

通过后台配置策略，实现定向人群、灰度放量、渠道、版本机型组合等多种组合方式进行修复，提供修复版本快速回滚功能。

2.4 数据可视化

修复包安装数、修复成功数等重要数据可按照版本快速查询展示，第一时间掌握版本修复情况。

第三章 应用场景

3.1 修复线上问题

支持代码、资源及So库的动态下发，如果线上出现崩溃、逻辑错误、功能遗漏等问题，热修复可以帮您最大程度的迅速挽回损失。

3.2 快速验证业务

支持新增Activity，您可以通过热修复在不发版的情况下进行小规模的业务验证，不必再通过灰度发版验证效果，省时省力。

第四章 总体设计

4.1 产品架构

4.2 部署架构

第五章 主要功能

5.1 创建热修复

创建热修复主要需要三个步骤。
第一步，填写基础包信息。基础包信息包括要修复的目标版本号与build号。
第二步，上传补丁文件。上传成功后，补丁文件将会自动解析相关信息，需注意，上传的补丁文件后缀为.jdpatch。 第三步，配置相关策略。可选择按照发布目标进行修复，其中包含：全量、按比例（即灰度形式）、定向人员（输入/粘贴指定人员名单，选择渠道、修复API版本、机型等，设置完成后，点击发布，开始修复。

5.2 数据查看

点击热修复列表中，对应修复版本后的数据详情（周期为30天），可查看对应的版本的热修复数据。已回滚的版本，仅能查看修复期间的数据。

5.3 回滚功能

当修复版本发布后，需要取消并删除当前客户端安装或未安装的修复包，可使用回滚功能。回滚后，当前修复包将不再下发。同时，当前已安装的修复包客户端将自动卸载，未安装的将删除安装包。回滚后，可查看该版本的相关信息，但不能再次发布或修改。

第六章 部署环境要求

6.1 硬件要求

根据日活1000w，QPS 峰值6w估算：

• 热修复客户端上报API，用于接收客户端获取补丁信息以及上报安装数和下载数，单个4C8G容器可支持约3000 QPS；
• 1000w日活，大约部署4个4C8G容器可满足需求。

6.2 软件要求

6.2.1 操作系统

建议CentOS 7.4以上；

6.2.2 中间件依赖