BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

滴滴插件化项目VirtualAPK开源

| 作者 滴滴App架构组 关注 2 他的粉丝 发布于 2017年7月1日. 估计阅读时间: 12 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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

我们在2016年开始研究这方面的技术,经过半年的开发、测试、适配和线上验证,目前推出了一款比较完善的插件化框架:VirtualAPK。

之所以现在推出来,是因为VirtualAPK在我们内部已经得到了很好的验证,我们在迭代过程中不断地做机型适配和细节特性的支持,目前已经达到一个非常稳定的状况,足以支撑滴滴部分乃至全部业务的动态发版需求。目前VirtualAPK应用于滴滴乘客端和优步中国APP中,大家可以去体验。

为了更好地体现出VirtualAPK的价值,我们决定将其开源,请猛击https://github.com/didi/VirtualAPK 。

VirtualAPK也是滴滴公司的首个对外开源项目,欢迎大家star、发送pull request,也欢迎大家来使用VirtualAPK,我们会给予一定的技术支持。

VirtualAPK能为我们带来什么?

在传统的APP发布过程中,总是存在着固定的发版节奏,比如两周或者一个月更新一次,这固然没有问题。但考虑一种情况,如果一个版本刚发布出去,却发现存在大量crash,这个时候我们会怎么办?大多数公司都会选择立刻发一个紧急版本,然后一批人需要手忙脚乱甚至加班来准备这个版本,所以紧急版本还是越少越好。

其实不仅仅是因为致命crash而紧急发版,比如一个早期创业公司,需要通过迅速的“试错”来尝试找准市场的方向,这个时候就需要更加紧凑的发版方式,有些时候甚至想一天发一次版。在正常的发版流程中,这显然是不现实的。但是如果这家创业公司必须要随时可以发版,否则就可能被竞争对手抢占先机,这个时候该怎么办呢?

上述的这两个问题,通过VirtualAPK,将不再是问题。通过VirtualAPK将业务模块插件化,然后就可以随时通过更新插件的方式来发布新功能,不管是修复致命crash还是进行业务“试错”,都是一种很爽快的体验。

VirtualAPK的特性

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

功能完备

  • 支持几乎所有的Android特性;
  • 四大组件方面

四大组件均不需要在宿主manifest中预注册,每个组件都有完整的生命周期。

  1. Activity:支持显示和隐式调用,支持Activity的theme和LaunchMode,支持透明主题;
  2. Service:支持显示和隐式调用,支持Service的start、stop、bind和unbind,并支持跨进程bind插件中的Service;
  3. Receiver:支持静态注册和动态注册的Receiver;
  4. ContentProvider:支持provider的所有操作,包括CRUD和call方法等,支持跨进程访问插件中的Provider。
  5. 自定义View:支持自定义View,支持自定义属性和style,支持动画;
  6. PendingIntent:支持PendingIntent以及和其相关的Alarm、Notification和AppWidget;
  7. 支持插件Application以及插件manifest中的meta-data;
  8. 支持插件中的so。

优秀的兼容性

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

入侵性极低

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

VirtualAPK和主流开源框架的对比

如下是VirtualAPK和主流的插件化框架之间的对比。

为什么选择VirtualAPK

已经有那么多优秀的开源的插件化框架,滴滴为什么要重新造一个轮子呢?

1. 大部分开源框架所支持的功能还不够全面 除了DroidPlugin,大部分都只支持Activity。

2. 兼容性问题严重,大部分开源方案不够健壮 由于国内Rom尝试深度定制Android系统,这导致插件框架的兼容性问题特别多,而目前已有的开源方案中,除了DroidPlugin,其他方案对兼容性问题的适配程度是不足的。

3. 已有的开源方案不适合滴滴的业务场景 虽然说DroidPlugin从功能的完整性和兼容性上来看,是一款非常完善的插件框架,然而它的使用场景和滴滴的业务不符。

DroidPlugin侧重于加载第三方独立插件,比如微信,并且插件不能访问宿主的代码和资源。而在滴滴打车中,其他业务模块均需要宿主提供的订单、定位、账号等数据,因此插件不可能和宿主没有交互。

其实在大部分产品中,一个业务模块实际上并不能轻而易举地独立出来,它们往往都会和宿主有交互,在这种情况下,DroidPlugin就有点力不从心了。

基于上述几点,我们只能重新造一个轮子,它不但功能全面、兼容性好,还必须能够适用于有耦合的业务插件,这就是VirtualAPK存在的意义。

在加载耦合插件方面,VirtualAPK是开源方案的首选,推荐大家使用

通俗易懂地说

  1. 如果你是要加载微信、支付宝等第三方APP,那么推荐选择DroidPlugin;
  2. 如果你是要加载一个内部业务模块,并且这个业务模块很难从主工程中解耦,那么VirtualAPK是最好的选择。

抽象地说

  1. 如果你要加载一个插件,并且这个插件无需和宿主有任何耦合,也无需和宿主进行通信,并且你也不想对这个插件重新打包,那么推荐选择DroidPlugin;
  2. 除此之外,在同类的开源中,推荐大家选择VirtualAPK。

VirtualAPK的工作过程

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

如何使用

第一步: 初始化插件引擎

@Override

protected void attachBaseContext(Context base) {

    super.attachBaseContext(base);

    PluginManager.getInstance(base).init();

}

第二步:加载插件

public class PluginManager {

    public void loadPlugin(File apk);

}

当插件入口被调用后,插件的后续逻辑均不需要宿主干预,均走原生的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 plugin

    Intent service = new Intent(this, BookManagerService.class);

    bindService(service, mConnection, Context.BIND_AUTO_CREATE);

    

    // start activity in plugin

    Intent intent = new Intent(this, TCPClientActivity.class);

    startActivity(intent);

}

探究原理

基本原理

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

四大组件的实现原理

  • Activity 采用宿主manifest中占坑的方式来绕过系统校验,然后再加载真正的activity;
  • Service 动态代理AMS,拦截service相关的请求,将其中转给Service Runtime去处理,Service Runtime会接管系统的所有操作;
  • Receiver 将插件中静态注册的receiver重新注册一遍;
  • ContentProvider 动态代理IContentProvider,拦截provider相关的请求,将其中转给Provider Runtime去处理,Provider Runtime会接管系统的所有操作。

如下是VirtualAPK的整体架构图,更详细的内容请大家阅读源码和wiki。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT