热修复技术分为几部分：
原理介绍
Android HotFix源码分析
自定义框架
1.Android分包MultiDex原理
首先Dex是什么东西？
Dex就是Window里面的exe文件 也就是可执行问题。
Android没有用传统的Java虚拟机，而是使用dalvik虚拟机。当APK安装到手机后，dalvik会先把de文件转化位ODEX文件，
优化结构。
在早期的android系统中，为了优化dex，所有的method会存放在一张表里面，表的大小位short，也就是65535（65K）
But现在android代码非常多，超过65K很正常，这个时候就需要一种解决方案来解决这个问题。
简单来说就是将编译好的class文件分拆成2个dex文件，绕过65k的限制。
关于分包的具体实现，可以参考dex分包方案概述与multidex包的配置使用
2.Android热补丁修复技术原理
目的：有时候需要修改几行代码，但是我们需要重发各个市场，重新release等。是不是可以只是简单的打patch就可以解决这个问题呢？
首先来看dex加载的源码：
public Class findClass(String name, List<Throwable> suppressed) {
for (Element element : dexElements) {
DexFile dex = element.dexFile; if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
每个element对应的就是dex文件，所以加载class就是从一个个dex文件中找到对应的code。but，可以发现，一旦找到成功了以后，就直接return。
也就是说如果2个dex含有相同的class，会先返回前面那个。
so 我们的解决方案来了，使用一个新的dex，让他在element文件表的最前面，这样我们修改的class文件就会被首先加载进来。
理论上，如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类，如下图：
在此基础上，我们构想了热补丁的方案，把有问题的类打包到一个dex（patch.dex）中去，然后把这个dex插入到Elements的最前面，如下图：
好，该方案基于第二个拆分dex的方案，方案实现如果懂拆分dex的原理的话，大家应该很快就会实现该方案，如果没有拆分dex的项目的话，可以参考一下谷歌的multidex方案实现。然后在插入数组的时候，把补丁包插入到最前面去。
But 我们发现在插入patch.dex后，会报错，原因是CLASS_ISPREVERIFIED。这是个什么东东？
在类的方法中直接引用的类，如果在同一dex中，就会被打上CLASS_ISPREVERIFIED这个标志。
我们单独给一个AntilazyLoad类打包成hack.dex 这样每个class里面都调用。我们在构造函数里面添加：
public class A{
public A（）
{
system.println(AntilazyLoad.class);
}
}
So,这样A就引用了不在一个dex里面的class，从而不会被打上CLASS_ISPREVERIFIED的代码。进而不会出现问题。
参考：
http://my.oschina.net/853294317/blog/308583
http://blog.csdn.net/lmj623565791/article/details/49883661
