DynamicLoadApk 源码解析

(1) 宿主：主 App，可以加载插件，也称 Host。

(2) 插件：插件 App，被宿主加载的 App，也称 Plugin，可以是跟普通 App 一样的 Apk 文件。

上面是 DynamicLoadApk 的总体设计图，DynamicLoadApk 主要分为四大模块：

(1) DLPluginManager

插件管理模块，负责插件的加载、管理以及启动插件组件。

(2) Proxy

代理组件模块，目前包括 DLProxyActivity(代理 Activity)、DLProxyFragmentActivity(代理 FragmentActivity)、DLProxyService(代理 Service)。

(3) Proxy Impl

代理组件公用逻辑模块，与(2)中的 Proxy 不同的是，这部分并不是一个组件，而是负责构建、加载插件组件的管理器。这些 Proxy Impl 通过反射得到插件组件，然后将插件与 Proxy 组件建立关联，最后调用插件组件的 onCreate 函数进行启动。

(4) Base Plugin

插件组件的基类模块，目前包括 DLBasePluginActivity(插件 Activity 的基类)、DLBasePluginFragmentActivity(插件 FragmentActivity 的基类)、DLBasePluginService(插件 Service 的基类)。

上面是调用插件 Activity 的流程图，其他组件调用流程类似。

(1) 首先通过 DLPluginManager 的 loadApk 函数加载插件，这步每个插件只需调用一次。

(2) 通过 DLPluginManager 的 startPluginActivity 函数启动代理 Activity。

(3) 代理 Activity 启动过程中构建、启动插件 Activity。

以上是 DynamicLoadApk 主要类的关系图，跟总体设计中介绍的一样大致分为三部分。

(1) 对于 Proxy 部分，每个组件都存在 DLAttachable 接口，方便统一该组件不同类，如 Activity、FragmentActivity。每个组件的公共实现部分都统一放到了对应的 DLProxyImpl 中。

(2) 对于 Base Plugin 部分，每个组件都存在 DLPlugin 接口，同样是方便统一该组件不同类。

DynamicLoadApk 框架的核心类，主要功能包括：

(1) 插件的加载和管理；

(2) 启动插件的组件，目前包括 Activity、Service。

主要属性：

mNativeLibDir 为插件 Native Library 拷贝到宿主中后的存放目录路径。

mPackagesHolder HashMap，key 为包名，value 为表示插件信息的 DLPluginPackage ，存储已经加载过的插件信息。

主要函数：

(1) getInstance(Context context)

获取 DLPluginManager 对象的单例。

在私有构造函数中将 mNativeLibDir 变量赋值为宿主 App 应用程序数据目录下名为 pluginlib 子目录的全路径。

(2) loadApk(String dexPath)

加载插件。参数 dexPath 为插件的文件路径。

这个函数直接调用 loadApk(final String dexPath, boolean hasSoLib)。

(3) loadApk(final String dexPath, boolean hasSoLib)

加载插件 Apk。参数 dexPath 为插件的文件路径，hasSoLib 表示插件是否含有 so 库。

流程图如下：

loadApk 函数调用 preparePluginEnv 函数加载插件，图中虚线框为 preparePluginEnv 的流程图。

(4) preparePluginEnv(PackageInfo packageInfo, String dexPath)

加载插件及其资源。流程图如上图。

调用 createDexClassLoader(…) 、 createAssetManager(…) 、 createResources(…) 函数完成相应初始化部分。

(5) createDexClassLoader(String dexPath)

利用 DexClassLoader 加载插件，DexClassLoader 初始化函数如下：

其中 dexPath 为插件的路径。

optimizedDirectory 优化后的 dex 存放路径。这里将路径设置为当前 App 应用程序数据目录下名为 dex 的子目录中。

libraryPath 为 Native Library 存放的路径。这里将路径设置为 mNativeLibDir 属性，其在 getInstance(Context) 函数中已经初始化。

parent 父 ClassLoader，ClassLoader 采用双亲委托模式查找类，具体加载方式可见 ClassLoader 基础 。

(6) createAssetManager(String dexPath)

创建 AssetManager，加载插件资源。

在 Android 中，资源是通过 R.java 中的 id 来调用访问的。但是实现插件化之后，宿主是无法通过 R 文件访问插件的资源，所以这里使用反射来生成属于插件的 AssetManager ，并利用 addAssetPath 函数加载插件资源。

(7) createResources(AssetManager assetManager)

利用 AssetManager 中已经加载的资源创建 Resources ，代理组件中会从这个 Resources 中读取资源。

关于 AssetManager 、 Resources 深入的信息可参考： Android 应用程序资源的查找过程分析 。

(8) copySoLib(String dexPath)

调用 SoLibManager 拷贝 so 库到 Native Library 目录。

(9) startPluginActivity(Context context, DLIntent dlIntent)

启动插件 Activity，会直接调用 startPluginActivityForResult(…) 函数。

插件自己内部 Activity 启动依然是调用 Context#startActivity(…) 方法。

(10) startPluginActivityForResult(Context context, DLIntent dlIntent, int requestCode)

启动插件 Activity，流程图如下：

(11) startPluginService(final Context context, final DLIntent dlIntent)

启动插件 Service。

主要逻辑在函数 fetchProxyServiceClass(…) 中，流程与 startPluginActivity(…) 类似，只是换成了回调的方式，在各种条件成立后调用原生方式启动代理 Service，不再赘述。

(12) bindPluginService(…) unBindPluginService(…)

bind 或是 unBind 插件 Service。逻辑与 startPluginService(…) 类似，不再赘述。

packageName 为插件的包名；

defaultActivity 为插件的 Launcher Main Activity；

classLoader 为加载插件的 ClassLoader；

assetManager 为加载插件资源的 AssetManager；

resources 利用 assetManager 中已经加载的资源创建的 Resources ，代理组件中会从这个 Resources 中读取资源。

packageInfo 被 PackageManager 解析后的插件信息。

这些信息都会在 DLPluginManager#loadApk(…) 时初始化。

DLAttachable 是一个接口，主要作用是以统一所有不同类型的代理 Activity，如 DLProxyActivity 、 DLProxyFragmentActivity ，方便作为同一接口统一处理。

DLProxyActivity 和 DLProxyFragmentActivity 都实现了这个类。

DLPlugin 是一个接口，包含 Activity 生命周期、触摸、菜单等抽象函数。

DLBase*Activity 都实现了这个类，这样插件的 Activity 间接实现了此类。

主要作用是统一所有不同类型的插件 Activity，如 Activity 、 FragmentActivity ，方便作为同一接口统一处理，所以这个类叫 DLPluginActivity 更合适。

首先来看下它的成员变量。

(1). DLPlugin mRemoteActivity

表示真正需要启动的插件 Activity 。这个属性名应该叫做 pluginActivity 更合适。

上面我们已经介绍了， DLPlugin 是所有插件 Activity 都间接实现了的接口。

(2). DLProxyImpl impl

主要封装了插件 Activity 的公用逻辑，如初始化插件 Activity 并和代理 Activity 绑定、获取资源等。

主要函数：

(1) DLProxyImpl(Activity activity)

构造函数，参数为代理 Activity。

(2) public void onCreate(Intent intent)

onCreate 函数，会在代理 Activity onCreate 函数中被调用，流程图如下：

其中第一步 设置 intent 的 ClassLoader 是用于 unparcel Parcelable 数据的，可见介绍： android.os.BadParcelableException 。

(3) protected void launchTargetActivity()

加载待启动插件 Activity 完成初始化流程，并通过 DLPlugin 和 DLAttachable 接口的 attach 函数实现和代理 Activity 的双向绑定。流程图见上图虚线框部分。

(4) private void initializeActivityInfo()

获得待启动插件的 ActivityInfo。

(5) private void handleActivityInfo()

设置代理 Activity 的主题等信息。

DLBasePluginActivity 继承自 Activity ，同时实现了 DLPlugin 接口。这两个类大同小异，所以这里只分析 DLProxyActivity 。

主要变量：

mProxyActivity 为代理 Activity，通过 attach(…) 函数绑定。

that 与 mProxyActivity 等同，只是为了和 this 指针区分，表示真实的 Context ，这里真实指的是被代理情况下为代理 Activity，未被代理情况下等同于 this。

主要变量含义与 DLBasePluginActivity 类似，不重复介绍。

PS：截止目前这个类还是不完善的，至少和 DLBasePluginActivity 对比，还不支持非代理的情况

主要函数：

(1) copyPluginSoLib(Context context, String dexPath, String nativeLibDir)

函数中以 ZipFile 形式加载插件，循环读取其中的文件，如果为 .so 结尾文件、符合当前平台 CPU 类型且尚未拷贝过最新版，则新建 Runnable 拷贝 so 文件。

Eclipse 打包解决方式见项目主页；

Android Studio 打包解决方式见 5.2；

Ant 打包需要修改 build.xml 中 dex target 引用到的 compileclasspath 属性。

(1) 还未支持广播；

(2) Base Plugin 中的 that 还未去掉，需要覆写 Activity 的相关方法；

(3) 插件和宿主资源 id 可能重复的问题没有解决，需要修改 aapt 中资源 id 的生成规则；

(4) 不支持自定义主题，不支持系统透明主题；

(5) 插件中的 so 处理有异常；

(6) 不支持静态 Receiver；

(7) 不支持 Provider；

(8) 插件不能直接用 this；

除了 DynamicLoadApk 用代理的方式实现外，目前还有两种插件化方案：

(1) 用 Fragment 以及 schema 的方式实现。

(2) 利用字节码库动态生成一个插件类 A 继承自待启动插件 Activity，启动插件 A。这个插件 A 名称固定且已经在 Manifest 中注册。

具体可见： Android 插件化