Android HotFix

What is HotFix?

以补丁的方式动态修复紧急Bug，不再需要重新发布App，不再需要用户重新下载，覆盖安装(来自：安卓App热补丁动态修复技术介绍)
HotFix原理
首先HotFix原理是基于Android Dex分包方案的,而Dex分包方案的关键就是Android的ClassLoader体系。ClassLoader的继承关系如下：

ClassLoader继承关系

这里我们可以用的是PathClassLoader和DexClassLoader,接下来看看这两个类的注释：

PatchClassLoader/*** Provides a simple {@link ClassLoader} implementation that operates on a list* of files and directories in the local file system, but does not attempt to* load classes from the network. Android uses this class for its system class* loader and for its application class loader(s).*/

这个类被用作系统类加载器和应用类(已安装的应用)加载器。

DexClassLoader/*** A class loader that loads classes from {@code .jar} and {@code .apk} files* containing a {@code classes.dex} entry. This can be used to execute code not* installed as part of an application.*/

注释可以看出，这个类是可以用来从.jar文件和.apk文件中加载classed.dex，可以用来执行没有安装的程序代码。
通过上面的两个注释可以清楚这两个类的作用了，很显然我们要用的是DexClassLoader，对插件化了解的小伙伴们对这个类肯定不会陌生的，对插件化不了解的也没关系。下面会更详细的介绍。
我们知道了PathClassLoader和DexClassLoader的应用场景，接下来看一下是如何加载类的，看上面的继承关系这里两个类都是继承自BaseDexClassLoader，所以查找类的方法也在BaseDexClassLoader中，下面是部分源码：

/** * Base class for common functionality between various dex-based * {@link ClassLoader} implementations. */public class BaseDexClassLoader extends ClassLoader {     /** structured lists of path elements */     private final DexPathList pathList;     //...some code     @Override     protected Class<?> findClass(String name) throws ClassNotFoundException {         Class clazz = pathList.findClass(name);         if (clazz == null) {             throw new ClassNotFoundException(name);         }         return clazz;     }    //...some code}

可以看到在findClass()方法中用到了pathList.findClass(name)，而pathList的类型是DexPathList，下面看一下DexPathList的findClass()方法源码：

/** * A pair of lists of entries, associated with a {@code ClassLoader}. * One of the lists is a dex/resource path — typically referred * to as a "class path" — list, and the other names directories * containing native code libraries. Class path entries may be any of: * a {@code .jar} or {@code .zip} file containing an optional * top-level {@code classes.dex} file as well as arbitrary resources, * or a plain {@code .dex} file (with no possibility of associated * resources). * * <p>This class also contains methods to use these lists to look up * classes and resources.</p> *//*package*/ final class DexPathList {     /** list of dex/resource (class path) elements */     private final Element[] dexElements;    /**     * Finds the named class in one of the dex files pointed at by     * this instance. This will find the one in the earliest listed     * path element. If the class is found but has not yet been     * defined, then this method will define it in the defining     * context that this instance was constructed with.     *     * @return the named class or {@code null} if the class is not     * found in any of the dex files     */     public Class findClass(String name) {         for (Element element : dexElements) {             DexFile dex = element.dexFile;             if (dex != null) {                 Class clazz = dex.loadClassBinaryName(name, definingContext);                 if (clazz != null) {                     return clazz;                 }             }         }         return null;     }}

这个方法里面有调用了dex.loadClassBinaryName(name, definingContext)，然后我们来看一下DexFile的这个方法：

/** * Manipulates DEX files. The class is similar in principle to * {@link java.util.zip.ZipFile}. It is used primarily by class loaders. * <p> * Note we don't directly open and read the DEX file here. They're memory-mapped * read-only by the VM. */public final class DexFile {    /**     * See {@link #loadClass(String, ClassLoader)}.     *     * This takes a "binary" class name to better match ClassLoader semantics.     *     * @hide     */     public Class loadClassBinaryName(String name, ClassLoader loader){         return defineClass(name, loader, mCookie);     }     private native static Class defineClass(String name, ClassLoader loader, int cookie);}

好了，关联的代码全部贴上了，理解起来并不难，总结一下流程：BaseDexClassLoader中有一个DexPathList对象pathList，pathList中有个Element数组dexElements（Element是DexPathList的静态内部类，在Element中会保存DexFile的对象），然后遍历Element数组，通过DexFile对象去查找类。
更通俗的说：

一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件，然后从当前遍历的dex文件中找类，如果找类则返回，如果找不到从下一个dex文件继续查找。(出自安卓App热补丁动态修复技术介绍)
so，通过上面介绍，我们可以将patch.jar(补丁包)，放在dexElements数组的第一个元素，这样优先找到我们patch.jar中的新类去替换之前存在bug的类。
方案有了，但是我们还差一个步骤，就是防止类被打上CLASS_ISPREVERIFIED的标记
解释一下：在apk安装的时候，虚拟机会将dex优化成odex后才拿去执行。在这个过程中会对所有class一个校验。校验方式：假设A该类在它的static方法，private方法，构造函数，override方法中直接引用到B类。如果A类和B类在同一个dex中，那么A类就会被打上CLASS_ISPREVERIFIED标记。A类如果还引用了一个C类，而C类在其他dex中，那么A类并不会被打上标记。换句话说，只要在static方法，构造方法，private方法，override方法中直接引用了其他dex中的类，那么这个类就不会被打上CLASS_ISPREVERIFIED标记。(引用自Android热补丁动态修复技术（二）：实战！CLASS_ISPREVERIFIED问题！)
O..O..OK，现在很清楚了，实现热修复，我们需要完成两个任务：
改变BaseDexClassLoader中的dexElements数组，将我们的patch.jar插入到dexElements数组的第一个位置。
在打包的时候，我们要阻止类被打上CLASS_ISPREVERIFIED标记

HotFix框架汇总
RocooFix(推荐)
Nuwa
HotFix
AndFix
Tinker_imitator(微信热更新方案实践)

RoccoFix使用问题
RocooFix的正确教程，不生成patch.jar请按这个步骤来执行
待更新

参考
安卓App热补丁动态修复技术介绍
Android dex分包方案
Android 热补丁动态修复框架小结
Android热补丁动态修复技术（一）：从Dex分包原理到热补丁
Android热补丁动态修复技术（二）：实战！CLASS_ISPREVERIFIED问题！
Android热补丁动态修复技术（三）—— 使用Javassist注入字节码，完成热补丁框架雏形（可使用）
Android热补丁动态修复技术（四）：自动化生成补丁——解决混淆问题

文／zyyoona7（简书作者）
原文链接：http://www.jianshu.com/p/6f0ae1e364d9
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。