Android 插件化框架 DynamicLoadApk 源码解析（上）

上图是调用插件 Activity 的标准流程图，其他组件的调用流程类似。主要步骤如下：

1. 加载插件：首先通过 DLPluginManager 的 loadApk 函数加载插件 APK。这一步每个插件只需调用一次，将插件资源加载到宿主内存中。
2. 启动代理：通过 DLPluginManager 的 startPluginActivity 函数启动代理 Activity。此时系统并不知道实际要启动的是哪个插件 Activity。
3. 构建与启动：代理 Activity 在启动过程中，利用反射和类加载器构建、启动真正的插件 Activity。

4. 类详细分析

4.1 DLPluginManager.java

DLPluginManager 是 DynamicLoadApk 框架的核心管理类，主要功能包括插件的加载管理和启动插件组件（Activity、Service）。

主要属性

• mNativeLibDir：存储插件 Native Library 拷贝到宿主后的存放目录路径。该路径在 getInstance(Context context) 方法中被赋值，确保插件的 so 库能被宿主正确识别。

  private String mNativeLibDir = null;
  

• mPackagesHolder：HashMap 结构，key 为包名，value 为表示插件信息的 DLPluginPackage 对象。它存储了所有已经成功加载过的插件信息，便于快速查找和管理。

  private final HashMap<String, DLPluginPackage> mPackagesHolder = new HashMap<String, DLPluginPackage>();
  

主要函数分析

(1) getInstance(Context context) 获取 DLPluginManager 对象的单例。在私有构造函数中，将 mNativeLibDir 变量赋值为宿主 App 应用程序数据目录下名为 pluginlib 子目录的全路径。这确保了插件的 native 库有独立的存储空间。

private DLPluginManager(Context context) {
    mContext = context.getApplicationContext();
    mNativeLibDir = mContext.getDir("pluginlib", Context.MODE_PRIVATE).getAbsolutePath();
}

(2) loadApk(String dexPath) 加载插件的入口函数。参数 dexPath 为插件的文件路径。该函数直接调用重载的 loadApk(final String dexPath, boolean hasSoLib) 方法，默认假设插件不包含 so 库或需特殊处理。

/**
 * Load a apk. Before start a plugin Activity, we should do this first.<br/>
 * NOTE : will only be called by host apk.
 * 
 * @param dexPath
 */
public DLPluginPackage loadApk(String dexPath) {
    // when loadApk is called by host apk, we assume that plugin is invoked
    // by host.
    return loadApk(dexPath, true);
}

(3) loadApk(final String dexPath, boolean hasSoLib) 加载插件 APK 的核心逻辑。参数 dexPath 为插件路径，hasSoLib 表示插件是否含有 so 库。注意：在启动插件的组件前，必须先调用此函数加载插件，并且只能在宿主中调用。

加载过程包括获取 PackageInfo、准备插件环境、拷贝 so 库等步骤。如果插件包含 so 库，则调用 copySoLib 进行拷贝。

public DLPluginPackage loadApk(final String dexPath, boolean hasSoLib) {
    mFrom = DLConstants.FROM_EXTERNAL;

    PackageInfo packageInfo = mContext.getPackageManager().getPackageArchiveInfo(dexPath,
            PackageManager.GET_ACTIVITIES | PackageManager.GET_SERVICES);
    if (packageInfo == null) {
        return null;
    }

    DLPluginPackage pluginPackage = preparePluginEnv(packageInfo, dexPath);
    if (hasSoLib) {
        copySoLib(dexPath);
    }

    return pluginPackage;
}

(4) preparePluginEnv(PackageInfo packageInfo, String dexPath) 加载插件及其运行时环境。该函数依次调用 createDexClassLoader、createAssetManager、createResources 完成相应初始化部分，最终封装成 DLPluginPackage 对象存入缓存。

private DLPluginPackage preparePluginEnv(PackageInfo packageInfo, String dexPath) {
    DLPluginPackage pluginPackage = mPackagesHolder.get(packageInfo.packageName);
    if (pluginPackage != null) {
        return pluginPackage;
    }
    DexClassLoader dexClassLoader = createDexClassLoader(dexPath);
    AssetManager assetManager = createAssetManager(dexPath);
    Resources resources = createResources(assetManager);
    // create pluginPackage
    pluginPackage = new DLPluginPackage(dexClassLoader, resources, packageInfo);
    mPackagesHolder.put(packageInfo.packageName, pluginPackage);
    return pluginPackage;
}

(5) createDexClassLoader(String dexPath) 利用 DexClassLoader 加载插件代码。DexClassLoader 的初始化需要四个参数：dex 路径、优化目录、库路径、父 ClassLoader。

• dexPath：插件的路径。
• optimizedDirectory：宿主内 dex 存放路径，通常设置为当前 App 数据目录下的 dex 子目录。
• libraryPath：Native Library 存放的路径，即 mNativeLibDir。
• parent：父 ClassLoader，采用双亲委托模式查找类。

private DexClassLoader createDexClassLoader(String dexPath) {
    File dexOutputDir = mContext.getDir("dex", Context.MODE_PRIVATE);
    dexOutputPath = dexOutputDir.getAbsolutePath();
    DexClassLoader loader = new DexClassLoader(dexPath, dexOutputPath, mNativeLibDir, mContext.getClassLoader());
    return loader;
}

(6) createAssetManager(String dexPath) 创建 AssetManager 以加载插件资源。由于插件化后宿主无法直接通过 R 文件访问插件资源，这里使用反射生成属于插件的 AssetManager，并利用 addAssetPath 函数加载插件资源路径。

private AssetManager createAssetManager(String dexPath) {
    try {
        AssetManager assetManager = AssetManager.class.newInstance();
        Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);
        addAssetPath.invoke(assetManager, dexPath);
        return assetManager;
    } catch (Exception e) {
        e.printStackTrace();
        return null;
    }
}

(7) createResources(AssetManager assetManager) 利用 AssetManager 中已经加载的资源创建 Resources 对象，供代理组件读取插件资源使用。

private Resources createResources(AssetManager assetManager) {
    Resources superRes = mContext.getResources();
    Resources resources = new Resources(assetManager, superRes.getDisplayMetrics(), superRes.getConfiguration());
    return resources;
}

(8) copySoLib(String dexPath) 调用 SoLibManager 拷贝 so 库到 Native Library 目录，确保插件的原生代码能在宿主环境中运行。

private void copySoLib(String dexPath) {
    SoLibManager.getSoLoader().copyPluginSoLib(mContext, dexPath, mNativeLibDir);
}

(9) startPluginActivity(Context context, DLIntent dlIntent) 启动插件 Activity 的接口，内部会调用 startPluginActivityForResult 函数。插件内部 Activity 启动依然遵循 Android 原生方式调用 Context#startActivity。

(10) startPluginActivityForResult(Context context, DLIntent dlIntent, int requestCode) 启动插件 Activity 的详细逻辑。流程如下：

1. 判断来源，如果是内部调用，直接设置类名并启动。
2. 从 Intent 中获取插件包名，校验是否存在。
3. 根据包名从 mPackagesHolder 获取插件信息。
4. 通过反射加载待启动的 Activity 类。
5. 获取对应的代理 Activity 类。
6. 设置 Intent 参数，将代理类设置进 Intent 中，然后执行原生启动。

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
public int startPluginActivityForResult(Context context, DLIntent dlIntent, int requestCode) {
    //内部调用，原生方式启动 Activity
    if (mFrom == DLConstants.FROM_INTERNAL) {
        dlIntent.setClassName(context, dlIntent.getPluginClass());
        performStartActivityForResult(context, dlIntent, requestCode);
        return DLPluginManager.START_RESULT_SUCCESS;
    }
    //拿出 Intent 中的 packageName
    String packageName = dlIntent.getPluginPackage();
    if (TextUtils.isEmpty(packageName)) {
        throw new NullPointerException("disallow null packageName.");
    }
    //在 Map 集合 mPackagesHolder 中根据 packageName 拿出插件信息 DLPluginPackage
    DLPluginPackage pluginPackage = mPackagesHolder.get(packageName);
    //判断插件是否存在于 mPackagesHolder 中
    if (pluginPackage == null) {
        return START_RESULT_NO_PKG;
    }
    //根据 pluginPackage 得到待启动 Activity 全路径
    final String className = getPluginActivityFullPath(dlIntent, pluginPackage);
    //通过反射加载这个待启动 Activity 类
    Class<?> clazz = loadPluginClass(pluginPackage.classLoader, className);
    if (clazz == null) {
        return START_RESULT_NO_CLASS;
    }

    // get the proxy activity class, the proxy activity will launch the
    // plugin activity.
    //得到启动 Activity 类的代理类
    Class<? extends Activity> activityClass = getProxyActivityClass(clazz);
    if (activityClass == null) {
        return START_RESULT_TYPE_ERROR;
    }

    // put extra data
    //设置 dlIntent 的相关参数，将代理类设置进 dlIntent 中，还要设置 Activity 全路径，插件的包名 packageName
    dlIntent.putExtra(DLConstants.EXTRA_CLASS, className);
    dlIntent.putExtra(DLConstants.EXTRA_PACKAGE, packageName);
    dlIntent.setClass(mContext, activityClass);
    performStartActivityForResult(context, dlIntent, requestCode);
    return START_RESULT_SUCCESS;
}

其中 performStartActivityForResult 负责实际的跳转调用，getPluginActivityFullPath 处理类名的拼接逻辑，loadPluginClass 使用 Class.forName 进行反射加载，getProxyActivityClass 根据插件 Activity 继承关系返回对应的代理类。

(11) startPluginService(final Context context, final DLIntent dlIntent) 启动插件 Service。主要逻辑在 fetchProxyServiceClass 中，流程与 startPluginActivity 类似，只是换成了回调的方式，在各种条件成立后调用原生方式启动代理 Service。

(12) stopPluginService / bindPluginService / unBindPluginService 停止、绑定和解绑插件 Service。逻辑均复用 fetchProxyServiceClass 获取代理 Service 类，然后调用原生的 Service 生命周期方法。

5. 技术难点与扩展思考

在实际开发中，基于 DynamicLoadApk 进行插件化开发需要注意以下几点：

1. 资源冲突：虽然框架提供了 AssetManager 隔离，但如果多个插件使用了相同的资源 ID，可能会导致覆盖。建议在插件开发阶段规范资源命名空间。
2. 性能开销：每次启动插件都需要经过反射和类加载过程，相比原生启动会有轻微延迟。对于频繁切换的页面，建议做好预加载策略。
3. 安全性：插件 APK 的签名必须与宿主一致，否则可能无法安装或运行。同时，应防止恶意插件注入，对加载的 APK 进行完整性校验。
4. 版本兼容：不同版本的 Android 系统对 DexClassLoader 和 AssetManager 的实现细节有所不同，框架需要针对特定系统进行适配。

6. 总结

DynamicLoadApk 通过代理模式和自定义类加载器实现了插件的动态加载。其核心在于 DLPluginManager 对插件生命周期的管理，以及通过反射机制绕过 Android 系统对组件注册的限制。理解这一机制对于深入掌握 Android 高级特性至关重要。