Android热更新框架简单比较

1、Tinker

Tinker 的方案，都是让 Classloader 去加载新的类。如果不重启，原来的类还在虚拟机中，就无法加载新类。因此，只有在下次重启的时候，在还没走到业务逻辑之前抢先加载补丁中的新类，这样后续访问这个类时，就会 Resolve 为新的类。从而达到热修复的目的。

Tinker 开发团队人员自研了 DexDiff 算法。 BsDiff 加载 so 和部分资源文件，DexDiff 加载 Dex文件，以达到性能最优。但是这个方案也有缺点，就是占用 ROM 较大。

2、AndFix

AndFix采用的是替换ArtMethod结构体中的字段，这样会有兼容问题，因为厂商可能会修改ArtMethod结构体，导致方法替换失败。Sophix采用的是替换整个ArtMethod结构体，这样不会存在兼容问题。
底层替换方案直接替换了方法，可以立即生效不需要重启。采用底层替换方案主要是阿里系为主，包括AndFix、Dexposed、阿里百川、Sophix。Sophix是AndroidFix的升级方案，目前可以集成阿里的SDK来实现；

3、Robust

Robust 插件对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码。通过判断 if(changeQuickRedirect != null) 来确定是否进行热修复，当 changeQuickRedirect 不为 null 时，调用 patch.dex 中同名类的同名方法达到 hotfix 的目的。

生成的patch.dex 中有两个主要类，PatchesInfoImpl.java 和修复后的同名类 APatch.java。客户端拿到patch.dex 后，用DexClassLoader 加载patch.dex，反射拿到PatchesInfoImpl.java 这个 class。并创建这个class 的一个对象。然后通过这个对象知道被替换的是谁，给它的变量changeQuickRedirect 赋值为 patch.dex 中的 APatch 的对象，这样就会去执行补丁包中的方法了。

实现原理