写点什么

滴滴插件化项目 VirtualAPK 开源

  • 2017-06-29
  • 本文字数:3244 字

    阅读完需:约 11 分钟

在 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。

2017-06-29 22:495987

评论

发布
暂无评论
发现更多内容

一起学Elasticsearch系列-写入和检索调优

Java随想录

Java 大数据 Elastic Search

Mac电脑视频编辑处理:Apeaksoft Video Editor 激活最新版

mac大玩家j

Mac软件 视频处理工具 视频编辑器 视频编辑管理

Kosmos实战系列:有状态服务(MySQL)跨云灾备实战

畅聊云原生

打破界限:一体化数据驱动低代码平台,构建业务生态新纪元

天津汇柏科技有限公司

低代码

GaussDB(DWS)中的分布式死锁问题实践

华为云开发者联盟

大数据 后端 华为云 华为云开发者联盟 华为云GaussDB(DWS)

数据服务化解耦 创新企业智能运营架构

用友BIP

数据服务

好消息!华为云时习知荣获IXDC AWARD国际体验奖

华为云PaaS服务小智

云计算 华为云

绝地反击,不做背锅侠!

尚思卓越

运维 堡垒机

好用的IOS数据传输工具:FonePaw iOS Transfer中文激活

胖墩儿不胖y

Mac软件 iOS数据传输工具

《网络安全事件报告管理办法(征求意见稿)》正在公开征求意见

行云管家

网络安全 网络安全法

IPQ6018 vs. IPQ8074: A Selection Guide for Wireless Network Processors

wallysSK

网站被ddos跟cc攻击会有什么影响,该如何去解决

德迅云安全_初启

测试开发 | 人工智能无监督学习(Unsupervised Learning)

测吧(北京)科技有限公司

测试

IPQ9574-IPQ8072 has 10G Ethernet port- What is the performance difference?

wifi6-yiyi

ipq9574 10G Ethernet port

带你了解决策树模型

小齐写代码

【坚果派】JS开源库适配OpenHarmony系列——第一期实操

白晓明

OpenHarmony JS开源库 ArkTS开源库

测试开发 | 深入了解监督学习(Supervised Learning)

测吧(北京)科技有限公司

测试

Ampere 年度展望:AI 浪潮改变计算格局,预测 2024 年三大趋势

科技热闻

2024年度腾讯犀牛鸟精英人才计划开放申请

Geek_2d6073

Flink Has Become the De-facto Standard of Streaming Compute

Apache Flink

大数据 flink 实时计算

第33期 | GPTSecurity周报

云起无垠

软件测试/测试开发丨软件测试的基本概念

测试人

软件测试

基于大语言模型LangChain框架:知识库问答系统实践

博文视点Broadview

Vue 2最终版本 v2.7.16 已发布

南城FE

JavaScript Vue 前端开发

Kuasar成为CNCF官方项目,探索容器运行时新纪元

华为云开发者联盟

云原生 后端 华为云 华为云开发者联盟

基于「迭代分支」的 API 开发模式

Apifox

程序员 后端 Apifox 分支 API 开发

移动端防截屏录屏技术在百度账户系统实践

百度Geek说

移动端 企业号12月PK榜 防截屏录屏 百度账户系统

文心一言 VS 讯飞星火 VS chatgpt (165)-- 算法导论13.1 5题

福大大架构师每日一题

福大大架构师每日一题

滴滴插件化项目VirtualAPK开源_移动_滴滴App架构组_InfoQ精选文章