百川解码精彩回顾：热修复的坑和阿里的解

热修复是很多开发者关心的技术，8 月 27 日晚，阿里百川组织了“百川解码”在线直播，以“热修复的坑和阿里的解”为主题，邀请了三位业界嘉宾对热修复技术进行了探讨，并介绍了阿里百川全面接受公测的热修复解决方案：阿里百川HotFix ，就网友提出的相关问题进行了解答。本文是此次直播的精彩回顾。

嘉宾简介

歩川，阿里巴巴资深开发工程师，《让App 像Web 一样发布新版本》一文作者，在OPPO 从事Android Framework 两年，腾讯QQ 空间工作一年半，热衷研究安卓热补丁方案。目前在手机淘宝终端架构，主要负责动态部署增强和优化、存储相关工作。

刘昭，中华英才网Android 技术负责人，具有丰富的移动开发经验，崇尚开源社区文化，关注性能优化、研发效率、热修复、插件化、数据驱动等，善于评估技术方案，解决疑难杂症。

泽胤，阿里巴巴无线技术专家，阿里百川HotFix 项目负责人，无线事业部初创技术员工之一。经历阿里巴巴无线技术从小到大的整个过程，参与过多个无线的重要项目，包括无线的H5 建站，无线统一接入层，阿里的无线PUSH 系统，以及第一版的Android 客户端等。主要技术方向是在线高并发和高可用性的维护与实现。

1. 热修复是什么

刘昭认为，热修复是在应用的 App 包发布到市场之后，出现了 Bug，无需替换包来进行在线更新的一种技术，对用户是无感知的。

泽胤认为，谈到热修复，就应该和动态部署的概念进行区分。热修复是特指对微小改动进行修复的一个技术，它强调快速和无感的修复。而动态部署会复杂更多，它涵盖的东西也更多，但核心的技术还是热修复技术。

步川认为，热修复可以从技术上来理解并和动态部署进行区分。他提到，目前广义上有两种方案可以实现代码的替换，一种是类的替换，基于 Classloader，另一种是方法的替换，而这两种方式各有优缺点。

• 方法的替换：只能替换方法的内容，所以不能够对要 patch 的类进行方法的新增和删除；但同时，方法的替换可以在应用不重启的情况下实现。它包小、快速、功能单一、比较轻量，这种方案是热修复。
• 类的替换：可以修改类结构，功能更加的强大；但是必须要重启一次才会有效，因为已经加载过的类是不能够被替换的。这种方案叫做“动态部署”。它几乎能够适应任何代码的变更，所以很适合进行业务功能的迭代。

2. 热修复技术对比

目前，业内有很多的热修复方案，步川就热修复技术向观众进行了对比讲解。他提到，从广义上来讲，热修复的实现方式可以被分为类的替换和方法的替换。

类的替换

如图 1 所示，APK 包中包含了代码和资源，代码存放在 classes.dex 中，资源存放在 APK 的 res 目录下，系统会通过 ClassLoader 装载 classes.dex 来进行类加载。如果有多个 classes.dex，那么这多个 classes.dex 会在 ClassLoader 中会用数组的形式来进行组织，然后从前往后进行遍历查找。

图 1

一种具体的方案如图 2 所示，是利用多 dex 从前往后遍历的有序特性，把 patch.dex 插入到数组的最前面，对 patch 进行有限查找，达到替换的目的，这时候就会出现 preverify 问题，为了绕过这个问题，就必须往每个类的构造函数里面进行插桩防止安装期间的校验，把校验从编译期间移动到了运行期间，导致运行期间每加载一个类，都要进行校验和优化，降低了运行性能。

图 2

刘昭认为，这种方案利用了 ClassLoader，思想是比较好的，但是如果工程中的类比较多，就会在性能上造成比较大的影响。同时，有可能会导致 patch 包比较大。

步川提到，为了解决上述性能问题，出现了另一种方案，如图 3 所示：就是全量替换 dex，下发一个 patch.dex，然后把原来的 dex 和下发的 patch.dex，合成一个新的全量 dex，这个 dex 会全量替换原来的 dex，最终本质上也只会在这个全量的 dex 中查找，从而不会出现 preverify 问题，所以这种方案不用插入构造函数，不会影响性能。但是，这种方案的包也可能会比较大，只改动了一行代码，也必须合成一个全量的 dex，如图 4 所示，然后再 dexopt 出一个全量的 odex。

图 3

图 4

方法的替换

如图 5 所示，方法的替换的原理如下：在 Android 底层，有个数据结构记录着类的信息，比如成员变量的个数，方法的个数，每个方法的 code 执行地址，程序运行的时候会根据这个地址跳转到具体的 code 区域执行代码。方法的替换就是替换这些地址，把地址指向另一个类的方法，从而达到了替换的目的。这种方式的包比较小，而且也不需要插桩来影响性能，但是它无法修改类的结构（比如方法数的增删），而且有可能会有兼容性问题，例如厂商修改了类和方法的底层结构。

图 5

所以基于他们的优点和限制，区分热修复和动态部署这两种场景，可以在这两种不同的情况下，选择最优的方案，达到修复的目的。

3. 如何选择热修复技术方案

刘昭认为，热修复技术方案的选择应该对应具体的使用场景。在 patch 包的数量、大小方面，HotFix 是占优势的；但是 HotFix 不能新增类、新增字段（下文泽胤有回应），从这个角度考虑，ClassLoader 更好，但是会有一定的性能损耗；合成 dex 的方式，则需要知道用户手机的 ROM 有多大，能不能提供 20 多 M 的空间来。

4. 基于 AndFix 的阿里百川 HotFix 做了哪些优化工作

阿里百川 HotFix 是基于 AndFix 的，泽胤提到，手机淘宝（下文简称“手淘”）对于 Andfix 实践了大约一年左右，在工程和技术上做了一些改善，提高了其在稳定性、周边工具链的性能和稳定性等方面的表现，使得这项技术更加成熟，同时也解决了不能新增类等问题，并成功落地手淘 App。

具体的优化工作包括：在产品化方面，接入简单，2 行代码即可接入，一般开发者 1 个小时即可完全跑通流程，大大降低工程成本；提供了相对完善的周边工具链，通过后台操作自由控制 patch 发布，最大化保证用户体验。针对 patch 打包慢的问题进行优化，持续在工具链方面进行优化；在“打包工具交互”方面，开发了一个独立的可执行文件，可以在工程里面，用 GRADLE、ANT 中集成，甚至在 JENKINS 里面去执行，提高了灵活性。

在安全方面，泽胤也做了说明：第一，阿里会提供一个私有 RSA 加密的功能，开发者在本地打出包以后用自己的 RSA 密钥对中的私钥加密，然后上传百川平台，再在 SDK 中放置自己的公钥作为解码用，这样上传的内容完全加密确保绝对的信息安全，且不会被阿里看到；第二，传输层面，在设计上采用两级的加密，动态密钥和静态密钥相结合，因此网络拦截无法窃取到包内容。

5. 热修复的未来

从商业价值上来讲，开发者目前非常需要热修复技术，所以有一定的价值，但是未来，如果官方提供相应的功能，或者说 React Native 等技术减弱了开发者对热修复技术的依赖，则会对热修复的技术产品造成冲击。对于这样的情况，泽胤认为，作为技术人员，要不断学习进步。一项技术如果没有了被使用的价值，那么它是应该被淘汰掉的，例如历史上很多编程语言或者技术的消亡。泽胤表示，产品的迭代和消亡也是很正常的。很乐意看到有新的，满足开发者需求的技术可以代替老的技术。

步川认为，从方案讲，热修复和动态部署不是互相排斥的，在特定的场景下两者都可以做到最优，配合使用更佳。手淘同时使用这两项技术，用热修复解决 Bug，用动态部署来迭代业务，相互配合好则会达到很完美的状态。

刘昭提出，Android Studio 2.0 之后，提供了 Instant Run 这样的功能，从思想上来讲是非常好地解决了热修复 patch 的问题，之后的热修复有没有可能借鉴其思想？对于这个问题，步川认为，Instant Run 的更新力度比较大，同时又在代码中增加了预埋逻辑，侵入性比较大。若基于 Class Loader 来开发一个工具，或许会更简单。

6. 阿里百川 HotFix 开始公测

泽胤提到，市场上缺少阿里百川 HotFix 这样的产品，虽然热修复原理解析很多，但是真正难的是把这项技术做成熟、做稳定。基于手淘 App 这个大平台，由工程实践出来的阿里百川 HotFix 产品，可以推出独立的服务来满足市场上的需求。泽胤提到，阿里百川会有专门的团队持续跟进该产品，解决问题，吸纳用户意见。

在当天的直播中，嘉宾们还回答了网友们的提问。感兴趣的读者可以关注阿里百川社区论坛。

阿里百川HotFix 从直播当晚开始正式进行公测，感兴趣的读者可以到阿里百川官网了解。

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。