VirtualAPK的特性
VirtualAPK是滴滴出行自研的一款优秀的插件化框架,主要有如下几个特性。
功能完备
- 支持几乎所有的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。
优秀的兼容性
- 兼容市面上几乎所有的Android手机,这一点已经在滴滴出行客户端中得到验证;
- 资源方面适配小米、Vivo、Nubia等,对未知机型采用自适应适配方案;
- 极少的Binder Hook,目前仅仅hook了两个Binder:AMS和IContentProvider,hook过程做了充分的兼容性适配;
- 插件运行逻辑和宿主隔离,确保框架的任何问题都不会影响宿主的正常运行。
入侵性极低
- 插件开发等同于原生开发,四大组件无需继承特定的基类;
- 精简的插件包,插件可以依赖宿主中的代码和资源,也可以不依赖;
- 插件的构建过程简单,通过Gradle插件来完成插件的构建,整个过程对开发者透明。
VirtualAPK和主流开源框架的对比
如下是VirtualAPK和主流的插件化框架之间的对比。
特性 | DynamicLoadApk | DynamicAPK | Small | DroidPlugin | VirtualAPK |
---|---|---|---|---|---|
支持四大组件 | 只支持Activity | 只支持Activity | 只支持Activity | 全支持 | 全支持 |
组件无需在宿主manifest中预注册 | √ | × | √ | √ | √ |
插件可以依赖宿主 | √ | √ | √ | × | √ |
支持PendingIntent | × | × | × | √ | √ |
Android特性支持 | 大部分 | 大部分 | 大部分 | 几乎全部 几乎全部 | |
兼容性适配 | 一般 | 一般 | 中等 | 高 | 高 |
插件构建 | 无 | 部署aapt | Gradle插件 | 无 | Gradle插件 |
为什么选择VirtualAPK?
已经有那么多优秀的开源的插件化框架,滴滴为什么要重新造一个轮子呢?
- 大部分开源框架所支持的功能还不够全面 除了DroidPlugin,大部分都只支持Activity。
- 兼容性问题严重,大部分开源方案不够健壮 由于国内Rom尝试深度定制Android系统,这导致插件框架的兼容性问题特别多,而目前已有的开源方案中,除了DroidPlugin,其他方案对兼容性问题的适配程度是不足的。
- 已有的开源方案不适合滴滴的业务场景 虽然说DroidPlugin从功能的完整性和兼容性上来看,是一款非常完善的插件框架,然而它的使用场景和滴滴的业务不符。
DroidPlugin侧重于加载第三方独立插件,比如微信,并且插件不能访问宿主的代码和资源。而在滴滴打车中,其他业务模块均需要宿主提供的订单、定位、账号等数据,因此插件不可能和宿主没有交互。
其实在大部分产品中,一个业务模块实际上并不能轻而易举地独立出来,它们往往都会和宿主有交互,在这种情况下,DroidPlugin就有点力不从心了。
基于上述几点,我们只能重新造一个轮子,它不但功能全面、兼容性好,还必须能够适用于有耦合的业务插件,这就是VirtualAPK存在的意义。
在加载耦合插件方面,VirtualAPK是开源方案的首选,推荐大家使用。
通俗易懂地说
- 如果你是要加载微信、支付宝等第三方APP,那么推荐选择DroidPlugin;
- 如果你是要加载一个内部业务模块,并且这个业务模块很难从主工程中解耦,那么VirtualAPK是最好的选择。
抽象地说
- 如果你要加载一个插件,并且这个插件无需和宿主有任何耦合,也无需和宿主进行通信,并且你也不想对这个插件重新打包,那么推荐选择DroidPlugin;
- 除此之外,在同类的开源中,推荐大家选择VirtualAPK。
VirtualAPK的工作过程
VirtualAPK对插件没有额外的约束,原生的apk即可作为插件。插件工程编译生成apk后,即可通过宿主App加载,每个插件apk被加载后,都会在宿主中创建一个单独的LoadedPlugin对象。如下图所示,通过这些LoadedPlugin对象,VirtualAPK就可以管理插件并赋予插件新的意义,使其可以像手机中安装过的App一样运行。
基本使用
VirtualAPK 对插件没有额外的约束,原生的apk即可作为插件。插件工程编译生成apk后,即可通过宿主App加载,每个插件apk被加载后,都会在宿主中创建一个单独的LoadedPlugin对象。通过这些LoadedPlugin对象,VirtualAPK就可以管理插件并赋予插件新的意义,使其可以像手机中安装过的App一样运行。
宿主项目的配置
1.在项目根目录的build.gradle文件中加入VirtualAPK依赖:
dependencies {
classpath 'com.didi.virtualapk:gradle:0.9.8.6'
}
2.在app根目录的buil.gradle文件中应用VirtualAPK host插件:
apply plugin: 'com.didi.virtualapk.host'
3.在app根目录的buil.gradle文件中引用VirtualAPK远程库:
dependencies {
implementation 'com.didi.virtualapk:core:0.9.6'
}
4.在项目Application中初始化插件:
public class BaseApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// 初始化VirtualAPK
PluginManager.getInstance(base).init();
}
@Override
public void onCreate() {
super.onCreate();
// 加载存储根目录的插件apk,实际项目中按需保存
File plugin = new File(Environment.getExternalStorageDirectory(), "plugin.apk");
if (plugin.exists()) {
try {
PluginManager.getInstance(this).loadPlugin(plugin);
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
不要忘了在清单文件中配置Application:
<application
android:name=".BaseApplication">
</application>
5.调用插件
com.lwx.plugin_login是插件工程的包名,com.lwx.plugin_login.LoginActivity是插件工程中的类,插件工程的包名可以和宿主工程相同,但是相同包名下的类名不能相同,资源名称也不能相同。
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.btn_main_activity_host).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if (PluginManager.getInstance(MainActivity.this).getLoadedPlugin("com.lwx.plugin_login") == null) {
Toast.makeText(MainActivity.this, "Plugin is not loaded!", Toast.LENGTH_SHORT).show();
} else {
Intent intent = new Intent();
intent.setClassName("com.lwx.plugin_login", "com.lwx.plugin_login.LoginActivity");
intent.putExtra("name","hehe");
intent.putExtra("pwd","123456");
startActivity(intent);
}
}
});
}
}
6.权限(6.0以上手机请动态申请,或手动在设置中打开权限)
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
7.混淆配置
-keep class com.didi.virtualapk.internal.VAInstrumentation { *; }
-keep class com.didi.virtualapk.internal.PluginContentResolver { *; }
-dontwarn com.didi.virtualapk.**
-dontwarn android.**
-keep class android.** { *; }
插件项目的配置
1.在项目根目录的build.gradle文件中加入VirtualAPK依赖(如果插件和宿主在同一个项目中,则不需要再重复添加):
dependencies {
classpath 'com.didi.virtualapk:gradle:0.9.8.6'
}
2.在app根目录(或插件module)的buil.gradle文件中应用VirtualAPK plugin插件:
apply plugin: 'com.didi.virtualapk.plugin'
3.在app根目录(或插件module)的buil.gradle文件中配置VirtualAPK:
需要在buil.gradle文件中的最后位置进行此配置
virtualApk {
// 插件资源表中的packageId,需要确保不同插件有不同的packageId
// 范围 0x1f - 0x7f
packageId = 0x6f
// 宿主工程application模块的路径,插件的构建需要依赖这个路径
// targetHost可以设置绝对路径或相对路径
// ../VirtualAPKHostDemo/app 代表 VirtualAPKDemo/VirtualAPKHostDemo/app
targetHost = '../VirtualAPKDemo/app'
// 默认为true,如果插件有引用宿主的类,那么这个选项可以使得插件和宿主保持混淆一致
applyHostMapping = true
}
构建宿主与插件
宿主
宿主的构建和正常apk的构建方式是相同的,可以通过Build > Generate Signed APK的方式,也可以通过下面的命令:
gradlew clean assembleRelease
如果不想输入命令,还可以这样:
构建完成的apk在app > build > outputs > apk > release目录下。
插件
插件采用下面的命令进行构建:
gradlew clean assemblePlugin
如果不想输入命令,还可以这样:
构建完成的apk在app > build > outputs > plugin > release目录下。
注意:因为assemblePlugin依赖于assembleRelease,所以插件包均是Release包,不支持debug模式的插件包。(出现找不到插件的问题时,先检查是否给插件配置签名文件)
到这里,宿主和插件就构建完成了,将插件apk拷贝至存储设备根目录,安装运行宿主apk,看下效果:
插件与宿主进行交互
插件和宿主通过引用相同依赖库的方式来进行交互,比如,宿主工程中引用了A库,
dependencies {
implementation 'com.x.x.x.A'
}
插件工程中如果也需要访问A库中的类和资源,那么可以在插件工程中同样引用A库,这样就可以和宿主工程共用A库了,插件构建的过程中会自动将A库从apk中剔除。
以一个全局变量举例:
A库中有一个全局变量V = false,如果在插件中将此变量设置为true,那么在宿主中获取到的V值则为true。
探究原理
基本原理
- 合并宿主和插件的ClassLoader 需要注意的是,插件中的类不可以和宿主重复
- 合并插件和宿主的资源 重设插件资源的packageId,将插件资源和宿主资源合并
- 去除插件包对宿主的引用 构建时通过Gradle插件去除插件对宿主的代码以及资源的引用
四大组件的实现原理
- Activity 采用宿主manifest中占坑的方式来绕过系统校验,然后再加载真正的activity;
- Service 动态代理AMS,拦截service相关的请求,将其中转给Service Runtime去处理,Service Runtime会接管系统的所有操作;
- Receiver 将插件中静态注册的receiver重新注册一遍;
- ContentProvider 动态代理IContentProvider,拦截provider相关的请求,将其中转给Provider Runtime去处理,Provider Runtime会接管系统的所有操作。
如下是VirtualAPK的整体架构图,更详细的内容请大家阅读源码。
原理详解可以看大神的博客:https://blog.csdn.net/lmj623565791/article/details/75000580
demo地址