插件化篇 - 插件化框架对比

来看看现有插件化框架的对比。

MulitDex 引起的问题
插件化需要解决的问题与方案
插件化实现方案分析对比

1. MulitDex 引起的问题

在应用安装到手机上的时候 dex 文件的安装是复杂的，有可能会因为第二个 dex 文件太大导致 ANR。使用了 mulitDex 的 App 有可能在 4.0(api level 14) 以前的机器上无法启动，因为 Dalvik linearAlloc bug(Issue 22586) 。使用了 mulitDex 的 App 在 runtime期间有可能因为 Dalvik linearAlloc limit (Issue 78035) Crash。该内存分配限制在 4.0 版本被增大，但是 5.0 以下的机器上的 Apps 依然会存在这个限制。

主 dex 被 dalvik 虚拟机执行时候，哪些类必须在主 dex 文件里面这个问题比较复杂。build tools 可以搞定这个问题。但是如果你代码存在反射和 native 的调用也不保证 100% 正确。

对于 davilk 和 art 虚拟机 Mulitdex 的不同: ART 模式相比原来的 Dalvik，会在安装 APK 的时候，使用 Android 系统自带的dex2oat 工具把 APK 里面的 .dex 文件转化成 OAT 文件。

这里说一下罗迪的快速加载 Mulitdex 方案：art 虚拟机对 dex 优化需要很长时间，加载插件 dex 跳过优化实现加速，跳过会影响类加载的性能。

2. 插件化需要解决的问题与方案

2.1 实现插件化需要解决的技术点

问题 1：资源如何加载，资源冲突问题如何解决。
问题 2：代码如何加载访问。
问题 3：插件的管理后台包括的内容。
问题 4：插件的增量更新问题。
问题 5：加载插件中的 so 库。

2.2 解决方案

针对问题 1：

原理：资源 id 是在编译时生成的，其生成的规则是 0xPPTTNNNN，PP 段是用来标记 apk 的，默认情况下系统资源 PP 是01，应用程序的 PP 是 07。TT 段，是用来标记资源类型的，比如图标、布局等，相同的类型 TT 值相同，但是同一个 TT 值不代表同一种资源，例如这次编译的时候可能使用 03 作为 layout 的 TT，那下次编译的时候可能会使用 06 作为TT的值，具体使用那个值，实际上和当前 APP 使用的资源类型的个数是相关联的。NNNN 则是某种资源类型的资源 id，默认从1 开始，依次累加。

那么我们要解决资源 id 问题，就可从 TT 的值开始入手，只要将每次编译时的 TT 值固定，即可以让资源 id 达到分组的效果，从而避免重复。例如将宿主程序的 layout 资源的 TT 固定为 33，将插件程序资源的 layout 的 TT 值固定为 03 (可不对插件程序的资源 id 做任何处理，使其使用编译出来的原生的值)，即可解决资源 id 重复的问题了。

固定资源 id 的 TT 值的办法非常简单，提供一份 public.xml，在 public.xml 中指定什么资源类型以什么 TT 值开头即可。比如：

public.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <public type="mipmap" name="ic_launcher" id="0x7f030001" />
    <public type="drawable" name="ic_notice" id="0x7f02002b" />


    <!--<public-padding type="drawable" name="abc_" start="0x7f120000" end="0x7f12ffff" />-->
</resources>

build.gradle:

afterEvaluate {
    for (variant in android.applicationVariants) {
        def scope = variant.getVariantData().getScope()
        String mergeTaskName = scope.getMergeResourcesTask().name
        def mergeTask = tasks.getByName(mergeTaskName)

        mergeTask.doLast {
            copy {
                int i=0
                from(android.sourceSets.main.res.srcDirs) {
                    include 'values/public.xml'
                    rename 'public.xml', (i++ == 0? "public.xml": "public_${i}.xml")
                }

                into(mergeTask.outputDir)
            }
        }
    }
}

这样就能使用 public.xml 固定资源 id，public.xml 用来告诉 Android 资源打包工具 aapt，将类型为 drawable 的资源 ic_notice 的id 固定为 0x7f02002b。注意，在开发应用程序时，一般是不需要用到 public.xml 文件的，因为我们的资源基本上都是在内部使用的，不会导出来给第三方应用程序使用。只在内部使用的资源，不管它的 id 如何变化，我们都可以通过 R.java 文件定义的常量来正确地引用它们。只有系统定义的资源包才会使用到 public.xml 文件，因为它定义的资源是需要提供给第三方应用程序使用的。当然还有做插件化的时候，处理资源冲突问题。

还有一个方法是通过定制过的 aapt 在编译时指定插件的 PP 段的值来实现分组，重写过的 aapt 指定 PP 段来实现 id 分组。

方案 1：将插件 apk 资源解压，通过操作文件的方式来使用，这个只是理论上可行，实际使用的时候还是有很多的问题。
方案 2：重写 Context 的 getResource()、getAsset() 之类的方法，资源冲突需要扩展 aapt 实现。
方案 3：打包后执行一个脚本修改资源 id。

针对问题 2：

原理说明：主要就是 classloader 加载 dex，代理模式就是本身宿主中有 Activity，通过欺骗系统来创建 Activity，欺骗系统的部分 hook 的有深有浅 (对比 DroidPlugin 和 Small)，让这个 Activity 有生命周期，而动态加载模式就是运行时动态创建并编译一个 Activity 类，需要使用动态创建类的工具实现动态字节码操作。

方案 1：简单加载模式。
方案 2：Activity 代理模式。
方案 3：动态加载模式。

针对问题 3：

提供插件信息查询和下载，包括回滚到某一版本。
管理使用插件的 apk，可以向不同版本 apk 提供不同插件。
MD5 校检插件的合法性。

3. 插件化实现方案分析对比

AndroidDynamicLoader

AndroidDynamicLoader 的作者是大众点评的屠毅敏，应该是最早的动态加载实现方案了。作者在介绍这个框架时形容宿主 App就好像浏览器，但它加载的并不是网页，而是运行在 Android 系统上的插件。这个方案主要是在插件中使用 Fragment，在宿主中使用 Activity 去动态加载插件中的 Fragment。
github 链接：https://github.com/mmin18/AndroidDynamicLoader

23Code

23Code 并不是一个开源的项目，它是一个完整的 apk。在应用市场可以下载得到，它内部展示了一些有趣的动效，通过下载的方式，可以直接运行起来，这就是插件化的真实案例。

Altas

altas 是阿里的伯奎分享出来的一个插件化的方案。
分享视频链接：http://v.youku.com/v_show/id_XNTMzMjYzMzM2.html
对应的 PPT：http://club.alibabatech.org/resource_detail.htm?topicId=84

这里的分享主要是将一些思路，业务方面的场景，解决的问题。后来 github 上有了对应的开源项目叫 OpenAltas，后改名ACDD。
ACDD 的链接：https://github.com/bunnyblue/ACDD

官方对这个库的说明是非代理 Android 动态热部署框架，而且在视频介绍中，伯奎也讲到，这个方案，就是把宿主当做一个容器，动态加载对应的插件。视频中也有讲到，要做到让插件无感知地运行在这个容器中，需要 hook 很多系统层面的东西，比如：ActivityThread，LoadedApk，ContextImpl，PackageParser，ActivityManagerNative 等，即当插件需要系统的服务来提供对应功能的时候，将这个行为拦截掉，宿主就可以在插件和 Android 系统中间做些手脚了。在当时，Altas 是最为先进插件化技术了，为淘宝客户端提供了很多加载其他业务插件的能力。

Dynamic-load-apk

Dynamic-Load-Apk 简称 DL，这个开源框架作者是任玉刚，他的实现方式是，在宿主中埋一个代理 Activity，更改 ClassLoader后找到加载插件中的 Activity，使用宿主中的 Activity 作为代理，回调给插件中 Activity 所以对应的生命周期。这个思路与AndroidDynamicLoader 有点像，都是做一个代理，只不过 Dynamic-load-apk 加载的插件中的 Activity。
项目地址：https://github.com/singwhatiwanna/dynamic-load-apk
项目说明：http://blog.csdn.net/singwhatiwanna/article/details/40283117

DroidPlugin

DroidPlugin 是张勇实现的一套插件化方案，它的原理也是 Hook 客户端一侧的系统 API，可能与 Altas 所 Hook 的点不同，细想应该是基本相同的。
项目地址：https://github.com/DroidPluginTeam/DroidPlugin

项目中 DOC 文件夹有很多关于项目的讲解说明。
张勇本人对 DroidPlugin 的讲解：http://www.infoq.com/cn/presentations/the-realization-principle-and-application-of-droidplugin?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=presentations_link&utm_content=link_text
维术对这个框架的讲解：http://weishu.me/2016/01/28/understand-plugin-framework-overview/

维术的这几篇 blog 很详细滴讲解了 DroidPlugin 是如何实现四大组件的插件化的，还有几篇有规划但是没有写的方面，希望后面能补全。

VirtualApp

VirtualApp 作者是高中生罗迪，据说这个 Android 大牛初三的时候就开始研究双开、插件化的技术，相当了不起。项目的思路与DroidPlugin 相似，不过他没有提供 Service 的代理，而是使用 ContentProvider 来代替 Service 在宿主中作为真正的运行体。
项目地址：https://github.com/asLody/VirtualApp

DynamicAPK

DynamicAPK 是携程推出的动态加载方案。
项目说明：http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading
项目地址：https://github.com/CtripMobile/DynamicAPK

与 ACDD 一样修改了aapt，使得插件与宿主的资源不会出现相同 id 的问题。

整体对比如下：

插件化篇 - 插件化框架对比

猜你喜欢