Android 面试—深入理解Android类加载机制

前言

任何一个java程序都是由一个或者多个class文件组成，在程序运行时，需要将class文件加载到JVM中才可以使用，负责加载这些class文件的就是java的类加载机制。ClassLoader的作用简单的来说就是加载class文件，提供给程序运行时使用，每个Class对象的内部都有一个ClassLoader字段来标识自己是由哪个Classloader加载的。

Java与Android类加载机制的区别

我们都知道Java中JVM虚拟机加载的是Class文件，而DVM和ART加载的是Dex文件，所以java的类加载器和Android的类加载器是不一样的。Java中的类加载器主要有系统加载器和自定义加载器两种类型。系统类加载器主要是Bootstrap ClassLoader、Extensions Classloader和Application Classloader这3种。Android中的Classloader类型和java中一样，也分为系统加载器和自定义加载器两种。系统类加载器主要包括3种，分别是BootClassloader、PathClassloader和DexClassLoader这三种，接下来我们就来简单的了解一下Android中的类加载器。

Android中的类加载器

在这里插入图片描述

BaseDexClassLoader：实现应用层类文件的加载，真正的加载逻辑委托给PathList来完成。
PathClassLoader：继承自BaseDexClassLoader，加载系统类和应用程序的类，通常用来加载已安装的apk的dex文件，实际上外部存储的dex文件也能加载。
DexClassLoader：继承自BaseDexClassLoader，可以加载dex文件以及包含dex的压缩文件（apk，dex，jar，zip），不管加载哪种文件，最终都要加载dex文件。Android8.0之后和PathClassloader无异。
BootClassLoader：Android系统启动时会使用BootClassLoader来预加载常用类，它继承自ClassLoader，是顶层的父加载器parent。

PathClassLoader & DexClassLoader的异同

PathClassLoader构造方法：

public PathClassLoader(String dexPath,String librarySearchPath,ClassLoader parent){
	super(dexPath,null,librarySearchPath,parent);
}

DexClassLoader构造方法：

//android 8.0之前
public DexClassLoader(String dexPath, String optimizedDirectory,String librarySearchPath,ClassLoader parent){
	super(dexPath,new File(optimizedDiretory),librarySearchPth,parent);
}

//android 8.0之前
public DexClassLoader(String dexPath,String optimizedDirectory,String librarySearchPath,ClassLoader parent){
	super(dexPath,null,librarySearchPath,parent);
}

dexPath： dex文件以及包含dex的apk文件或者jar文件的路径集合，多个路径用文件分隔符分隔，默认文件分隔符为“:”。
optimizedDerectory: Android系统将dex文件进行优化后所生成的ODEX文件的存放路径，该路径必须是一个内部存储路径。在一般情况下，使用当前应用程序的私有路径：data/data/< Package Name> /...。
librarySearchPath: 所使用到的C/C++库存放的路径
parent: 父加载器

从构造方法可以看出DexClassLoader和PathClassLoader的实现逻辑基本一样，其实二者都可以加载指定路径的apk、jar、zip、dex，区别在于DexClassLoader多了一个optimizedDirectory参数，optimizedDirectory参数就是dexopt的产出目录(odex)。那PathClassLoader创建时，这个目录为null，就意味着不进行dexopt？并不是，optimizedDirectory为null时的默认路径为：/data/dalvik-cache。optimizedDirectory这个参数在API26的时候被谷歌废弃掉了，可以看到DexClassLoader中即使传递了这个参数，在super调用中，传递的值也是null，而且查看PathClassloader和DexClassLoader的super调用，会发现代码是一样的，那么也就是说在Android8.0之后，这两个ClassLoader是没有区别的。

dex和odex区别： 一个APK是一个程序压缩包，里面有个执行程序包含dex文件，ODEX优化就是把包里面的执行程序提取出来，就变成ODEX文件。因为你提取出来了，系统第一次启动的时候就不用去解压程序压缩包，少了一个解压的过程。这样的话系统启动就加快了。为什么说是第一次呢？是因为DEX版本的也只有第一次会解压执行程序到/data/dalvik-cache（针对PathClassLoader）或者optimizedDirectory(针对DexClassLoader）目录，之后也是直接读取目录下的的dex文件，所以第二次启动就和正常的差不多了。当然这只是简单的理解，实际生成的ODEX还有一定的优化作用。ClassLoader只能加载内部存储路径中的dex文件，所以这个路径必须为内部路径。

双亲委托介绍

类加载器在查找Class的时候采用的就是双亲委托机制，双亲委托就是在加载.Class文件的时候，首先会判断该Class文件是否被自身加载，如果没有加载的话会委托给父加载器parent去进行查找而不是让自身去加载，委托给父加载器之后父加载器会去判断自己是否有加载过这个文件，如果有加载，那么就直接返回，如果这个文件没有被加载的话，那么会继续向上委托给更上一级的父加载器去加载，直到达到链路的顶层ClassLoader，如果顶层ClassLoader也没有加载这个文件的话，那么顶层ClassLoader就会尝试自己去加载这个文件，如果加载失败，就会逐级向下交给它的子加载器加载这个文件，以此类推，如果最后都没有找到的话，才会交给自身去查找，其实双亲委派机制就是一个递归的过程。

Android双亲委派机制的实现

在这里插入图片描述

Android中的ClassLoader和java中一样，同样遵循了双亲委托机制来加载，查看Classloader.java中的loadClass能够看出：

1、首先调用findLoadedClass检查传入的类是否已经被加载，如果已经加载那么就直接返回。

2、如果第一步中类没有被加载（c == null），那么就会判断parent是否等于null，也就是判断父加载器是否存在，如果父加载器存在，就调用父加载器的loadClass方法。

3、如果父加载器不存在就会调用findBootstrapClassOrNull，这个方法会直接返回null。

4、如果到了第4步依然c == null，那么表示在向上委托的过程中，没有加载该类，会调用findClass继续向下进行查找。

接下来我们引用一个例子再总结说明一下整个加载流程：

在这里插入图片描述
上图中创建了一个DexClassLoader对象，使用DexClassLoader进行加载一个类，参数中的parent我们传入了context.getClassLoader，这里就等于DexClassLoader的parent我们给它传的是PathClassloader，所以此时的父子关系是DexClassLoader——>PathClassLoader——>BootClassLoader，也就是DexClassLoader的parent为PathClassloader，PathClassloader的parent为BootClassloader，需要注意的是这里的parent并不是继承关系，比如PathClassloader继承自BaseDexClassLoader，但是PathClassloader的parent为BootClassLoader，二者并不冲突。下面使用一张流程图来进行总结。
在这里插入图片描述

双亲委派的作用

避免重复加载，如果已经加载过一次Class，就不需要再次加载，而是直接读取已经加载的Class。
对于任意一个类确保在虚拟机中的唯一性，由加载它的类加载器和这个类的全类名一同确立其在Java虚拟机中的唯一性。不同的类加载器加载同一个class文件得到的不是同一个class对象
安全，保证系统类.class文件不能被篡改。通过委托方式可以保证系统类的加载逻辑不会被篡改。假如我们自定义一个String类来替代系统的String类，就会造成安全隐患，但是使用双亲委托就会使得系统的String类在Java虚拟机启动时就被加载，也就无法通过自定义String类来替代系统的String类。
只有当两个类名完全一致并且被同一个类加载器所加载的类，Java虚拟机才会认为它们是同一个类。

类的加载过程

可以看到在所有父ClassLoader无法加载Class时，则会调用自己的findClass()方法。其实任何ClassLoader子类，都可以重写loadClass()与findClass() 。一般如果你不想使用双亲委托，则重写loadClass()修改其实现。而重写findClass()则表示在双亲委托下，父ClassLoader都找不到Class的情况下，定义自己如何去查找一个Class。如果没有重写的话，那findClass()是在BaseDexClassLoader中实现的。我们来看一下findClass()中的实现逻辑。

在这里插入图片描述
这里省略了部分代码，可以看到调用了pathList的findClass()方法，pathList就是DexPathList对象，在BaseDexClassLoader初始化的时候被创建。接下来进入DexPathList。

在这里插入图片描述
可以看到DexPathList在创建的时候调用了makeDexElements()方法来创建出了dexElements数组，在makeDexElements之前我们先来看一下splitDexPath()方法，在这个方法中将dexPath目录下的所有程序文件转变成一个File集合，而且dexPath是一个用冒号作为分隔符把多个程序文件目录拼接起来的字符串，如 /data/dexdir1:/data/dexdir2:...。makePathElements方法核心作用就是将指定路径中的所有文件转化成DexFile同时存储到到Element[]这个数组中。接下来进入DexPathList的findClass()方法中。

在这里插入图片描述

在findClass()方法中会通过for循环不断的遍历dexElement数组，拿到element，然后调用element的findClass()，Element是DexPathList的内部类，dexElements是维护dex文件的数组，每一个Element对应一个dex文件。DexPathList遍历dexElements，从每一个dex文件中查找目标类，在找到后即返回并停止遍历。继续往下看，进入element的findClass()方法。