Android 插件化技术：动态加载综述与核心原理

6. 动态加载 Dex/Jar/APK 文件详解

我们通常讲到的 Android 动态加载技术默认指这种。下面详细介绍其基础知识和实现模式。

基础知识：类加载器 ClassLoader 和 Dex 文件

动态加载 Dex/Jar/APK 文件的基础是类加载器 ClassLoader，它的包路径是 java.lang，由此可见其重要性。虚拟机就是通过类加载器加载其需要用到的 Class，这是 Java 程序运行的基础。

在 Android 中，常用的类加载器包括：

• PathClassLoader：只能加载已安装的 APK 中的 Dex 文件。
• DexClassLoader：可以加载任意路径下的 Dex 文件（如 SD 卡、网络下载），支持动态加载未安装的 APK。

7. 动态加载的实现模式

目前网络上有多种基于 ClassLoader 的 Android 动态加载开源项目，大部分核心思想都差不多。按照复杂程度以及具体实现的框架，大致可以分为以下三种形式。

7.1 简单的动态加载模式

Android 应用在运行时使用 ClassLoader 动态加载外部的 dex 文件非常简单，不用覆盖安装新的 APK，就可以更改 APP 的代码逻辑。但是 Android 却很难使用插件 APK 里的 res 资源，这意味着无法使用新的 XML 布局等资源。同时由于无法更改本地的 Manifest 清单文件，所以无法启动新的 Activity 等组件。

解决方案：

• 先把要用到的全部 res 资源都放到主 APK 里面。
• 把所有需要的 Activity 先全部写进 Manifest 里，只通过动态加载更新代码，不更新 res 资源。
• 如果需要改动 UI 界面，可以通过使用纯 Java 代码创建布局的方式绕开 XML 布局。
• 可以使用 Fragment 代替 Activity，这样可以最大限度避开'无法注册新组件的限制'。

这种模式的框架比较适用一些 UI 变化比较少的项目，比如游戏 SDK，基本就只有登录、注册界面，而且基本不会变动，更新的往往只有代码逻辑。

7.2 代理 Activity 模式

我们可以通过动态加载，让现在的 Android 应用启动一些'新'的 Activity，甚至不用安装就启动一个'新'的 APK。宿主 APK 需要先注册一个空壳的 Activity 用于代理执行插件 APK 的 Activity 的生命周期。

主要特性：

• 宿主 APK 可以启动未安装的插件 APK。
• 插件 APK 也可以作为一个普通 APK 安装并且启动。
• 插件 APK 可以调用宿主 APK 里的一些功能。
• 宿主 APK 和插件 APK 都要接入一套指定的接口框架才能实现以上功能。

限制：

• 需要在 Manifest 注册的功能都无法在插件实现，比如应用权限、LaunchMode、静态广播等。
• 宿主一个代理用的 Activity 难以满足插件一些特殊的 Activity 的需求，插件 Activity 的开发受限于代理 Activity。
• 宿主项目和插件项目的开发都要接入共同的框架，大多时候，插件需要依附宿主才能运行，无法独立运行。

代理 Activity 模式的核心在于'使用宿主的一个代理 Activity 为插件所有的 Activity 提供组件工作需要的环境'。随着代理模式的逐渐成熟，现在还出现了'使用 Hack 手段给插件的 Activity 注入环境'的模式。

7.3 动态创建 Activity 模式

动态创建 Activity 模式的核心是'运行时字节码操作'。现在宿主注册一个不存在的 Activity，启动插件的某个 Activity 时都把想要启动的 Activity 替换成前面注册的 Activity，从而使得后者能正常启动。

特点：

1. 主 APK 可以启动一个未安装的插件 APK。
2. 插件 APK 可以是任意第三方 APK，无需接入指定的接口，理所当然也可以独立运行。

8. 动态加载技术的作用与缺点

作用

1. 规避升级流程：规避 APK 覆盖安装的升级过程，提高用户体验，顺便能规避一些安卓市场的限制。
2. 紧急修复：动态修复应用的一些紧急 BUG，做好最后一道保障。
3. 模块分割：当应用体积太庞大的时候，可以把一些模块通过动态加载以插件的形式分割出去，这样可以减少主项目的体积，提高项目的编译速度，也能让主项目和插件项目并行开发。
4. 懒加载优化：插件模块可以用懒加载的方式在需要的时候才初始化，从而提高应用的启动速度。
5. 代码分离：从上来看，分割插件模块的方式做到了项目级别的代码分离，大大降低模块之间的耦合度，同一个项目能够分割出不同模块在多个开发团队之间并行开发，如果出现 BUG 也容易定位问题。
6. 推广辅助：在 Android 应用上推广其他应用的时候，可以使用动态加载技术让用户优先体验新应用的功能，而不用下载并安装全新的 APK。
7. 解决 DEX 限制：减少主项目 DEX 的方法数，65535 问题彻底成为历史（虽然现在在 Android Studio 中很容易开启 MultiDex，这个问题也不难解决）。

缺点

1. 开发繁琐：开发方式可能变得比较诡异、繁琐，与常规开发方式不同。
2. 构建复杂：随着动态加载框架复杂程度的加深，项目的构建过程也变得复杂，有可能要主项目和插件项目分别构建，再整合到一起。
3. 调试困难：由于插件项目是独立开发的，当主项目加载插件运行时，插件的运行环境已经完全不同，代码逻辑容易出现 BUG，而且在主项目中调试插件十分繁琐。
4. 兼容性风险：非常规的开发方式，有些框架使用反射强行调用了部分 Android 系统 Framework 层的代码，部分 Android ROM 可能已经改动了这些代码，所以有存在兼容性问题的风险，特别是在一些古老 Android 设备和部分三星的手机上。
5. 资源兼容：采用动态加载的插件在使用系统资源（特别是 Theme）时经常有一些兼容性问题，特别是部分三星的手机。

9. 其他动态修改代码的技术

上面说到的都是基于 ClassLoader 的动态加载技术（除了加载 SO 库外）。使用 ClassLoader 的一个特点是，如果程序不重新启动，加载过一次的类就无法重新加载。因此，如果使用 ClassLoader 来动态升级 APP 或者动态修复 BUG，都需要重新启动 APP 才能生效。

除了使用 ClassLoader 外，还可以使用 JNI Hook 的方式修改程序的执行代码。前者是在虚拟机上操作的，而后者做的是已经是 Native 层级的工作了，直接修改应用运行时的内存地址，所以使用 JNI Hook 的方式时，不用重启应用就能生效。

目前采用 JNI Hook 方案的项目中比较热门的有阿里的 Dexposed 和 AndFix。这些工具通过 Hook 系统方法或重写类方法，实现了在不重启应用的情况下修复 Bug 或热更新代码。

10. 总结与建议

Android 插件化技术是高级 Android 架构设计的重要组成部分。它通过动态加载机制打破了传统 APK 的封闭性，为应用的热修复、模块化开发和灵活升级提供了强有力的支持。

开发者建议：

• 在决定使用插件化方案前，需充分评估项目的复杂度与维护成本。
• 注意安全性，避免加载来源不明的 Dex 文件。
• 针对不同的 Android 版本和 ROM 进行充分的兼容性测试。
• 结合项目实际情况选择合适的动态加载框架，如 RePlugin、VirtualAPK 或自行实现轻量级方案。

通过深入理解动态加载的原理与实现细节，开发者可以更好地掌控应用的生命周期，提升用户体验与开发效率。