前言

几年前我在 CSDN 写过一篇 [《android 插件化框架 speed-tools》],那时候框架只解决了"不安装 APK 就能加载页面"这一个核心诉求。几年过去,Android 系统经历了多次大版本迭代,插件化方案也面临新的挑战:

  • Android 10 收紧了私有目录访问;
  • Android 14 彻底禁止了加载可写 dex 文件
  • 业务侧对"动态换肤"和"全局字体调节"的需求越来越强烈。

于是我把整个项目从里到外升级了一遍:

  • 构建基线从 Support Library + compileSdk 28 升级到 AndroidX + compileSdk 35 + AGP 8.8.2
  • 类加载策略在 Android 8.0+ 切换为 InMemoryDexClassLoader(内存加载),天然规避 Android 14+ 的文件权限限制;
  • 新增 运行时换肤运行时字体切换两大能力。

本文会带你从 0 到 1 跑通整个 Demo,并理解背后的核心原理。


二、Speed Tools 能做什么?

一句话概括:一套面向 Android 的本地插件化框架,同时附带换肤和字体调节能力

能力 一句话说明 典型场景
插件化 宿主加载未安装的 APK,代理启动插件页面 多业务独立演进、按插件解耦
动态换肤 运行时加载皮肤包 APK,替换颜色/图片/背景 夜间模式、节日主题、品牌定制
字体调节 运行时全局调整字体大小,支持用户偏好持久化 无障碍适配、老年模式

2.1 为什么不用 Google Play Dynamic Delivery?

  • 国内应用商店生态复杂,很多渠道不支持 PAD;
  • 需要完全本地可控,不依赖外部服务;
  • 希望低侵入接入现有工程,而非改造成 Dynamic Feature Module 结构。

Speed Tools 的定位就是:本地可控、低侵入、开箱即用


三、工程结构一览

speed_tools/
├── lib_speed_tools/          # 核心库(插件加载、代理、换肤、字体)
├── module_host_main/         # 宿主示例 App
├── module_client_one/        # 插件示例 1
├── module_client_two/        # 插件示例 2
├── theme_demo/               # 换肤与字体切换演示 App
├── black_theme/              # 皮肤包示例(纯资源,无业务代码)
└── lib_img_utils/            # 第三方图片库测试模块
  • lib_speed_tools 是唯一的依赖入口,宿主和插件都只依赖它;
  • module_host_main 演示了如何加载插件并跳转;
  • theme_demo 演示了换肤和字体切换的完整链路。

四、10 分钟跑通 Demo

4.1 环境要求

  • Android Studio(推荐最新稳定版)
  • JDK 17
  • compileSdk 35 / minSdk 21 / targetSdk 35

4.2 编译插件和皮肤包

# 编译插件 APK
./gradlew :module_client_one:assembleDebug
./gradlew :module_client_two:assembleDebug

# 编译皮肤包
./gradlew :black_theme:assembleDebug

4.3 放置 APK 到 assets

把编译产物复制到对应目录:

module_host_main/src/main/assets/
    ├── module_client_one-debug.apk
    └── module_client_two-debug.apk

theme_demo/src/main/assets/
    └── black_theme-debug.apk

4.4 运行

  1. 选择运行配置 module_host_main → 启动后自动加载插件,点击按钮进入插件页面;
  2. 选择运行配置 theme_demo → 依次体验:切换黑色主题 → 恢复默认 → 放大字体 → 恢复字体。

到这里,你已经亲眼见证了框架的三项核心能力。


五、插件化核心原理

5.1 整体架构

┌─────────────────────────────────────────┐
│              宿主 APK                    │
│  ┌─────────┐   ┌─────────────────────┐  │
│  │ Assets  │──▶│ SpeedApkManager     │  │
│  │ (插件)  │   │ (类加载 + 资源桥接)  │  │
│  └─────────┘   └─────────────────────┘  │
│                     │                    │
│                     ▼                    │
│  ┌───────────────────────────────────┐  │
│  │       代理 Activity                │  │
│  │  (转发 onCreate/onResume/onDestroy)│  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│            插件 APK(未安装)              │
│  ┌──────────────┐   ┌──────────────┐   │
│  │ 业务实现类    │   │    res/      │   │
│  │(继承接口)    │◀──│  (资源文件)  │   │
│  └──────────────┘   └──────────────┘   │
└─────────────────────────────────────────┘

5.2 类加载:InMemoryDexClassLoader 如何规避 Android 14 限制

Android 14 引入了一条硬性限制:禁止加载可写的 dex 文件。旧方案使用 DexClassLoader 直接加载 APK 路径,如果文件权限是可写的,就会抛出:

java.lang.SecurityException: Writable dex file ... is not allowed.

Speed Tools 的解决思路很直接:

  • Android 8.0+(API 26):从 APK 中解压出 classes.dex,读取到内存 ByteBuffer,通过 InMemoryDexClassLoader 加载。dex 数据完全在内存中,不走文件系统,自然不受"可写"限制。
  • Android 5.0~7.1(API 21~25):回退到传统的 DexClassLoader,这些旧版本没有此限制。

核心代码片段(SpeedUtils.java):

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    ByteBuffer[] dexBuffers = extractDexBuffersFromApk(apkPath);
    return new InMemoryDexClassLoader(dexBuffers, appContext.getClassLoader());
} else {
    return new DexClassLoader(apkPath, optimizedDir, nativeLibDir, parent);
}

5.3 资源桥接

插件的 res/ 资源如何被宿主识别?答案是反射创建 AssetManager

AssetManager assetManager = AssetManager.class.getDeclaredConstructor().newInstance();
Method addAssetPath = assetManager.getClass().getDeclaredMethod("addAssetPath", String.class);
addAssetPath.invoke(assetManager, apkPath);

Resources pluginRes = new Resources(assetManager, hostMetrics, hostConfig);

宿主代理 Activity 持有这份 pluginRes,插件页面里的 setContentView(R.layout.xxx) 就能正确找到插件自己的布局了。

5.4 生命周期转发

插件业务类不直接继承 Activity,而是继承 SpeedBaseInterfaceImp,实现一套与 Activity 对应的生命周期接口。宿主端的 SpeedHostBaseActivity 作为"壳",在 onCreateonResumeonDestroy 等节点调用插件实现类的对应方法,完成生命周期转发。


六、插件化接入实战

6.1 宿主侧:加载插件

// 优先从外部目录查找,fallback 到 assets 拷贝
File apkFile = SpeedUtils.resolvePluginApk(
        context, "/sdcard/Download", 
        "module_client_one-debug.apk"
);

SpeedApkManager.getInstance().loadApk(
        "first_apk",           // 插件 key
        apkFile.getAbsolutePath(), 
        "dex_output2",         // dex 优化目录(每个插件独立)
        context
);

6.2 宿主侧:跳转插件

SpeedUtils.goActivity(this, "first_apk", null);

第三个参数 classTag 对应插件 AndroidManifest.xml 中 meta-data 的 name,为空时走默认入口。

6.3 插件侧:声明入口

<application>
    <meta-data
        android:name="root_class"
        android:value="com.example.clientdome.ClientMainActivity" />
</application>

插件业务类需要实现 SpeedBaseInterface,代理层会通过反射实例化这个类。


七、换肤与字体切换

7.1 核心设计

换肤和字体调节的本质是资源替换

  • 换肤:拦截 LayoutInflater 创建 View 的过程,把颜色/图片资源替换为皮肤包中的同名资源;
  • 字体:拦截 textSize 属性的读取,在基础值上叠加用户设置的偏移量。

为了框架能识别哪些资源需要被替换,规定了强制前缀:

类型 前缀 示例
颜色/背景/图片 cxt_ @color/cxt_primary
字体维度 cxf_ @dimen/cxf_normal

7.2 三步接入

Step 1:Application 初始化

@Override
public void onCreate() {
    super.onCreate();
    SPFontManager.getInstance().init(this);
    SPThemeManager.getInstance().init(this);
}

Step 2:Activity 注册监听

public class BaseActivity extends AppCompatActivity implements SPUpdateUIListener {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        SPThemeManager.getInstance().registerUpdateUI(this);
        super.onCreate(savedInstanceState);
    }

    @Override
    protected void onDestroy() {
        SPThemeManager.getInstance().unRegisterUpdateUI(this);
        super.onDestroy();
    }

    @Override
    public void updateUI(boolean isFistLoading) {
        // 自定义控件手动刷新
    }
}

Step 3:触发切换

// 换肤
SPThemeManager.getInstance()
        .changeTheme("black_theme-debug.apk")
        .sendUpdateUIAction();

// 字体放大
SPFontManager.getInstance().changeConfig(40).updateUI();

7.3 皮肤包怎么制作?

皮肤包就是一个只包含资源、不含业务代码的普通 Android App 模块:

  1. 新建 Android App 模块;
  2. 在 res/ 中放置与主工程同名的 cxt_* / cxf_* 资源;
  3. 打包生成 APK。

主工程和皮肤包的资源名必须完全一致,值可以不同。运行时 

Logo

讨论HarmonyOS开发技术,专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐