全面了解Android热修复技术

WeTest 导读

本文探讨了Android热修复技术的发展脉络，现状及其未来。

---

热修复技术概述

热修复技术在近年来飞速发展，尤其是在InstantRun方案推出之后，各种热修复技术竞相涌现。国内大部分成熟的主流APP都拥有自己的热修复技术，像手淘、支付宝、QQ、饿了么、美团等等。

目前能搜集到的资料，大多简单罗列每个方案的特点并进行横向比较，而其中技术发展的脉络往往被掩盖了。热修复技术从何而来，又将往何处去？在这些资料中都找不到答案。

我认为，走马观花地看一遍各家的热修复方案并不能找到答案，所以写下本文，希望从一个不同的角度来了解热修复技术，权当抛砖引玉，如有不足，欢迎指正。

代码热修复

代码热修复是最常见，也是热修复中最重要的部分，因为程序错误往往都是代码逻辑的错误。最初的热修复方案也仅支持代码热修复。代码热修复分两个流派，即腾讯系的类加载方案和阿里系的底层替换方案，前者需要重启应用但却能修复大部分错误，后者及时生效却只能作方法内的修改。下面详细介绍。

一、类加载方案

1、Qzone 
Qzone的超级热修复方案是业界最早的热修复方案之一，原理简单而巧妙，影响深刻而久远，在此简单介绍。Android类加载的源码如下: 

可以看出当有多个dex文件时，他们会组成一个有序数组，按顺序加载，而对于一个已经加载的Class是不会再次加载的，由此得出热修复方案：把需要修复的类打包成一个dex文件下发，并在APP启动时通过反射，将这个dex文件放在dexElements的最前面，这样修复了的Class就会比有Bug的Class优先加载了。如下图所示： 

但在实现过程中，会遇到unexpected DEX problem异常，Qzone方案为了解决这个问题采用了插桩的策略来规避这个异常。实际上，Android系统的检查和优化都是有其意义的，因此这种方法在Dalvik和Art上都会遇到问题。

● 在Dalvik虚拟机，APP在安装的时候会被执行dexopt操作，同一个dex文件内的Class会被打上CLASS_ISPREVERIFIED标志，而补丁包中的类并没有打上此标志，因此抛出异常。解决方法就是在第一次打包APK时让所有类都引用另一个dex文件中的类，这样所有的类始终不会打上CLASS_ISPREVERIFIED标志，因此补丁包可以顺利加载，但是Dalvik虚拟机在检测到一个类未打上CLASS_ISPREVERIFIED之后会再次在类加载的时候进行dexopt相关的操作，如果一次性加载很多类，速度将明显变慢。

● 在Art虚拟机，dex文件最终会编译成本地机器码，在dex2oat时fast *已经将各个类的地址写死，若补丁包中的类出现字段或者方法的修改，会出现内存地址错乱，解决办法是将这个类的父类和调用这个类的类都加入补丁包。但这样会导致补丁包急剧增大。(实际上要理解清楚这个问题需要熟悉Dalvik和Art的完整流程，并非三言两语能解释清楚)

这两个问题都可以解决，但都要付出一些代价：类加载速度或者补丁包大小。

2、Tinker 
如果Qzone没有上面两个缺陷，或许就不会有Tinker了。对于微信这样一个对性能有极高要求的产品来说，Qzone的缺点会被无限放大。在参考Instant Run的冷插拔与buck的exopackage后，Tinker采用了全量替换的策略。全量替换可以避免插桩和地址写死问题，但是补丁包会很大，因此可以在新旧两个Dex的差异放在补丁包中，下发到移动端后再在本地合成完整的dex文件。

实际上，Tinker保留了Qzone最核心的东西：反射修改dexElements。无论是插入还是替换，本质都是利用了类加载的特点。由于需要下发的全量补丁包体积过大，Tinker采用了后台求diff，下发diff文件，移动端合成全量包的策略。

如果仅此而已，只要有diff/patch算法，就可以开发Tinker了。实际上，确实如此。而Tinker第二个创新之处就是采用了自研的DexDiff算法，大大优化了下发差异包的大小。

二、底层替换方案

阿里的Andfix热修复方案是底层替换方案的代表，与Qzone和Tinker的思想完全不同，Andfix通过修改一个方法的入口地址来达到修复。以Dalvik虚拟机为例，Andfix的核心代码如下： 

其实就是修改了方法包括入口地址在内的每一项数据的地址，使之指向一个新的方法。在后台，使用Andfix提供的apkpatch工具，可以得到补丁文件out.apatch，这个文件记录了哪些方法需要修改，以及修改后的方法。Andfix效果： 

（注意我一直在点击，下发补丁后发生了变化……）

资源修复

除了代码热修复，资源热修复也很常见。各大主流方案在资源修复的实现上大多参考了InstantRun的实现方式，因此本章节先讨论了InstantRun，再分析了基于InstantRun所实现的热修复。

一、InstantRun

InstantRun在AndroidStudio2.0.0中引入。

InstantRun包括代码修复和在资源修复，资源修复的核心代码: 

其实做了两件事： 
1. 通过反射替换掉原有的AssetManager 
2. 找到引用了原AssetManager对象的字段并替换为新的引用。

关键是要熟悉Android相关源码，才能确定哪些字段是需要更新引用的。通过以上两步即可实现资源替换。

二、资源热修复实现

将InstantRun的monkeyPatchExistingResource方法引入我们的代码就可以实现资源热修复，效果如下:

SO库热修复

so库的修复本质是对native方法的修复和替换，和类加载方案类似，可以把补丁so库的路径插入到nativeLibraryDirectories数组的最前面，使得优先加载补丁库而不是原来的库来达到修复目的。在此不做赘述。

热修复的稳定性

一、兼容的困境

最初Qzone就需要在Dalvik平台进行插桩，Tinker同样也是分平台合成（在Dalvik平台合成全量Dex，在Art平台合成需要的小Dex），而阿里的Andfix作为底层热修复方案，不仅要面对两种虚拟机平台，甚至要为不同Android版本编写一套替换逻辑，如下： 

二、不安全的代码

加载了补丁包的程序本质还是未编译的程序，只是两个已编译程序的结合体，由于Java的编译过程对于我们是透明，所以我们一不小心就会引入错误，而且这种错误十分隐蔽。在使用类加载方案时由于还是在Java层，可能不那么容易犯错，但使用Andfix等底层热修复方案时却总是防不胜防。

比如，Java在编译匿名内部类时会编译成顶级类，命名方式为ClassNamen，其中n为匿名内部类出现的顺序，所以在第i个匿名内部类前面添加匿名内部类就会导致ClassNamei#methodName变成ClassName$i+1#methodName，即一个方法的地址发生改变。再比如，Java的泛型编译可能会在编译期引入新的方法，也会导致Andfix的异常。 
因为编译过程是透明的，所以热修复后的程序不能代替修复问题后重新编译出来的程序，即热修复后程序的安全性是得不到保证的。

热修复技术展望

Qzone时期插桩影响了类加载的速度，Tinker的DexDiff算法粒度过细、实现复杂，导致性能消耗严重，Andfix使用场景有限、兼容性差，此外美团的Robust、饿了么的Amigo等也都各有限制。Android热修复技术虽然百花齐放，但却并没有哪种方案能够解决所有问题，统一当前的局面。而最近阿里又推出了Sophix，针对各种类型的修复又做了深度的优化，虽然没有开源代码，但是发布了《深入探索Android热修复技术原理》，引起Android社区的关注，其统一各种热修复方案的意图也十分明显。

从Qzone到Tinker，从Andfix到Sophix都可以看出来，热修复技术还在不断上升发展，每一次新方案的推出都是对原有方案的超越。但目前来看，阿里并未打算开源Sophix，而Tinker2.0仍然在路上，热修复技术在性能、兼容、开发透明方面仍然有很多不足，所以不能仅仅满足于了解已有方案，还要深入源码去理解原理，更要对业界最新进展保持关注。

---

参考：

1、安卓App热补丁动态修复技术介绍 
2、微信Tinker的一切都在这里，包括源码(一) 
3、alibaba/AndFix: AndFix is a library that offer hot-fix for Android App. 
4、Instant Run: How 
5、微信Android热补丁实践演进之路 
6、Tencent/tinker: Tinker is a hot-fix solution library for Android, it ……

腾讯WeTest兼容性测试团队积累了10年的手游测试经验，旨在通过制定针对性的测试方案，精准选取目标机型，执行专业、完整的测试用例，来提前发现游戏版本的兼容性问题，针对性地做出修正和优化，来保障手游产品的质量。目前该团队已经支持所有腾讯在研和运营的手游项目。

iPhone8/iPhoneX新机即将同步上线，欢迎进入：http://wetest.qq.com/product/expert-compatibility-testing 使用专家兼容测试服务。 WeTest兼容性测试团队期待与您交流！You Create，We Test！

如果对使用当中有任何疑问，欢迎联系腾讯WeTest企业qq：800024531