Android ClassLoader详解

嘉小华
622 阅读12分钟

一、ClassLoader 是如何使用的?

绝大多数情况下，你不需要直接操作 ClassLoader！  系统已经为你设置好了默认的管理员。但理解它在后台如何工作非常重要，尤其是在涉及动态加载、插件化、热修复等高级技术时。

  1. 默认加载：

    • 当你写 MyClass obj = new MyClass(); 或 Class.forName("com.example.MyClass") 时，Java 虚拟机 (JVM/ART) 会自动使用当前线程关联的 ClassLoader（通常是应用的 PathClassLoader）去查找并加载 com.example.MyClass 这个类。
    • 这个默认的 ClassLoader 是由系统在应用启动时创建并设置好的，它知道去哪里找你的 APK 里面的代码（DEX 文件）和系统框架的代码。

  2. 显式使用：

    • 动态加载 DEX/APK (插件化/热修复)：  这是 ClassLoader 最核心的高级用法。

      • 你从网络下载或本地存储中获取一个额外的 DEX 文件或 APK (插件)。
      • 创建一个新的 ClassLoader (通常是 DexClassLoader)。
      • 告诉这个新的 ClassLoader DEX/APK 文件在哪里 (dexPath)，优化后的文件放哪里 (optimizedDirectory)，系统库路径 (librarySearchPath)，以及它的父 ClassLoader 是谁 (通常是当前应用的 PathClassLoader 或 BootClassLoader)。
      • 使用这个新创建的 ClassLoader 去加载插件中的类：Class clazz = myNewClassLoader.loadClass("com.plugin.PluginClass");
      • 然后通过反射 (clazz.newInstance(), clazz.getMethod(...)) 来创建对象和调用方法。
      • 目的：  实现功能模块的按需加载、应用不重启更新代码（热修复）、运行未经安装的 APK（插件）。

    • 加载非 DEX 格式的资源：  虽然不常见，但 ClassLoader 也可以用来加载 JAR 包中的类或特定的资源文件。

    • 实现类隔离：  创建不同的 ClassLoader 实例加载相同的类，这些类会被视为不同的类（即使全限定名相同），避免冲突。这在多插件框架中很重要。

二、ClassLoader 的原理

  1. 双亲委派模型 (Parent Delegation Model)：  这是 ClassLoader 工作的基石原则。

    • 核心思想：  “儿子有事，先找爸爸”。当一个 ClassLoader 收到加载类的请求时：

      1. 它首先不会自己尝试加载。
      2. 它会把这个请求委派给自己的父 ClassLoader 去处理。
      3. 父 ClassLoader 收到请求后，又会采用同样的策略，委派给自己的父 ClassLoader。这样一直递归到最顶层的父 ClassLoader (通常是 BootClassLoader)。
      4. 只有当所有的父 ClassLoader 都表示自己无法加载这个类 (在它们各自的搜索路径中找不到) 时，子 ClassLoader 才会自己尝试去加载。

    • 优点：

      • 安全性：  防止核心系统类（如 java.lang.String）被应用自定义的同名类替换。因为核心类肯定会被顶层的 BootClassLoader 找到并加载，应用层的 ClassLoader 根本没机会加载自己的版本。
      • 避免重复加载：  同一个类在同一个 ClassLoader 命名空间里只会被加载一次。父 ClassLoader 加载过的类，子 ClassLoader 可以直接使用，无需再加载。
      • 清晰的责任链：  不同类型的 ClassLoader 负责加载不同来源的类，层次分明。

  2. 命名空间 (Namespace)：  每个 ClassLoader 实例都有自己独立的“类仓库”。

    • 由同一个 ClassLoader 加载的类属于同一个命名空间。
    • 即使两个类的全限定名完全相同，如果它们是由两个不同的 ClassLoader 实例加载的，那么在 JVM/ART 看来，它们就是两个完全不同的、互不兼容的类！instanceof 检查、类型转换都会失败。
    • 这个特性是实现类隔离的关键。插件 A 和插件 B 可以使用相同名字的类而不会冲突，因为它们是由不同的 ClassLoader 加载的。

  3. 查找与加载：

    • 当轮到一个 ClassLoader 自己尝试加载时（父类都找不到），它会调用自己的 findClass(String name) 方法。

    • 不同类型的 ClassLoader 实现 findClass 的方式不同：

      • BootClassLoader: 在系统 Framework 的预加载 DEX 文件 (如 framework.jar, core-libart.jar) 中查找。
      • PathClassLoader: 在 dexPath 指定的路径（通常是 APK 文件本身）中查找 DEX 文件。
      • DexClassLoader: 在 dexPath 指定的路径（可以是 APK、JAR 或包含 DEX 的目录）中查找 DEX 文件。

    • 查找过程通常依赖于 DexPathList 这个内部辅助类，它维护了 DEX 文件、APK、JAR 文件的列表以及本地库目录。DexPathList 会遍历这些元素，尝试在里面的 DEX 文件中找到指定的类。

  4. 定义与链接：  一旦找到类的字节码，ClassLoader 会调用 defineClass (通常由 Native 实现) 将字节码转换为 JVM/ART 内部可用的类结构，并进行必要的链接（验证、准备等），最终得到一个可用的 Class 对象。

  5. Android 特有的 ClassLoader 类型：

    • BootClassLoader：

      • 最顶层的父加载器（由 C++ 实现，Java 代码中不可见）。
      • 负责加载 Android Framework 的核心类库（rt.jar, core.jar 等）。
      • 是所有其他 Android ClassLoader 的最终父加载器。

    • PathClassLoader (Android 默认应用加载器)：

      • 继承自 BaseDexClassLoader。
      • 系统创建：  当应用启动时，系统会为每个 APK 创建一个 PathClassLoader 实例。
      • 加载路径：  专门用于加载已安装的 APK 文件（路径如 /data/app/com.example.myapp-1/base.apk）中的 classes.dex。
      • 开发者使用：  通常通过 context.getClassLoader() 获得。不推荐开发者手动创建它去加载外部文件（权限/路径问题）。

    • DexClassLoader (动态加载的主力)：

      • 也继承自 BaseDexClassLoader。
      • 开发者创建：  专门设计用来动态加载包含 classes.dex 的文件（.dex, .jar, .apk, .zip）。

    • InMemoryDexClassLoader (Android 8.0+):

      • 继承自 BaseDexClassLoader。
      • 允许直接从内存中的字节数组加载 DEX 内容，无需先将 DEX 文件写入存储。对安全性和性能（减少 IO）有要求的热修复/插件化场景有用。

  6. BaseDexClassLoader 的核心：DexPathList

    • 这是真正干“找包裹”脏活累活的类。每个 BaseDexClassLoader (PathClassLoader/DexClassLoader) 内部都有一个 DexPathList 对象。

    • DexPathList 维护了两个关键数组：

      • dexElements: 元素是 Element 对象。每个 Element 代表一个 DEX 文件（或 APK/JAR 中的 DEX）、一个 JAR 文件、或者一个包含 DEX/JAR 的目录。它内部封装了 DexFile 对象，用来真正加载 DEX 和查找类。
      • nativeLibraryDirectories: 包含 native 库（.so 文件）的目录列表。

    • findClass 实现：  BaseDexClassLoader 的 findClass(String name) 方法，本质上就是遍历 DexPathList 中的 dexElements 数组，依次调用每个 Element 的 findClass(name, definingContext) 方法（内部调用 DexFile.loadClassBinaryName），直到找到并加载目标类，或者遍历完所有 Element 都没找到则抛出 ClassNotFoundException

三、源码调用链路

假设我们在应用代码中写 Class.forName("com.example.MyClass")：

  1. Class.forName(String className)

    • (内部调用) Class.forName(className, true, currentClassLoader) // true 表示初始化类，currentClassLoader 是当前调用者类的 ClassLoader (通常是 PathClassLoader)

  2. currentClassLoader.loadClass(className) // 通常是 PathClassLoader.loadClass()

    • 首先检查是否已加载过：Class c = findLoadedClass(className); (本地方法)

    • 如果已加载，直接返回 c。

    • 双亲委派开始：

      • 如果父 ClassLoader 不为 null (parent != null), 调用 parent.loadClass(className)。 // 父 ClassLoader (通常是 BootClassLoader) 执行同样的流程。
      • 如果父 ClassLoader 为 null (说明 currentClassLoader 就是 BootClassLoader)，调用 findBootstrapClassOrNull(className) (尝试用 Bootstrap ClassLoader 加载，在 Android 中通常返回 null)。

    • 如果父 ClassLoader (或 Bootstrap) 没能加载成功：

      • 调用自己的 findClass(className)。 // PathClassLoader.findClass()

  3. PathClassLoader.findClass(String name)

    • (内部调用) super.findClass(name) // 实际调用的是 BaseDexClassLoader.findClass()

  4. BaseDexClassLoader.findClass(String name)

    • (核心) 交给内部的 pathList (一个 DexPathList 对象) 去查找：return pathList.findClass(name, suppressedExceptions);

  5. DexPathList.findClass(String name, List<Throwable> suppressed)

    • 遍历 dexElements 数组 (这个数组包含了所有它知道的 DEX 文件、APK、JAR 的 Element 对象)。
    • 对每个 element：调用 element.findClass(name, definingContext, suppressed); // definingContext 就是当前的 BaseDexClassLoader

  6. DexPathList.Element.findClass(...) (通常由 DexFile 实现)

    • 最终调用 dexFile.loadClassBinaryName(name, definingContext, suppressed);

  7. DexFile.loadClassBinaryName(...)

    • 通过 Native 方法 defineClassNative(...) 或类似机制，最终调用到 ART 运行时内部的 ClassLinker::DefineClass 等方法，将 DEX 文件中的字节码加载、验证、链接并定义为一个运行时的 Class 对象。

  8. 如果 DexPathList 遍历完所有 element 都没找到，则抛出 ClassNotFoundException。

关键点：

  • 委派发生在 ClassLoader.loadClass() 方法中。
  • 实际的查找发生在 BaseDexClassLoader.findClass() -> DexPathList.findClass() -> 遍历 dexElements -> DexFile。
  • dexElements 数组的顺序至关重要！  遍历是从数组开头到结尾，找到第一个包含所需类的 Element 就返回。这是很多热修复方案（如 Tinker, AndFix 早期）利用的关键点：将补丁 DEX 插入到 dexElements 数组的前面，使其优先于原 APK 中的 DEX 被加载，从而覆盖有 Bug 的类。

四、相关的关键概念与补充内容

  1. Android 中的主要 ClassLoader 类型：

    • BootClassLoader：

      • 父加载器：  没有父加载器（是根）。
      • 加载内容：  Android Framework 的核心 Java 类库 (如 java.lang.*, android.*)，由系统预加载。由 C/C++ 实现，Java 代码中不可直接实例化或获取（ClassLoader.getSystemClassLoader().getParent() 返回它，但类型是 ClassLoader）。
      • 特点：  单例。

    • PathClassLoader：

      • 父加载器：  BootClassLoader。
      • 加载内容：  应用程序自身 APK 中的类。是系统为每个 Android 应用默认创建的主 ClassLoader。
      • 路径：  构造参数 dexPath 通常是 APK 文件路径。optimizedDirectory 在较新 Android 版本上已废弃/忽略，由系统管理。
      • 特点：  应用启动时创建，负责加载 Activity, Service 等应用代码。

    • DexClassLoader：

      • 父加载器：  可以指定（通常指定为 PathClassLoader 或 BootClassLoader）。
      • 加载内容：  从指定的文件路径加载包含 DEX 的 JAR/APK/ZIP 文件或纯 DEX 文件。这是用于动态加载的核心 ClassLoader。
      • 路径：  构造时需要 dexPath (DEX/JAR/APK/ZIP 路径或目录), optimizedDirectory (已废弃/忽略，传入 null 或应用私有目录), librarySearchPath (本地库 .so 路径，可为 null), parent (父 ClassLoader)。
      • 特点：  开发者显式创建，用于加载非安装的、额外的代码。

    • InMemoryDexClassLoader (API 26+):

      • 父加载器：  可以指定。
      • 加载内容：  直接从内存缓冲区 (ByteBuffer)  加载 DEX 字节码。
      • 特点：  避免 DEX 文件落地到存储，提高动态加载的安全性和性能。是热修复和插件化的更优选择。
    特性BootClassLoaderPathClassLoaderDexClassLoaderInMemoryDexClassLoader (API 26+)
    父加载器无 (根)BootClassLoader可指定 (通常 PathClassLoader)可指定
    主要加载内容Android Framework 核心库应用自身 APK 中的类外部 DEX/JAR/APK/ZIP 文件中的类内存中的 DEX 字节码
    开发者创建否 (系统内部)否 (系统为应用创建)是 (用于动态加载)是
    dexPath 类型N/AAPK 文件路径DEX/JAR/APK/ZIP 文件路径或目录N/A
    optimizedDirN/A已废弃/忽略 (传 null)已废弃/忽略 (传 null)不需要
    libraryPathN/AN/A可选 (.so 库路径)可选
    关键用途加载系统核心类加载应用主代码动态加载插件/补丁高效安全加载内存补丁

  2. DexPathList 与 dexElements：

    • 这是 BaseDexClassLoader (因此也是 PathClassLoader 和 DexClassLoader) 内部的核心数据结构。
    • 它维护了一个 Element[] dexElements 数组。
    • 每个 Element 代表一个包含 DEX 代码的来源，比如一个 DEX 文件、一个 APK 文件、一个 JAR 文件。
    • findClass 方法就是顺序遍历这个数组，在每个 Element 中尝试查找类。数组顺序决定了类加载的优先级！

  3. 热修复 (HotFix) 原理 (基于 ClassLoader)：

    • 类替换：  最常见的方案。将修复后的类打包成一个 DEX 补丁文件。在应用启动时（或特定时机）：

      • 创建一个包含补丁 DEX 的 DexClassLoader (父加载器是原 PathClassLoader)。
      • 通过反射获取到原 PathClassLoader 内部的 DexPathList 对象和它的 dexElements 数组。
      • 通过反射获取新创建的 DexClassLoader 的 DexPathList 和它的 dexElements 数组。
      • 将补丁的 dexElements 数组合并到原 dexElements 数组的前面，创建一个新的 dexElements 数组。
      • 通过反射将这个新的 dexElements 数组设置回原 PathClassLoader 的 DexPathList 中。

    • 效果：  下次需要加载类时，PathClassLoader 会先在补丁 DEX 的 Element 中查找。如果找到了修复后的类，就直接加载它，而不会再去加载原 APK 中有 Bug 的类。利用了双亲委派失败后自己查找和 dexElements 数组顺序优先级的特性。

    • 限制：  不能修复已被加载过的类（需要重启应用或特定技巧）、不能修改类结构（如增删字段/方法，否则易崩溃）、需要处理资源修复（通常单独处理）。

  4. 插件化原理 (基于 ClassLoader)：

    • 每个插件 APK 通常由自己独立的 DexClassLoader 加载。
    • 这个 DexClassLoader 的父加载器通常是主应用的 PathClassLoader（或 BootClassLoader），这样插件可以访问主应用的公共类和系统类。
    • 类隔离：  不同插件的 DexClassLoader 不同，即使它们加载了同名类，也被视为不同的类，避免了冲突。
    • 资源加载：  类加载解决了代码问题，但插件的资源（图片、布局等）加载是另一个复杂问题，通常需要创建新的 AssetManager 实例并添加插件 APK 的路径，然后创建新的 Resources 对象包装这个 AssetManager。
    • 组件管理：  如何启动未在 AndroidManifest.xml 中声明的插件 Activity 等组件是核心挑战，常用方案有代理 Activity (占坑)、Hook Instrumentation/ActivityThread 等系统机制。

  5. 注意事项：

    • 内存泄漏：  自定义的 ClassLoader (尤其是加载了插件/补丁的) 如果持有 Context 引用，容易造成内存泄漏。确保在不需要时（如应用退出、插件卸载）能正确释放。

    • 性能：  加载 DEX 文件（特别是首次）是一个相对耗时的 IO 和验证过程。优化加载时机和策略。

    • 兼容性：  Android 不同版本对 ClassLoader 的实现、DEX 格式优化 (如 ART 的 AOT)、optimizedDirectory 的处理等有差异。代码需要兼容。

    • 安全性：  动态加载外部代码存在安全风险，需确保代码来源可信，并做好混淆加固。

    • NoClassDefFoundError / ClassNotFoundException：  常见于动态加载场景，原因包括：

      • 类名拼写错误。
      • 需要的类不在你指定的 dexPath 路径中。
      • 该类依赖的其他类找不到（确保父 ClassLoader 能加载到依赖项）。
      • 插件/补丁 DEX 与宿主环境不兼容（如使用了宿主没有的库）。

    • ClassCastException：  典型的名空间问题。对象 A 由 ClassLoaderX 加载，你尝试将它转换成由 ClassLoaderY 加载的接口或父类。即使全限定名相同，只要加载器不同，转换就会失败。

总结

Android 的 ClassLoader 是一个强大而灵活的机制，是应用动态加载、插件化和热修复等技术的基础。其核心在于双亲委派模型和独立的命名空间。理解 BootClassLoader, PathClassLoader, DexClassLoader 的角色和关系，以及 DexPathList 和 dexElements 的工作原理，是掌握高级开发技巧的关键。

avatar
文章
阅读
粉丝