Android热修复原理

一. AndFix

AndFix的原理就是方法的替换，把有bug的方法替换成补丁文件中的方法。

注：在Native层使用指针替换的方式替换bug方法，已达到修复bug的目的。

AndFix采用native hook的方式，这套方案直接使用dalvik_replaceMethod替换class中方法的实现。因为它并无总体替换class, 而field在class中的相对地址在class加载时已肯定，因此AndFix没法支持新增或者删除filed的状况(经过替换init与clinit只能够修改field的数值)。Andfix能够支持的补丁场景相对有限，仅仅可使用它来修复特定问题。 二. QZone（插桩方式）

该方案基于的是android dex分包方案的, 简单的归纳一下，就是把多个dex文件塞入到app的classloader之中，可是android dex拆包方案中的类是没有重复的，若是classes.dex和classes1.dex中有重复的类，当用到这个重复的类的时候，系统会选择哪一个类进行加载呢？  让咱们来看看类加载的代码：

一个ClassLoader能够包含多个dex文件，每一个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件，而后从当前遍历的dex文件中找类，若是找类则返回，若是找不到从下一个dex文件继续查找。

理论上，若是在不一样的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类，以下图：

在此基础上，咱们构想了热补丁的方案，把有问题的类打包到一个dex（patch.dex）中去，而后把这个dex插入到Elements的最前面，以下图：

三. 微信Tinker（差量包）

Instant Run的冷插拔与buck的exopackage或许能给咱们灵感，它们的思想都是全量替换新的Dex。

咱们能够将新旧两个Dex的差别放到补丁包中，最简单咱们能够采用BsDiff算法。

简单来讲，在编译时经过新旧两个Dex生成差别path.dex。在运行时，将差别patch.dex从新跟原始安装包的旧Dex还原为新的Dex。这个过程可能比较耗费时间与内存，因此咱们是单独放在一个后台进程:patch中。为了补丁包尽可能的小，微信自研了DexDiff算法，它深度利用Dex的格式来减小差别的大小。 4、阿里Sophix

原理(双剑合璧)：

1.优化Andfix（突破底层结构差别，解决稳定性问题）：

---

Andfix底层ArtMethod结构时采用内部变量一一替换，却是这个各个厂商是会修改的，因此兼容性很差。

Sophix改变了一下思路，采用总体替换方法结构，忽略底层实现，从而解决兼容稳定性问题。

2.突破QQ和Tinker的缺陷

---

QQ和Tinker的缺陷

Sophix对dex的解决方案

• Dalvik下采用阿里自研的全量dex方案：不是考虑把补丁包的dex插到全部dex前面（dex插桩），而是想办法在原理的dex中删除（只是删除了类的定义）补丁dex中存在的类，这样让系统查找类的时候在原来的dex中找不到，那么只有补丁中的dex加载到系统中，系统天然就会从补丁包中找到对应的类。
• Art下本质上虚拟机以及支持多dex的加载，Sophix的作法仅仅是把补丁dex做为主dex（classes.dex）而已，至关于从新组织了全部的dex文件：把补丁包的dex更名为classes.dex，之前apk的全部dex依次改成classes2.dex、classes3.dex ... classesx.dex，以下图所示。

3.资源修复另辟蹊径

---

经常使用方案（Instant Run技术）：这种方案的兼容问题在于替换AssetManager的地方

Sophix资源修复方案

4.SO修复另辟蹊径

---