从15年开始各技术大佬们开始研究热修复技术，并陆续开源了许多的热修复框架。如 Jasonross 的 Nuwa，美团的 Robust，阿里的 Andfix，腾讯的 Tinker 等等…均是Android 前辈们夜以继日的成果。而现在热修复被广泛地应用于Android 应用和游戏，运用并理解热修复框架在面试中也是加分项。
实现原理 1. Nuwa 实现原理最早看到热修复框架的相关文章就是Qzone官方的文章，但是Qzone热修复技术的实现代码并没有开源。不过GitHub上有一开源的热修复框架Nuwa，实现原理和其相似。这里我们以Qzone为例进行分析。
Qzone的实现原理是生成差分dex文件，将patch.dex插到dexElements的最前面。但patch.dex中的类patchA.java和classes.dex中的类classesB.java会相互引用，如果这两个类所在的patch.dex和classes.dex不是同一个文件就会报错。
疑惑的Qzone技术大佬发现classes.dex和classes2.dex也不是同一个文件，为啥不报错？于是继续查，发现了这个判断
if(!fromUnverifiedConstant && IS_CLASS_FLAG_SET(referrer, CLASS_ISPREVERIFIED)){
如果被引用者（也就是classesB.java）这个类被打上了CLASS_ISPREVERIFIED标志，那么就会进行dex的校验。校验不过就报错了。
那么这个标志是什么时候被打上去的？ 在apk安装的时候，虚拟机会将dex优化成odex后才拿去执行。在这个过程中会对所有class进行校验。
怎么校验的？ 假设 classesB.java类在它的static方法，private方法，构造函数，override方法中直接引用到classesC.java类。如果classesB.java类和classesC.java类在同一个dex中，那么classesB.java类就会被打上CLASS_ISPREVERIFIED标记，被打上这个标记的类不能引用其他dex中的类，否则就会报错。所以要防止类被打上CLASS_ISPREVERIFIED的标志。
// 校验引用者 ClassB 和被引用者 PatchA 的 dex 是否相同，不同则报错
if(referrer->pDvmDex != resClassCheck->pDvmDex &&
resClassCheck->classLoader != NULL)
如何防止类被打上CLASS_ISPREVERIFIED的标志？ Common类会被打包成单独的hack.dex，这样当安装apk的时候，classes.dex内的类都会引用一个在不相同dex中的Common类，这样就防止了类被打上CLASS_ISPREVERIFIED的标志了，只要没被打上这个标志的类都可以进行打补丁操作。
优点：
- 开发透明，简单；
- 热修复成功率高。
缺点：
- 在Art 上表现为补丁包较大；
- 在Dalvik 上性能消耗较大。
更多实现细节请看 Android 热修复Nuwa的原理及Gradle插件源码解析
2. 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 的对象，这样就会去执行补丁包中的方法了。
大致流程图如下所示：A_old 表示未被修复的原有类，A_new 表示已修复的新类。 
优点
- 兼容性高，开发透明；
- 实时生效。
缺点
- 会增大方法数，影响运行效率；
- 暂不支持 so 文件和资源的替换。
Andfix 采用的方法是，在已经加载了的类中直接在 native 层替换掉原有方法，是在原来类的基础上进行修改的。其核心在于 replaceMethod 函数，所以只支持方法替换，对于方法的增删，资源更新，so 文件更新及类和属性的替换等都是不支持的。
Andfix 的实现偏 native 层，笔者能力有限，其具体实现过程，就不妄加总结了。
更多实现细节请看 Andfix 官网文章
优点
- 立即生效，消耗低；
- 补丁包较小。
缺点
- 仅支持方法替换；
- 兼容性不佳，对部分机型暂不支持。
在 App 运行到一半的时候，所有需要发生变更的 Class 已经被加载过了，在Android 上是无法对一个 Class 进行卸载的。而 Tinker 的方案，都是让 Classloader 去加载新的类。如果不重启，原来的类还在虚拟机中，就无法加载新类。因此，只有在下次重启的时候，在还没走到业务逻辑之前抢先加载补丁中的新类，这样后续访问这个类时，就会 Resolve 为新的类。从而达到热修复的目的。
Tinker 的实现过程更像是在 Qzone 热修复方案上做优化。核心点是性能最优，消耗最低。
经 Tinker 开发人员调研，Qzone 的方案最大挑战在于性能，即Dalvik平台存在插桩导致的性能损耗，Art平台由于地址偏移问题导致补丁包可能过大的问题。为了避免这两个问题，根据 Instant Run 的全量替换新的 Dex 的思路，于是决定将新旧两个Dex 的差异放到补丁包中。
经过调研，BsDiff 算法对 Dex 支持效果不太好，所以，Tinker 开发团队人员自研了 DexDiff 算法。
最终， BsDiff 加载 so 和部分资源文件，DexDiff 加载 Dex文件，以达到性能最优。但是这个方案也有缺点，就是占用 ROM 较大。好吧！现在手机内存都不小，多几十 M 可以接受。 优点
- 补丁包较小，消耗较小；
- 开发透明，文档丰富。
缺点
- 占用 ROM 较大；
- 需要重启才能生效。
更多实现细节请看 Android 热修复 Tinker接入及源码浅析
