在 Android 开发中，无论是插件化还是组件化架构，底层都离不开系统的 ClassLoader 机制支撑。简单来说，它是负责将类从存储介质加载到内存并实例化的核心组件。
不同于标准 Java 环境，Android 平台上的虚拟机运行的是 Dex 字节码。这是一种针对 Class 文件优化的产物。传统 Java 编译后生成 .class 文件，而 Android 会将所有 Class 文件合并、优化，最终生成一个或多个 class.dex 文件。这样做的主要目的是去重——如果不同 Class 文件中有重复内容，只需保留一份。当然，如果应用不进行分 dex 处理，最终的 APK 里可能只包含一个 dex 文件。
Android 平台的 ClassLoader 体系
Android 中常见的类加载器主要包括 BootClassLoader、URLClassLoader、PathClassLoader、DexClassLoader 以及 BaseDexClassLoader。虽然它们功能各异，但本质上都是 java.lang.ClassLoader 的子类。
继承关系与基础类
java.lang.ClassLoader 是所有 ClassLoader 的最终父类。它定义了类加载的基本流程，如 loadClass() 方法。在实际使用中，我们很少直接实例化这个基类，而是通过其子类来满足不同场景的需求。
常用子类对比
- BootClassLoader: 负责加载系统核心库，位于最顶层，不可被替换。
- PathClassLoader: 用于加载已安装应用的私有目录下的 dex 和 jar 包，是普通应用最常用的加载器。
- DexClassLoader: 支持从任意路径加载 dex、jar 和 zip 文件，常用于插件化框架或动态加载场景。
- URLClassLoader: 基于 URL 加载资源，在 Android 中较少直接使用，更多见于 Java SE 环境。
构造与初始化
ClassLoader 的构造方法通常涉及父加载器的设置。大多数情况下，我们需要通过父类提供的受保护构造函数进行初始化，指定父加载器以建立双亲委派模型。例如，DexClassLoader 的构造函数通常需要传入 dex 路径、优化目录、库路径以及父加载器等参数。理解这些构造细节，有助于我们在编写自定义加载器时避免类冲突或加载失败的问题。
掌握这些基础概念，是深入理解 Android 动态加载技术的前提。
