安卓类加载机制分析

谈安卓类加载之前，我们先来了解一下java的类加载机制.

1、什么是类加载器

类加载器是一个用来加载类文件的类。Java源代码通过javac编译器编译成类文件。然后JVM来执行类文件中的字节码来执行程序。类加载器负责加载文件系统、网络或其他来源的类文件。有三种默认使用的类加载器：Bootstrap类加载器、Extension类加载器和System类加载器（或者叫作Application类加载器）。每种类加载器都有设定好从哪里加载类。

个人理解:类 通常是同一种对象实例的统称，在虚拟机创建 某个类的对象实例时，它并不知道这个对象实例的具体结构，对象实例的具体结构是由它的类决定的，那么虚拟机就必须先加载这个类，加载完类之后 才能 根据类的结构确定 如何 创建这个 对象实例，例如为这个对象实例分配多少内存，内存里排布的各项值的是什么基本类型等。

2、为什么要使用类加载器

Java语言里，类加载都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会给java应用程序提供高度的灵活性。例如：
1.编写一个面向接口的应用程序，可能等到运行时再指定其实现的子类；
2.用户可以自定义一个类加载器，让程序在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分；(这个是Android插件化，动态安装更新apk的基础)

使用java编译器可以把java代码编译为存储字节码的Class文件，使用其他语言的编译器一样可以把程序代码翻译成Class文件，java虚拟机不关心Class的来源是何种语言。

3、几种类加载器的介绍

3.1、启动类加载器（Bootstrap ClassLoader）

  负责加载JAVA_HOME\lib目录中并且能被虚拟机识别的类库到JVM内存中，如果名称不符合的类库即使放在lib目录中也不会被加载。该类加载器无法被Java程序直接引用。

  下图是我自己打开了 java_home目录下的lib，看看都有哪类。但具体有哪些类是能直接 被 虚拟机识别的类库，我们尚不得而知。

3.2、扩展类加载器（Extension ClassLoader）

该加载器主要是负责加载JAVA_HOME\lib\，该加载器可以被开发者直接使用。

3.3、应用程序类加载器（Application ClassLoader）

该类加载器也称为系统类加载器，它负责加载用户类路径（Classpath）上所指定的类库，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

对于上面三种类加载器，其中启动类加载器（Bootstrap ClassLoader）使用C++语言实现，属于虚拟机自身的一部分，不是ClassLoader的子类。所有其他的类加载器，这些类加载器是由Java语言实现，独立于JVM外部，并且全部继承自抽象类lava.lang.ClassLoader。

4、双亲委派模型

类加载器的双亲委派模型（Parent Delegation Model）要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。子类加载器和父类加载器不是以继承（Inheritance）的关系来实现，而是通过组合（Composition）关系来复用父加载器的代码。

双亲委派模型的工作过程为：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的加载器都是如此，因此所有的类加载请求都会传给顶层的启动类加载器，只有当父加载器反馈自己无法完成该加载请求（该加载器的搜索范围中没有找到对应的类）时，子加载器才会尝试自己去加载。

双亲委派的优点: 使用这种模型来组织类加载器之间的关系的好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如java.lang.Object类，无论哪个类加载器去加载该类，最终都是由启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。否则的话，如果不使用该模型的话，如果用户自定义一个java.lang.Object类且存放在classpath中，那么系统中将会出现多个Object类，应用程序也会变得很混乱。如果我们自定义一个rt.jar中已有类的同名Java类，会发现JVM可以正常编译，但该类永远无法被加载运行。
在rt.jar包中的java.lang.ClassLoader类中，我们可以查看类加载实现过程的代码，具体源码如下：

疑问一：知道了类加载器的作用，但是谁来运行 类加载器？

从虚拟机的角度来说，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader）,另一种就是“非启动类加载器”（呵呵，这样说 是不是想打我？），该类加载器使用C++语言实现，属于虚拟机自身的一部分。因此可以认为，虚拟机在 启动时，就会执行 启动类加载器 去加载一些 通用的 类，比如 Object、String 等.

5、Android类加载机制

        Android中的虚拟机无论是dvm还是art都只能识别dex文件。因此Java中的ClassLoader在Android中不适用。Android中的java.lang.ClassLoader这个类也不同于Java中的java.lang.ClassLoader。
Android中的ClassLoader类型也可分为系统ClassLoader和自定义ClassLoader。

其中系统ClassLoader包括以下几种分别是：

• BootClassLoader，Android系统启动时会使用BootClassLoader来预加载常用类，与Java中的Bootstrap ClassLoader不同的是，它并不是由C/C++代码实现，而是由Java实现的。BootClassLoader是ClassLoader的一个内部类。这个内部类是包内可见,所以我们没法使用。

• URLClassLoader，只能用于加载jar文件，但是由于 dalvik 不能直接识别jar，所以在 Android 中无法使用这个加载器。

• BaseDexClassLoader，它是PathClassLoader和DexClassLoader 的 父类,其中的主要逻辑都是在BaseDexClassLoader完成的。这些源码在java/dalvik/system中。
  先看下BaseDexClassLoader的构造方式：
  
  BaseDexClassLoader的构造函数包含四个参数，分别为：
  a)、dexPath,指目标类所在的APK或jar文件的路径,类装载器将从该路径中寻找指定的目标类,该类必须是APK或jar的全路径.如果要包含多个路径,路径之间必须使用特定的分割符分隔,特定的分割符可以使用System.getProperty(“path.separtor”)获得。上面"支持加载APK、DEX和JAR，也可以从SD卡进行加载"指的就是这个路径，最终做的是将dexPath路径上的文件ODEX优化到内部位置optimizedDirectory，然后，再进行加载的。
  b)、File optimizedDirectory,由于dex文件被包含在APK或者Jar文件中,因此在装载目标类之前需要先从APK或Jar文件中解压出dex文件,该参数就是制定解压出的dex 文件存放的路径。这也是对apk中dex根据平台进行ODEX优化的过程。其实APK是一个程序压缩包，里面包含dex文件，ODEX优化就是把包里面的执行程序提取出来，就变成ODEX文件，因为你提取出来了，系统第一次启动的时候就不用去解压程序压缩包的程序，少了一个解压的过程。这样的话系统启动就加快了。为什么说是第一次呢？是因为DEX版本的也只有第一次会解压执行程序到 /data/dalvik-cache（针对PathClassLoader）或者optimizedDirectory(针对DexClassLoader）目录，之后也是直接读取目录下的的dex文件，所以第二次启动就和正常的差不多了。当然这只是简单的理解，实际生成的ODEX还有一定的优化作用。ClassLoader只能加载内部存储路径中的dex文件，所以这个路径必须为内部路径。
  c)、libPath,指目标类中所使用的C/C++库存放的路径
  d)、classload,是指该装载器的父装载器,一般为当前执行类的装载器，例如在Android中以context.getClassLoader()作为父装载器。

• PathClassLoader，全名是dalvik/system.PathClassLoader，可以加载已经安装的Apk，也就是/data/app/package 下的apk文件，也可以加载/vendor/lib, /system/lib下的nativeLibrary。
  
  同理，也先来看看 源码中的 构造函数。
  
  可以看出PathClassLoader没有将optimizedDirectory置为Null,也就是没设置优化后的存放路径。其实optimizedDirectory为null时的默认路径就是/data/dalvik-cache 目录。
  PathClassLoader是用来加载Android系统类和应用的类，并且不建议开发者使用
  
  很多博客里说PathClassLoader只能加载已安装的apk的dex，其实这说的应该是在dalvik虚拟机上，在art虚拟机上PathClassLoader可以加载未安装的apk的dex（在art平台上已验证），然而在/data/dalvik-cache 确未找到相应的dex文件，怀疑是art虚拟机判断apk未安装，所以只是将apk优化后的odex放在内存中，之后进行释放，这只是个猜想，希望有知道的可以告知一下。因为dalvik上无法使用，所以我们也没法使用。
   
• DexClassLoader，全名是dalvik/system.DexClassLoader，可以加载一个未安装的apk文件。
  继续看一下源码
  

 

6、ART虚拟机的兼容性问题

Android Runtime（缩写为ART），在Android 5.0及后续Android版本中作为正式的运行时库取代了以往的Dalvik虚拟机。ART能够把应用程序的字节码转换为机器码，是Android所使用的一种新的虚拟机。它与Dalvik的主要不同在于：Dalvik采用的是JIT技术，字节码都需要通过即时编译器（just in time ，JIT）转换为机器码，这会拖慢应用的运行效率，而ART采用Ahead-of-time（AOT）技术，应用在第一次安装的时候，字节码就会预先编译成机器码，这个过程叫做预编译。ART同时也改善了性能、垃圾回收（Garbage Collection）、应用程序除错以及性能分析。但是请注意，运行时内存占用空间较少同样意味着编译二进制需要更高的存储。

ART模式相比原来的Dalvik，会在安装APK的时候，使用Android系统自带的dex2oat工具把APK里面的.dex文件转化成OAT文件，OAT文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。这使得我们无需重新编译原有的APK就可以让它正常地在ART里面运行，也就是我们不需要改变原来的APK编程接口。ART模式的系统里，同样存在DexClassLoader类，包名路径也没变，只不过它的具体实现与原来的有所不同，但是接口是一致的。实际上，ART运行时就是和Dalvik虚拟机一样，实现了一套完全兼容Java虚拟机的接口。

参考: Android动态加载之ClassLoader详解

参考:类加载机制原理分析与 hook技术实现底层java方法转发