Android热修复基础篇（二）

2024-04-11 08:57:13

热修复系列文章

在 Android热修复基础篇（一）中我们讲了热修复的基本概念和四种常见热修复解决方案的原理，最后，我们会发现他们都有一个共同特点：那就是玩到最后都是对 dex 文件进行操作。

想要把 dex 文件玩明白，这篇文章你的读下去！！！

类加载过程中所用到的类

如何查看你调用的某个类由哪个 classloader 加载？

ClassLoader mainClassLoader = MainActivity.class.getClassLoader();
ClassLoader appCompatClassLoader = AppCompatActivity.class.getClassLoader();
ClassLoader activityClassLoader = Activity.class.getClassLoader();

System.out.println("mainClassLoader -> " + mainClassLoader);
System.out.println("appCompatClassLoader -> " + appCompatClassLoader);
System.out.println("activityClassLoader -> " + activityClassLoader);

I/System.out: mainClassLoader -> dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.wust.jingdutiao-jnlJr4sTotwg6ttws9yYFw==/base.apk"],nativeLibraryDirectories=[/data/app/com.wust.jingdutiao-jnlJr4sTotwg6ttws9yYFw==/lib/arm64, /system/lib64, /product/lib64]]]
    appCompatClassLoader -> dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.wust.jingdutiao-jnlJr4sTotwg6ttws9yYFw==/base.apk"],nativeLibraryDirectories=[/data/app/com.wust.jingdutiao-jnlJr4sTotwg6ttws9yYFw==/lib/arm64, /system/lib64, /product/lib64]]]
I/System.out: activityClassLoader -> java.lang.BootClassLoader@9e062e4

运行结果分析：

BootClassLoader 类加载器是加载 Android 系统自带的类，如 Activity
PathClassLoader 类加载器是加载第三方类或自己写的类，（不是Android自带的），如 MainActivity、AppCompatActivity

补充点：现在你应该明白了，为什么你写的类直接调用就好了，这是因为系统帮你选择好了类加载器自动帮你把需要的类加载进来，即类加载过程代码如下（系统自动替你完成了）：

getClassLoader().loadClass() //在这里只是表明类加载逻辑，实际加载过程没这么简单

PathClassLoader源码分析

源码展示

public class PathClassLoader extends BaseDexClassLoader {
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }

    public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }
}

源码分析

源码里面只包含两个构造方法
构造方法中 ClassLoader parent 传的是 BootClassLoader

由于 PathClassLoader 源码太简单，没有找到我们想要的 loadClass() 方法，所以我们来看看其父类 BaseDexClassLoader，发现还是没有，继续找父类 ClassLoader，在这里面我们看到了loadClass()

//发现了两个 是重载方法 
public Class<?> loadClass(String name) throws ClassNotFoundException {
        //可以看到 最后还是调到了 含两个参数的 loadClass 方法，
        return loadClass(name, false);
}

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
            // First, check if the class has already been loaded
            //找缓存 
            //1、在Android中 class 存在于 dex file 中
            //2、public PathClassLoader(String dexPath, ClassLoader parent) 第一个参数就是就是 dex 文件的存放路径
            //3、所以 classLoader 在加载类的时候 是通过 IO 操作将文件读进来 ，然后按照 dex 格式解析出每一个类！
            //4、为了避免你重复用一个类的时候反复 IO读取+解析 所以，先找缓存
            Class<?> c = findLoadedClass(name);

            //如果没找到 缓存 则进入 if语句
            if (c == null) {
                try {
                    if (parent != null) {
                        //1、前面我就告诉过大家 parent =》 BootClassLoader 
                        //2、也就是说 先在 BootClassLoader 里找类
                        c = parent.loadClass(name, false);
                    } else {
                        //如果你的 parent==null  系统调用findBootstrapClassOrNull方法查找，看方法名字就知
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    //如果还是没找到 那就只能自己找了
                    c = findClass(name);
                }
            }
            return c;
    }

源码分析注释已经写得很清楚了，在这里面就涉及到传说中的双亲委托机制

为什么要用这种双亲委托机制？

定义：某个类加载器在加载类时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成委托加载任务，就成功返回；只有父类加载器无法完成加载任务或者没有父类加载器时，才自己去加载。

使用原因：

避免重复加载，当父类加载器已经加载了该类的时候，就没必要子ClassLoader在加载一次。

举例：加载 MainActivity 时肯定得加载其父类 Activity，而 Activity 是由父加载器 BootClassLoader 加载了，那你不用双亲委托机制，非得 PathClassLoader 自己去加载，那不是重复了吗！！！

安全性考虑，防止核心API库被随意篡改。

举例：String类我们都知道是系统自带的是由 BootClassLoader 加载，而你不用双亲委托机制，非得用 PathClassLoader 加载，那不是加载到你写的 String类了，这样很不安全！！！

双亲委托机制是我们本段内容的一个小插曲，我们回归主题，看一下 PathClassLoader 的 findClass() ,(PathClassLoader 源码很简单，当然没有我们想要的，所以我们得看其直接父类的（BaseDexClassLoader）实现)

public class BaseDexClassLoader extends ClassLoader {
   /*什么是DexPathList呢？解释如下：*/
/**
 * A pair of lists of entries, associated with a {@code ClassLoader}.
 * One of the lists is a dex/resource path &mdash; typically referred
 * to as a "class path" &mdash; 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  look up
 * classes and resources.</p>
 */

/*这是关联一个ClassLoder 的条目列表，这其中有dex/resource path
通常称为“class path” ，其他名称目录包含本地代码库，class path条目
可能是包含一个可选的*class.dex的zip文件，jar文件，以及任意资源
*/

    private final DexPathList pathList;

/*重写了ClassLoder的这个方法，这个方法会在loadClass中调用，当loadClass时，具体步骤是这样的：
先查找已经加载的类，如果有返回，如果没有，用父装载器去加载这个类，如果失败，则会调用我们重写的findclass这个方法*/

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
        Class c = pathList.findClass(name, suppressedExceptions);
        if (c == null) {
            ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
            for (Throwable t : suppressedExceptions) {
                cnfe.addSuppressed(t);
            }
            throw cnfe;
        }
        return c;
    }
}

附上DexPathList源码：

final class DexPathList {
/**
* List of dex/resource (class path) elements.
* Should be called pathElements, but the Facebook app uses reflection
* to modify 'dexElements' (http://b/7726934).
*    注意了啊：这里是一个数组 所以 dex 文件遍历是有顺序的
*    [patch.dex,classes.dex,classes2.dex]
*     patch.dex 得放到最前面，你放到后面就没用了，最先找到的还是你那个有错误的 dex
*/    
      private final Element[] dexElements;


      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;
    }
}

到此为止，类的加载源码已经分析完了，下面我们通过几个问题来帮大家梳理一下

1、类是怎么被加载的？

解：由于是加载你自己写的类，所以，我们定位到 PathClassLoader 这个类，为了找到 loadClass() 这个方法，我们得看 PathClassLoader 的父类 ClassLoader，在这里我们分析知道了其运用了双亲委托机制，先在父类加载器 BootClassLoader里找，由于是我们自己写的类，BootClassLoader 肯定找不到，于是，我们来分析 PathClassLoader 的findClass() 方法，这还是得看父类 BaseDexClassLoader 的 findClass() 方法，从源码中我们可以看到，真正查找类是由 DexPathList pathList.findClass() 完成的，在它源码里面，是遍历了每个 dexFile 来查找我们调用的类（Element 是DexFile的包装类）。

所以，一句话概括就是：类是通过类加载器遍历 dexFile 而加载的

2、怎么使用补丁包中的类？

解：把你的补丁包（patch.dex），放到 dexElements 数组的 最前面，最前面，最前面！！！原因如下：

3、已经被加载过的类还能够替换修复吗?

解：当然不行啊！！！，已经被加载 === 有缓存了，缓存里能找到这个类，后面的方法都不执行了啊。

这里就是为什么 Tinker 和 QZone 热修复解决方案得重启才行。重启就是为了清理缓存，让所有类重新加载，避免因为错误的类在缓存中导致正确的类不被加载！！！

4、怎样保证正确class的dex先加载?

同2问

码农公寓

热修复系列文章

类加载过程中所用到的类

如何查看 你调用的某个类 由哪个 classloader 加载？

PathClassLoader源码分析

相关文章

如何查看你调用的某个类由哪个 classloader 加载？