Android热修复原理

Android应用经常会遇到App上线后发现Bug需要紧急修复，如果将修复Bug后的应用重新提交应用商店进行审核升级，首先会遇到应用商店审核需要时间，还可能会出现审核不通过的情况，其次还得提示用户进行升级，有的用户可能还不愿意升级，如果应用包比较大，下载需要时间比较长，用户升级的意愿进一步降低。如果能有一种技术可以只将修复Bug涉及到的相关文件打包上传到服务器，客户端只需要下载少量文件就能完成Bug的修复，就会避免上面所说的几个问题。应市场需求，Android热修复应运而生。

Android热修复方案基本分为两种：

• 类替换方案
• Native修改Filed指针替换方法
  本文主要讲第一种类替换的方式。

类加载机制

说起Android热修复就不得不提类加载机制，Android是基于Java进行开发的，首先说一下Java的类加载机制。

双亲委托机制

Java的类加载是通过ClassLoader进行完成的，ClassLoaer 的加载机制是一种特别聪明的方式，双亲委托机制，在这种机制下，一个Class只会被加载一次。这里需要明白的一点是对于一个ClassLoader（类加载器）来说，将一个具体的类（class）加载到内存中其实是由虚拟机完成的。Java中的类加载主要分为4种：

• Bootstrap ClassLoader：加载Java虚拟机运行时所需要的系统类，如java.lang.、java.uti.等这些系统类
• Extensions ClassLoader：用于加载 Java 的拓展类，主要实现系统类之外的额外功能
• App ClassLoader：负责加载当前应用程序Classpath目录下的所有jar和Class文件
• Custom ClassLoader： 自定义的类加载器

Android的类加载器

在Android中类的加载也是通过ClassLoader来完成，具体来说就是PathClassLoader 和 DexClassLoader。实现Android热修复需要了解以下四个类：

• PathClassLoader：只能加载已经安装到Android系统中的apk文件（/data/app目录），是Android默认使用的类加载器。
• DexClassLoader：可以加载任意目录下的dex/jar/apk/zip文件，这里可以是我们热修复需要用到的补丁文件。
• BaseDexClassLoader：PathClassLoader和DexClassLoader共同的父类。
• DexPathList：将热修复补丁文件封装成Element对象，并将这些对象添加到一个Element的数组集合dexElements中去。

其中PathClassLoader、DexClassLoader这两个类都是继承自BaseDexClassLoader，在BaseDexClassLoader的构造函数中对DexPathList进行初始化。

    public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(parent);
        this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }

热修复简单实现原理

在App出现Bug后，可以将修复完Bug的几个类打包成一个补丁文件，然后通过DexClassLoader找到补丁文件路径将补丁文件加载到内存中，在DexPathList初始化完成后，通过DexPathList将补丁文件封装出一个Element对象，并且将这个Element对象插到原有dexElements数组的最前端。当DexClassLoader去加载类时，优先会从我们插入的这个Element中找到相应的类，虽然那个有bug的类还存在于数组中后面的Element中，但由于双亲加载机制的特点，这个有bug的类已经没有机会被加载了，这样一个bug就在没有重新安装应用的情况下修复了。

热修复原理.png