插件化篇插件化框架对比

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

目录&＃xff1a;

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

1. MulitDex 引起的问题

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

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

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

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

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

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

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

• 2.2 解决方案

针对问题 1&＃xff1a;

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

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

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

public.xml:

build.gradle:

afterEvaluate {for (variant in android.applicationVariants) {def scope &＃61; variant.getVariantData().getScope()String mergeTaskName &＃61; scope.getMergeResourcesTask().namedef mergeTask &＃61; tasks.getByName(mergeTaskName)mergeTask.doLast {copy {int i&＃61;0from(android.sourceSets.main.res.srcDirs) {include &＃39;values/public.xml&＃39;rename &＃39;public.xml&＃39;, (i&＃43;&＃43; &＃61;&＃61; 0? "public.xml": "public_${i}.xml")}into(mergeTask.outputDir)}}}
}

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

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

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

针对问题 2&＃xff1a;

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

• 方案 1&＃xff1a;简单加载模式。
• 方案 2&＃xff1a;Activity 代理模式。
• 方案 3&＃xff1a;动态加载模式。

针对问题 3&＃xff1a;

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

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

• AndroidDynamicLoader

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

• 23Code

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

• Altas

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

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

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

• Dynamic-load-apk

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

• DroidPlugin

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

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

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

• VirtualApp

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

• DynamicAPK

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

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

整体对比如下&＃xff1a;