源码分析基于Android 28
1.BootClassLoader，PathClassLoader，DexClassLoader区别
BootClassLoader，用来加载Framework的class文件，例如Activity、Service；
PathClassLoader，用来加载指定的dex、jar、zip、apk中class文件；
DexClassLoader，作用跟PathClassLoader一样。
2.常用的类都是由哪些加载器加载的呢？
自定义的MainActivity是由PathClassLoader加载的；
Framework的Activity是由BootClassLoader加载的；
AppCompatActivity是由PathClassLoader加载的；
String是由BootClassLoader加载的；
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
viewDataBinding = DataBindingUtil.setContentView(this, R.layout.activity_main);
Log.d(TAG, "MainActivity classLoader=" + MainActivity.class.getClassLoader());
Log.d(TAG, "Activity classLoader=" + Activity.class.getClassLoader());
Log.d(TAG, "Activity classLoader=" + AppCompatActivity.class.getClassLoader());
Log.d(TAG, "String classLoader=" + String.class.getClassLoader());
}
很多人都认为AppCompatActivity属于Google提供的，应该由BootClassLoader加载才对啊，这里为什么会跟Activity不一样呢？其实是因为AppCompatActivity是通过依赖包添加的，不在Framework中，可以将它理解一个第三方库，所以由PathClassLoader加载。
2020-06-30 10:41:55.433 17291-17291/com.yang.match D/MainActivity: MainActivity classLoader=dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.yang.match-IORgTSlCsYVXoz6eMXbPsg==/base.apk"],nativeLibraryDirectories=[/data/app/com.yang.match-IORgTSlCsYVXoz6eMXbPsg==/lib/arm, /system/lib, /vendor/lib]]]
2020-06-30 10:41:55.433 17291-17291/com.yang.match D/MainActivity: Activity classLoader=java.lang.BootClassLoader@4c0dd39
2020-06-30 10:41:55.434 17291-17291/com.yang.match D/MainActivity: AppCompatActivity classLoader=dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.yang.match-IORgTSlCsYVXoz6eMXbPsg==/base.apk"],nativeLibraryDirectories=[/data/app/com.yang.match-IORgTSlCsYVXoz6eMXbPsg==/lib/arm, /system/lib, /vendor/lib]]]
2020-06-30 10:41:55.434 17291-17291/com.yang.match D/MainActivity: String classLoader=java.lang.BootClassLoader@4c0dd39
3.PathClassLoader跟DexClassLoader作用一样？
看下PathClassLoader的构造函数，
（1）dexPath，指定的dex、jar、zip、apk文件绝对路径；
（2）librarySearchPath，dex文件中需要用到的so库路径；
（3）parent，父ClassLoader；
public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
super(dexPath, null, librarySearchPath, parent);
}
再看下DexClassLoader的构造函数，
（1）dexPath，指定的dex、jar、zip、apk文件绝对路径；
（2）optimizedDirectory，dex文件经过opt优化后的 odex文件输出的路径；
（3）librarySearchPath，dex文件中需要用到的so库路径；
（4）parent，父ClassLoader；
public DexClassLoader(String dexPath, String optimizedDirectory,
String librarySearchPath, ClassLoader parent) {
super(dexPath, null, librarySearchPath, parent);
}
两者的构造函数大同小异，只不过DexClassLoader多了一个optimizedDirectory而已，而且两者都是继承BaseDexClassLoader，所有方法的实现都在父类，所以说两者作用一样：
都可以加载 指定的dex、jar、zip、apk文件。
而且在Android 26、25、24、23上的表现也都是一样的。
4.类加载过程
以使用DexClassLoader加载Activity为例，假设Activity重来没有加载过，有两点需要注意的
（1）DexClassLoader、PathClassLoader、BootClassLoader的loadClass方法都是继承父类的，所以逻辑一样；
（2）DexClassLoader的parentClassLoader是PathClassLoader，PathClassLoader的parentClassLoader是BootClassLoader，而BootClassLoader的则为空，一般这么配置的；
DexClassLoader.loadClass
主要工作：
（1）findLoadedClass，Activity没有加载过，返回null；
（2）调用PathClassLoader.loadClass，也进入findLoadedClass，因为Activity没有加载过，还是返回null；
（2）调用BootClassLoader.loadClass，也进入findLoadedClass，因为Activity没有加载过，还是返回null，BootClassLoader没有父类，所以调用findBootstrapClassOrNull，但是该方法默认返回null，所以执行findClass由自己加载Activity；
（3）Activity类返回给PathClassLoader，PathClassLoader返回给DexClassLoader，这就完成了一次加载过程；
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {{
c = findBootstrapClassOrNull(name);
}
}
if (c == null) {
c = findClass(name);
}
}
return c;
}
双亲委派机制可以简单的理解为，先通过parent来加载class文件，如果加载不到，才自己加载。
DexClassLoader加载流程.png
dex文件中的class是如何加载到内存？
主要看BaseDexClassLoader.findClass
主要工作：
调用pathList.findClass来加载类，
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
Class c = pathList.findClass(name, suppressedExceptions);
......
return c;
}
DexPathList.findClass
主要工作：
遍历dexElements数组，调用 element.findClass来加载类，
public Class<?> findClass(String name, List<Throwable> suppressed) {
for (Element element : dexElements) {
Class<?> clazz = element.findClass(name, definingContext, suppressed);
......
}
Element.findClass
主要工作：
这里才是真正加载.class文件的地方，loadClassBinaryName最终会调到native方法；
public Class<?> findClass(String name, ClassLoader definingContext,
List<Throwable> suppressed) {
return dexFile != null ? dexFile.loadClassBinaryName(name, definingContext, suppressed)
: null;
}
看到这里可能会有点晕，pathList、dexElements、dexFile 都是些什么鬼？
这里得从构造方法入手，
（1）pathList是BaseDexClassLoader的属性，是DexPathList类型，在构建ClassLoader就会构建pathList，注意会传入dexPath；
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
String librarySearchPath, ClassLoader parent) {
super(parent);
this.pathList = new DexPathList(this, dexPath, librarySearchPath, null);
......
}
（2）dexElements 是DexPathList的属性，是Element[]数组，在构建DexPathList通过makeDexElements创建，注意会传入dexPath；
DexPathList(ClassLoader definingContext, String dexPath,
String librarySearchPath, File optimizedDirectory, boolean isTrusted) {
......
ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
// save dexPath for BaseDexClassLoader
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
suppressedExceptions, definingContext, isTrusted);
......
}
（3）dexFile 是Element的属性，是DexFile 类型，在构建Element时，会给dexFile 赋值，一个dexFile 对应一个dex文件；
private static Element[] makeDexElements(List<File> files, File optimizedDirectory,
List<IOException> suppressedExceptions, ClassLoader loader, boolean isTrusted) {
Element[] elements = new Element[files.size()];//传进来的dexPath路径可以是多个，用冒号分隔开
for (File file : files) {//遍历集合
if (file.isDirectory()) {
......
} else if (file.isFile()) {
......
DexFile dex = null;
if (name.endsWith(DEX_SUFFIX)) {//以dex结尾
......
dex = loadDexFile(file, optimizedDirectory, loader, elements);
if (dex != null) {
elements[elementsPos++] = new Element(dex, null);
}
......
} else {//不是以dex结尾
......
dex = loadDexFile(file, optimizedDirectory, loader, elements);
if (dex == null) {
elements[elementsPos++] = new Element(file);
} else {
elements[elementsPos++] = new Element(dex, file);
}
}
} else {
......
}
}
......
return elements;
}
通过分析源码可以发现，最终都是通过native方法来实现加载的。
加载流程png
5.双亲委派机制好处
（1）唯一性，因为需要判断是否已经加载过，所以一个类只会加载一次；
（2）安全性，由唯一性保证了安全性，被加载过的类无法被篡改的类覆盖，因为全类名一致，全类名不一致那就不叫篡改了；
6.有这么一道面试题，能否替换掉SDK中的String类？
答案是不行。当尝试将篡改的String类加载到内存中，因为BootClassLoader已经加载过String类，所以将会直接返回，不会提供任何加载的机会；
7.如何破坏双亲委派机制呢?
通过自定义ClassLoader，重写loadClass方法，后续都通过自定义的ClassLoader来加载类即可。
8.思考题
以下代码相信大家都很熟悉，那么通过System.out.println打印输出来是AA还是A呢？当然是AA，即使将aa向上转型给A类，它的类信息也是不会丢失，因为类加载时，它加载的就是AA.Class，这个对象保存了AA类的描述信息，包括属性、方法、接口。
A aa=new AA();//AA是A的子类
System.out.println(aa.getClass().getName());
9.总结
（1）双亲委派机制可以简单的理解为，先通过parent来加载class文件，如果加载不到，才自己加载；
（2）一个dex文件对应一个DexFile对象，一个Elements对应一个DexFile，一个DexPathList对应一个Elements数组；
（3）DexClassLoader、PathClassLoader、BootClassLoader这三者的缓存池是同一个；
以上分析有不对的地方，请指出，互相学习，谢谢哦！
网友评论