VirtualAPK：滴滴 Android 插件化的实践之路

作者简介： 任玉刚，滴滴出行 Android 技术专家，《Android 开发艺术探索》作者，插件化框架 dynamic-load-apk 的发起者，CSDN 移动开发博客专家，曾当选 CSDN 2014、2015年度十大博客之星。热爱技术，热爱开源，凡事喜欢刨根问底，长期活跃在 CSDN 和 GitHub。目前就职于滴滴出行 App 架构组，从事热修复和插件化相关的开发工作。
博客地址：http://blog.csdn.net/singwhatiwanna；
GitHub：https://github.com/singwhatiwanna。
本文为 CSDN 首发，欢迎技术投稿、约稿，给文章纠错，请发送邮件至mobile@csdn.net。

一、前言

在 Android 插件化技术日新月异的今天，开发并落地一款插件化框架到底是简单还是困难，这个问题不同人会有不同的答案。但是我相信，完成一个插件化框架的 Demo 并不是多难的事儿，然而要开发一款完善的插件化框架却并非易事，尤其在国内，各大 ROM 厂商都对 Android 系统做了一定程度的定制，这更进一步加剧了 Android 本身的碎片化问题。

滴滴出行在插件化上的探索起步较晚，由于业务发展较快，迭代占据了大量的时间，这使得我们在2016年才开始研究这方面的技术。经过半年的开发、测试、适配和线上验证，今天，我们正式推出一款较为完善的插件化框架——VirtualAPK。之所以现在推出，是因为 VirtualAPK 在内部已经得到了很好的验证，我们在迭代过程中不断地做机型适配和细节特性的支持，目前已达到一个非常稳定的状况，足以支撑滴滴部分乃至全部业务的动态发版需求。目前滴滴出行最新版本（v5.0.4）上，小巴和接送机业务均为插件，大家可以去体验。

二、插件化的现状

到目前为止，业界已经有很多优秀的开源项目，比如早期的基于静态代理思想的 DynamicLoadApk，随后的基于占坑思想的 DynamicApk、Small，还有360手机助手的 DroidPlugin。它们都是优秀的开源项目，很大程度上促进了国内插件化技术的发展。

尽管有如此多的优秀框架存在，但是兼容性问题仍然是制约插件化发展的一大难题。一款插件化框架，也许可以在一款手机上完美运行，但是在数以千万的设备上却总是容易存在这样那样的兼容性问题。我相信上线过插件化的工程师应该深有体会。滴滴为什么还要自研一款新的插件化框架？因为我们需要一款功能完备、兼容性优秀、适用于滴滴业务的插件化框架，目前市面上的开源不能满足我们的需求，所以必须重新造轮子，于是 VirtualAPK 诞生了。

三、VirtualAPK 的诞生

VirtualAPK 是滴滴出行自研的一款优秀的插件化框架，主要有如下几个特性。

1. 功能完备

支持几乎所有的 Android 特性；
四大组件方面：四大组件均不需要在宿主manifest中预注册，每个组件都有完整的生命周期。
- Activity：支持显示和隐式调用，支持 Activity 的 theme 和 LaunchMode，支持透明主题；
- Service：支持显示和隐式调用，支持 Service 的 start、stop、bind 和 unbind，并支持跨进程 bind 插件中的 Service；
- Receiver：支持静态注册和动态注册的 Receiver；
- ContentProvider：支持 provider的所有操作，包括 CRUD 和 call 方法等，支持跨进程访问插件中的 Provider。
自定义View：支持自定义 View，支持自定义属性和 style，支持动画；
PendingIntent：支持 PendingIntent 以及和其相关的 Alarm、Notification 和AppWidget；
支持插件 Application 以及插件 manifest 中的 meta-data；
支持插件中的so。

2. 优秀的兼容性

兼容市面上几乎所有的 Android 手机，这一点已经在滴滴出行客户端中得到验证；
资源方面适配小米、Vivo、Nubia 等，对未知机型采用自适应适配方案；
极少的 Binder Hook，目前仅仅 hook 了两个 Binder：AMS 和 IContentProvider，Hook过程做了充分的兼容性适配；
插件运行逻辑和宿主隔离，确保框架的任何问题都不会影响宿主的正常运行。

3. 入侵性极低

插件开发等同于原生开发，四大组件无需继承特定的基类；
精简的插件包，插件可以依赖宿主中的代码和资源，也可以不依赖；
插件的构建过程简单，通过Gradle插件来完成插件的构建，整个过程对开发者透明。

四、VirtualAPK 的工作过程

VirtualAPK 对插件没有额外的约束，原生的 apk 即可作为插件。插件工程编译生成 apk 后，即可通过宿主 App 加载，每个插件 apk 被加载后，都会在宿主中创建一个单独的 LoadedPlugin 对象。如下图所示，通过这些 LoadedPlugin 对象，VirtualAPK 就可以管理插件并赋予插件新的意义，使其可以像手机中安装过的App一样运行。

1. VirtualAPK 的运行形态

我们计划赋予 VirtualAPK 两种工作形态，耦合形态和独立形态。目前 VirtualAPK 对耦合形态已经有了很好的支持，接下来将计划支持独立形态。

耦合形态：插件对宿主可以有代码或者资源的依赖，也可以没有依赖。这种模式下，插件中的类不能和宿主重复，资源 id 也不能和宿主冲突。这是 VirtualAPK 的默认形态，也是适用于大多数业务的形态。
独立形态：插件对宿主没有代码或者资源的依赖。这种模式下，插件和宿主没有任何关系，所以插件中的类和资源均可以和宿主重复。这种形态的主要作用是用于运行一些第三方 apk。

2. 如何使用

第一步：初始化插件引擎

@Override
protected void attachBaseContext(Context base) {super.attachBaseContext(base);PluginManager.getInstance(base).init();
}

第二步：加载插件

public class PluginManager {public void loadPlugin(final File apk);public void loadPlugin(final String moduleCode);
}

我们对上述加载过程进行了一些封装，通过如下方式即可异步地去加载一个插件。

// 示例：启动插件中的Activity
DownloadManager downloadManager = DownloadManager.getInstance(this);
downloadManager.loadModule("com.ryg.test", true, this, new ILoadListener() {@Overridepublic void onLoadEnd(int resultCode) {if (resultCode == ILoadListener.LOAD_SUCCESS) {Intent intent = new Intent();intent.setClassName("com.ryg.test", "com.ryg.test.MainActivity");startActivity(intent);} else {// todo load plugin failed}}
});

当插件入口被调用后，插件的后续逻辑均不需要宿主干预，均走原生的 Android 流程。比如，在插件内部，如下代码将正确执行：

@Override
protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_book_manager);LinearLayout holder = (LinearLayout)findViewById(R.id.holder);TextView imei = (TextView)findViewById(R.id.imei);imei.setText(IDUtil.getUUID(this));// bind service in pluginIntent service = new Intent(this, BookManagerService.class);bindService(service, mConnection, Context.BIND_AUTO_CREATE);// start activity in pluginIntent intent = new Intent(this, TCPClientActivity.class);startActivity(intent);
}

五、探究原理

1. 基本原理

合并宿主和插件的ClassLoader：需要注意的是，插件中的类不可以和宿主重复；
合并插件和宿主的资源：重设插件资源的packageId，将插件资源和宿主资源合并；
去除插件包对宿主的引用：构建时通过 Gradle 插件去除插件对宿主的代码以及资源的引用。

2. 四大组件的实现原理

Activity：采用宿主 manifest 中占坑的方式来绕过系统校验，然后再加载真正的 Activity；
Service：动态代理 AMS，拦截 Service 相关的请求，将其中转给一个虚拟空间（Matrix）去处理，Matrix 会接管系统的所有操作；
Receiver：将插件中静态注册的 Receiver 重新注册一遍；
ContentProvider：动态代理 IContentProvider，拦截 Provider 相关的请求，将其中转给一个虚拟空间（Matrix）去处理，Matrix 会接管系统的所有操作。

以下是 VirtualAPK 的整体结构图。

六、填坑之路

在实践中我们遇到了很多很多的问题，比如机型适配、API 版本适配、Binder Hook 的稳定性保证等问题，这里拿一个典型的资源适配问题来说明。

其实这是一个很无奈的问题，由于国内各大 ROM 厂商喜欢深度定制 Android 系统，所以就出现了这种适配问题。

正常情况下我们通过如下代码去创建插件的 Resources 对象：

Resources newResources = new Resources(assetManager,hostResources.getDisplayMetrics(), hostResources.getConfiguration());

然后在 Vivo 手机上，竟然出现了如下的类型转换错误，看起来是 Vivo 自己派生了 Resources 的子类。

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.sdu.didi.psnger/com.didi.virtualapk.core.A$1}: java.lang.ClassCastException: android.content.res.Resources cannot be cast to android.content.res.VivoResourcesat android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2196)at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)at android.app.ActivityThread.access$800(ActivityThread.java:140)at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1202)at android.os.Handler.dispatchMessage(Handler.java:102)at android.os.Looper.loop(Looper.java:136)at android.app.ActivityThread.main(ActivityThread.java:5143)at java.lang.reflect.Method.invokeNative(Native Method)at java.lang.reflect.Method.invoke(Method.java:515)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:602)at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassCastException: android.content.res.Resources cannot be cast to android.content.res.VivoResourcesat android.app.ResourcesManager.getTopLevelResources(ResourcesManager.java:236)at android.app.ContextImpl.<init>(ContextImpl.java:2057)at android.app.ContextImpl.createActivityContext(ContextImpl.java:2008)at android.app.ActivityThread.createBaseContextForActivity(ActivityThread.java:2207)at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2140)... 11 more

于是反编译了下 Vivo 的 Framework 代码，果不其然，在如下代码中进行了类型转换，所以在加载插件资源的时候就报错了。

@VivoHook(hookType = VivoHookType.NEW_METHOD)public Resources getTopLevelResources(String pkgName, String resDir, int displayId, Configuration overrideConfiguration, CompatibilityInfo compatInfo, IBinder token) {Resources resources = getTopLevelResources(resDir, displayId, overrideConfiguration, compatInfo, token);if (resources != null) {((VivoResources) resources).init(pkgName);}return resources;}

为了解决这个问题，我们分析了 VivoResources 的代码实现，然后在创建插件资源的时候，采用了如下的代码。

private static final class VivoResourcesCompat {private static Resources createResources(Resources hostResources, AssetManager assetManager) throws Exception {Class resourcesClazz = Class.forName("android.content.res.VivoResources");Resources newResources = (Resources)ReflectUtil.invokeConstructor(resourcesClazz,new Class[]{AssetManager.class, DisplayMetrics.class, Configuration.class},new Object[]{assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration()});return newResources;}
}