2018-07-25

对Android类加载器最全面的分析

心得体会：学习不仅仅只是看教程，最好能够想出代码实例去验证自己对某个方面的理解和判断，这样不仅能加深理解，还能够在未来的应用开发中使用到。

前言
本篇文章针对Java 8 之前的类加载结构，Java 9做了不少改变，有兴趣可以查看相关资料。

虚拟机类加载机制
类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期包括：

1. 加载

通过一个类的全限定名来获取定义此类的二进制流。
将这个字节流所代表的静态存储结构转化为运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种访问入口。

注意，这里第1条中的二进制字节流并不只是单纯地从Class文件中获取，比如它还可以从Jar包中获取、从网络中获取（最典型的应用便是Applet）、由其他文件生成（JSP应用）等。

2. 链接：

验证：确保被加载类的正确性；
准备：为类的静态变量分配内存，并将其初始化为默认值；
解析：把类中的符号引用转换为直接引用；（解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始）

3. 初始化

jvm有严格的规定（五种情况）：

遇到new，getstatic，putstatic，invokestatic这4条字节码指令时，假如类还没进行初始化，
则马上对其进行初始化工作。
其实就是3种情况：用new实例化一个类时、读取或者设置类的静态字段时（不包括被final修饰的静态字段，
因为他们已经被塞进常量池了）、以及执行静态方法的时候。
使用java.lang.reflect.*的方法对类进行反射调用的时候，
如果类还没有进行过初始化，马上对其进行。
初始化一个类的时候，如果他的父亲还没有被初始化，则先去初始化其父亲。
当jvm启动时，用户需要指定一个要执行的主类（包含static void main(String[] args)的那个类），
则jvm会先去初始化这个类。
用Class.forName(String className);来加载类的时候，也会执行初始化动作。
注意:ClassLoader的loadClass(String className);方法只会加载并编译某类，并不会对其执行初始化。

对于这5种会触发类初始化的场景，虚拟机使用了一个很强烈的限定语，“有且只有”，这5种场景的行为称为对一个类进行主动引用。除此之外，所有引用类的方法都不会触发初始化。

如：通过子类引用父类的静态字段，不会导致子类初始化；

通过数组定义引用类，不会触发此类的初始化；

常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

初始化阶段是执行类构造器()方法的过程。()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的。

这里借网络上一张图片总结一下,有兴趣可参考：Java面试相关（一）– Java类加载全过程（觉得图画的很细致，如若侵权，请联系作者）

双亲委派模型

看结构图（组合关系，非继承关系）

从图中我们发现除启动类加载器外，每个加载器都有父的类加载器。
双亲委派机制：如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

优势：Java类随着它的类加载器一起具备了一种带有优先级的层次关系，避免了重复加载类，保障了Java类型体系的安全。

当然你也可以破坏双亲委派模型，尤其在Android插件化中。

protected Class<?> loadClass(String name, boolean resolve)
     throws ClassNotFoundException
 {
         // First, check if the class has already been loaded
         Class c = findLoadedClass(name);//判断类是否已经加载过
         if (c == null) {
             long t0 = System.nanoTime();
             try {
                 if (parent != null) {
                     c = parent.loadClass(name, false);//父类加载器优先加载
                 } else {
                     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.
                 long t1 = System.nanoTime();
                 c = findClass(name);//调用当前类加载器的findClass方法进行加载
                 // this is the defining class loader; record the stats
             }
         }
         return c;
 }

源码分析：

简单来说，java的双亲委派机制分为三个过程，在ClassLoader的loadClass方法中会先判断该类是否已经加载，若加载了直接返回，若没加载过则先调用父类加载器的loadClass方法进行类加载，若父类加载器没有找到，则会调用当前正在查找的类加载器的findClass方法进行加载。

如果想保证自定义的类加载器符合双亲委派机制，则覆写findClass方法；如果想打破双亲委派机制，则覆写loadClass方法。

破坏双亲委派机制：

public class MyClassLoader extends DexClassLoader{
    public MyClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
        super(dexPath, optimizedDirectory, librarySearchPath, parent);
    }
    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        if(xxx){//条件判断是否自己加载
            return this.loadClass(name);
        }else{//双亲委派机制加载
            return super.loadClass(name, resolve);
        }
    }
}

父类，子类加载顺序

父类代码：

public class A{
	static{
		System.out.println("父类-静态代码块");
	}
	{
		System.out.println("父类-非静态代码块");
	}
	public A(){
		System.out.println("父类-构造方法");
	}
}

子类代码：

public class B extends A{
	static{
		System.out.println("子类-静态代码块");
	}
	{
		System.out.println("子类-非静态代码块");
	}
	public B(){
		System.out.println("子类-构造方法");
	}
}

测试一下：

public class Test{
	public static void main(String[] args) {
		B b = new B();
	}
}

看看效果：

父类-静态代码块
子类-静态代码块
父类-非静态代码块
父类-构造方法
子类-非静态代码块
子类-构造方法

看到这，就知道初始化子类会先初始化父类。顺序为父类静态——》子类静态——》父类非静态代码块——》父类构造方法——》子类非静态代码块——》子类构造方法。

以上根本原因：初始化一个类的时候，如果他的父亲还没有被初始化，则先去初始化其父亲。

Android中类加载器介绍

android中的类加载器中主要包括三类BootClassLoader，PathClassLoader和DexClassLoader。

BootClassLoader主要用于加载系统的类，包括java和android系统的类库。

PathClassLoader主要用于加载应用内中的类。路径是固定的，只能加载
/data/app中的apk，无法指定解压释放dex的路径。所以PathClassLoader是无法实现动态加载的。

DexClassLoader可以用于加载任意路径的zip,jar或者apk文件。可以实现动态加载。下面来具体看看应用程序中的类加载器。

Android的BootClassLoader和Java的BootStrapClassLoader区别：

Android虚拟机中BootClassLoader是ClassLoader内部类，由java代码实现而不是c++实现，是Android平台上所有ClassLoader的最终parent，这个内部类是包内可见,所以我们没法使用。
Java虚拟机中BootStrapClassLoader是由原生代码(C++)编写的，负责加载java核心类库(例如rt.jar等) .

补充知识点：

Log.i("ljj", "Context的类加载器："+ Context.class.getClassLoader());
Log.i("ljj", "TextView的类加载器： "+ TextView.class.getClassLoader());
//打印结果
02-14 12:37:49.161 22341-22341/com.ljj.host I/ljj: Context的类加载器：java.lang.BootClassLoader@a645091
02-14 12:37:49.162 22341-22341/com.ljj.host I/ljj: TextView的类加载器： java.lang.BootClassLoader@a645091

可见系统的类都是由BootClassLoader加载完成。

1
2

Log.i("ljj", "classLoader:"+getClassLoader());
02-14 13:19:23.730 20518-20518/com.ljj.host I/ljj: classLoader:dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.ljj.host-2/base.apk"],nativeLibraryDirectories=[/data/app/com.ljj.host-2/lib/arm64, /vendor/lib64, /system/lib64]]]

DexClassLoader:

public class DexClassLoader extends BaseDexClassLoader {
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String librarySearchPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
    }
}

DexClassLoader的源码很简单，只包含一个构造函数，看来所有的工作都是在BaseDexClassLoader中完成的。这里再看BaseDexClassLoader前，先说一下DexClassLoader构造函数的四个参数。

dexPath：是加载apk/dex/jar的路径
optimizedDirectory：是dex的输出路径(因为加载apk/jar的时候会解压除dex文件，这个路径就是保存dex文件的)
librarySearchPath：是加载的时候需要用到的lib库，这个一般不用，可以传入Null
parent：给DexClassLoader指定父加载器
下面继续分析BaseClassLoader。

public class BaseDexClassLoader extends ClassLoader {
    private final DexPathList pathList;
    public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String librarySearchPath, ClassLoader parent) {
        super(parent);
        this.pathList = new DexPathList(this, dexPath, librarySearchPath, optimizedDirectory);
    }
   @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;
    }

可以看出，DexClassLoader会通过传入的路径构造出一个DexPathList对象，作为pathList。从findClass方法可以看出来加载的类都是从pathList中查找。至于DexPathList对象的源码就不往下具体分析了，简单的理解就是将每个dex都构建成Element元素，放入到dexElements数组中，多说一句，这个dexElements数组的用处很大，MultiDex方案以及由此衍生出的QQ空间热更新方案都是通过改变dexElements数组的元素位置来实现的。感兴趣可以参考：Android类加载器分析

Android类加载器和Java的类加载器工作机制是类似的，使用双亲委托机制。

参考：

深入理解Java虚拟机周志明著
Android类加载器分析
Java面试相关（一）– Java类加载全过程
Android类加载器以及与Java类加载器区别
Java类加载
自己Demo代码
极客时间APP核心技术第23讲|请介绍类加载过程，什么是双亲委派模型？

声明：此为原创，转载请联系作者

作者：微信公众号添加公众号-遛狗的程序员 ，或者可以扫描以下二维码关注相关技术文章。

当然喜爱技术，乐于分享的你也可以可以添加作者微信号：

本文标题:对Android类加载器最全面的分析

文章作者:黄尘

发布时间:2018-07-25, 23:57:40

最后更新:2018-08-21, 15:09:41

原始链接:https://huangchen0.github.io/2018/07/25/对Android类加载器最全面的分析/

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。