一、背景：
如果发布了一个release包，但是里面出现了严重的事故级别(某些等不及下一版本迭代就得修复)的bug，那么站在公司角度，这边QA，开发，客服，甚至PR等部门都得加班赶忙发包重现覆盖，耗费的资源代价相当的大，而出问题的或许只是一两行代码；站在用户User角度，刚刚下载了一个包，准备尝鲜，发现又让更新，是不是很烦，如果新包打开就崩溃了，很多就会去市场评论，“垃圾，更新之后闪退”云云，抑或“垃圾，天天要更新”。
在这个基础上热更新技术出现了，即使发出了release包，如果出现某些等不及下一版本迭代就得修复的bug，向用户下发Patch，在用户无感知的情况下，修复了bug或问题。
二、类型：
花了几天查阅一些资料，去了解一些目前的热更新方案，主要有以下两大类型：
1、【基于native hook方案】
Dexposed(from 淘宝)
AndFix (from 支付宝)
无需重启Application、无需启动Activity即可更新Java方法 安卓代码要达到真正“热”更新的效果，也只有基于AOP这种技术，就是在方法级别这个粒度做替换。
2、【基于multidex的热更新框架】
ClassLoader(originally from qq空间团队 –原始)
在它之后和他有相同原理的其他热门开源库有：
Nuwa
HotFix
DroidFix
Tinker(来自微信)
需要重启Activity或重启Application达到更新效果。
3、【基于Instant Run原理】
Robust
前两个都会存在一些兼容性问题，为此美团借鉴了Instant Run原理，推出Android热更新方案Robust
三、对比
基于native hook的方案：需要针对dalvik虚拟机和art虚拟机做适配，需要考虑指令集的兼容问题，需要native代码支持，兼容性上会有一定的影响；但是无需重启Application、无需启动Activity即可更新Java方法。
基于Multidex的方案，需要反射更改DexElements，改变Dex的加载顺序，这使得patch需要在下次启动时才能生效，实时性就受到了影响，同时这种方案在android N [speed-profile]编译模式下可能会有问题，可以参考Android N混合编译与对热补丁影响解析
各大热补丁方案分析和比较
四、具体原理
【Dexposed】
基于exposed的AOP框架，方法级粒度，可以进行AOP编程、插桩、热补丁、SDK hook等功能。是真正程度上的热更新。无需重启Application、无需启动Activity即可更新Java方法。基于AOP这种技术，就是在方法级别这个粒度做替换。
我们知道，应用启动的时候，都会fork zygote进程，装载class和invoke各种初始化方法，Xposed就是在这个过程中，替换了app_process，hook了各种入口级方法（比如handleBindApplication、ServerThread、ActivityThread、ApplicationPackageManager的getResourcesForApplication等），加载XposedBridge.jar提供动态hook基础。方法级的替换是指，可以在方法前、方法后插入代码，或者直接替换方法。只能针对java方法做拦截，不支持C的方法。
缺点：
1.不支持AndroidRuntime（5.0+）
2.如果线上release版本进行了混淆，那写补丁也是一件很痛苦的事情，需要反射写混淆后的代码，粒度太细，要替换的方法多的话，工作量会比较大。反射+内部类，可能还有包名和内部类的名字冲突，总而言之就是写得很痛苦。
【AndFix】
同样是方法的hook，AndFix不像Dexposed从Method入手，而是以Field为切入点。
【ClassLoader】
其他相同原理开源库链接:Nuwa， HotFix，DroidFix，Tinker。
Classloader的原理就和上面两个不一样了，参考文章安卓App热补丁动态修复技术介绍，以及Android dex分包方案，所以这俩篇务必要看。这里就不对三个框架做过多对比了，因为原理都一致，实现的代码可能差异并不是特别大。
总结一下就是：
一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件，然后从当前遍历的dex文件中找类，如果找类则返回，如果找不到从下一个dex文件继续查找。
把多个dex放进app的classloader之中，从而使得所有dex的类都能被找到。而实际上findClass的过程中，如果出现了重复的类，改变类加载的实现，是会使用第一个找到的类的。
如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类。所以我们可以把有问题的类打包到一个dex（patch.dex）中去，然后把这个dex插入到Elements的最前面。
只要把有问题的类修复后，放到一个单独的dex，通过反射插入到dexElements数组的最前面，就可以让虚拟机加载到打完补丁的class了。
但在实践中，会发现运行加载类的时候报preverified错误，原来在DexPrepare.cpp，将dex转化成odex的过程中，会在DexVerify.cpp进行校验，验证如果直接引用到的类和clazz是否在同一个dex，如果是，则会打上CLASS_ISPREVERIFIED标志。通过在所有类（Application除外，当时还没加载自定义类的代码）的构造函数插入一个对在单独的dex的类的引用，就可以解决这个问题。空间使用了javaassist进行编译时字节码插入。总结起来就是两点，第一是动态改变BaseDexClassLoader对象间接引用的dexElements，第二是在app打包的时候，阻止相关类去打上CLASS_ISPREVERIFIED标志。
