Android 热修复技术（1）---原理

热修复技术分为几部分：

原理介绍

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 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的代码。进而不会出现问题。

参考：

安卓App热补丁动态修复技术介绍

http://my.oschina.net/853294317/blog/308583

http://blog.csdn.net/lmj623565791/article/details/49883661