VirtualAPK是滴滴出行自研的一款優(yōu)秀的插件化框架，主要有如下幾個(gè)特性。

功能完備

• 支持幾乎所有的Android特性；
• 四大組件方面

四大組件均不需要在宿主manifest中預(yù)注冊(cè)，每個(gè)組件都有完整的生命周期。

Activity：支持顯示和隱式調(diào)用，支持Activity的theme和LaunchMode，支持透明主題；

Service：支持顯示和隱式調(diào)用，支持Service的start、stop、bind和unbind，并支持跨進(jìn)程bind插件中的Service；

Receiver：支持靜態(tài)注冊(cè)和動(dòng)態(tài)注冊(cè)的Receiver；

ContentProvider：支持provider的所有操作，包括CRUD和call方法等，支持跨進(jìn)程訪問(wèn)插件中的Provider。

• 自定義View：支持自定義View，支持自定義屬性和style，支持動(dòng)畫(huà)；
• PendingIntent：支持PendingIntent以及和其相關(guān)的Alarm、Notification和AppWidget；
• 支持插件Application以及插件manifest中的meta-data；
• 支持插件中的so。

優(yōu)秀的兼容性

• 兼容市面上幾乎所有的Android手機(jī)，這一點(diǎn)已經(jīng)在滴滴出行客戶端中得到驗(yàn)證；
• 資源方面適配小米、Vivo、Nubia等，對(duì)未知機(jī)型采用自適應(yīng)適配方案；
• 極少的Binder Hook，目前僅僅hook了兩個(gè)Binder：AMS和IContentProvider，hook過(guò)程做了充分的兼容性適配；
• 插件運(yùn)行邏輯和宿主隔離，確保框架的任何問(wèn)題都不會(huì)影響宿主的正常運(yùn)行。

入侵性極低

• 插件開(kāi)發(fā)等同于原生開(kāi)發(fā)，四大組件無(wú)需繼承特定的基類；
• 精簡(jiǎn)的插件包，插件可以依賴宿主中的代碼和資源，也可以不依賴；
• 插件的構(gòu)建過(guò)程簡(jiǎn)單，通過(guò)Gradle插件來(lái)完成插件的構(gòu)建，整個(gè)過(guò)程對(duì)開(kāi)發(fā)者透明。

VirtualAPK和主流開(kāi)源框架的對(duì)比

如下是VirtualAPK和主流的插件化框架之間的對(duì)比。

特性DynamicLoadApkDynamicAPKSmallDroidPluginVirtualAPK

支持四大組件	只支持Activity	只支持Activity	只支持Activity	全支持	全支持
組件無(wú)需在宿主manifest中預(yù)注冊(cè)	√	×	√	√	√
插件可以依賴宿主	√	√	√	×	√
支持PendingIntent	×	×	×	√	√
Android特性支持	大部分	大部分	大部分	幾乎全部	幾乎全部
兼容性適配	一般	一般	中等	高	高
插件構(gòu)建	無(wú)	部署aapt	Gradle插件	無(wú)	Gradle插件

為什么選擇VirtualAPK？

已經(jīng)有那么多優(yōu)秀的開(kāi)源的插件化框架，滴滴為什么要重新造一個(gè)輪子呢？

1. 大部分開(kāi)源框架所支持的功能還不夠全面?除了DroidPlugin，大部分都只支持Activity。

2. 兼容性問(wèn)題嚴(yán)重，大部分開(kāi)源方案不夠健壯?由于國(guó)內(nèi)Rom嘗試深度定制Android系統(tǒng)，這導(dǎo)致插件框架的兼容性問(wèn)題特別多，而目前已有的開(kāi)源方案中，除了DroidPlugin，其他方案對(duì)兼容性問(wèn)題的適配程度是不足的。

3. 已有的開(kāi)源方案不適合滴滴的業(yè)務(wù)場(chǎng)景?雖然說(shuō)DroidPlugin從功能的完整性和兼容性上來(lái)看，是一款非常完善的插件框架，然而它的使用場(chǎng)景和滴滴的業(yè)務(wù)不符。

DroidPlugin側(cè)重于加載第三方獨(dú)立插件，比如微信，并且插件不能訪問(wèn)宿主的代碼和資源。而在滴滴打車中，其他業(yè)務(wù)模塊均需要宿主提供的訂單、定位、賬號(hào)等數(shù)據(jù)，因此插件不可能和宿主沒(méi)有交互。

其實(shí)在大部分產(chǎn)品中，一個(gè)業(yè)務(wù)模塊實(shí)際上并不能輕而易舉地獨(dú)立出來(lái)，它們往往都會(huì)和宿主有交互，在這種情況下，DroidPlugin就有點(diǎn)力不從心了。

基于上述幾點(diǎn)，我們只能重新造一個(gè)輪子，它不但功能全面、兼容性好，還必須能夠適用于有耦合的業(yè)務(wù)插件，這就是VirtualAPK存在的意義。

在加載耦合插件方面，VirtualAPK是開(kāi)源方案的首選，推薦大家使用。

通俗易懂地說(shuō)

如果你是要加載微信、支付寶等第三方APP，那么推薦選擇DroidPlugin；

如果你是要加載一個(gè)內(nèi)部業(yè)務(wù)模塊，并且這個(gè)業(yè)務(wù)模塊很難從主工程中解耦，那么VirtualAPK是最好的選擇。

抽象地說(shuō)

如果你要加載一個(gè)插件，并且這個(gè)插件無(wú)需和宿主有任何耦合，也無(wú)需和宿主進(jìn)行通信，并且你也不想對(duì)這個(gè)插件重新打包，那么推薦選擇DroidPlugin；

除此之外，在同類的開(kāi)源中，推薦大家選擇VirtualAPK。

VirtualAPK的工作過(guò)程

VirtualAPK對(duì)插件沒(méi)有額外的約束，原生的apk即可作為插件。插件工程編譯生成apk后，即可通過(guò)宿主App加載，每個(gè)插件apk被加載后，都會(huì)在宿主中創(chuàng)建一個(gè)單獨(dú)的LoadedPlugin對(duì)象。如下圖所示，通過(guò)這些LoadedPlugin對(duì)象，VirtualAPK就可以管理插件并賦予插件新的意義，使其可以像手機(jī)中安裝過(guò)的App一樣運(yùn)行。?

如何使用

第一步： 初始化插件引擎

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

第二步：加載插件

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

當(dāng)插件入口被調(diào)用后，插件的后續(xù)邏輯均不需要宿主干預(yù)，均走原生的Android流程。?比如，在插件內(nèi)部，如下代碼將正確執(zhí)行：

@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); }

探究原理

基本原理

• 合并宿主和插件的ClassLoader?需要注意的是，插件中的類不可以和宿主重復(fù)
• 合并插件和宿主的資源?重設(shè)插件資源的packageId，將插件資源和宿主資源合并
• 去除插件包對(duì)宿主的引用?構(gòu)建時(shí)通過(guò)Gradle插件去除插件對(duì)宿主的代碼以及資源的引用

四大組件的實(shí)現(xiàn)原理

• Activity?采用宿主manifest中占坑的方式來(lái)繞過(guò)系統(tǒng)校驗(yàn)，然后再加載真正的activity；
• Service?動(dòng)態(tài)代理AMS，攔截service相關(guān)的請(qǐng)求，將其中轉(zhuǎn)給Service Runtime去處理，Service Runtime會(huì)接管系統(tǒng)的所有操作；
• Receiver?將插件中靜態(tài)注冊(cè)的receiver重新注冊(cè)一遍；
• ContentProvider?動(dòng)態(tài)代理IContentProvider，攔截provider相關(guān)的請(qǐng)求，將其中轉(zhuǎn)給Provider Runtime去處理，Provider Runtime會(huì)接管系統(tǒng)的所有操作。

如下是VirtualAPK的整體架構(gòu)圖，更詳細(xì)的內(nèi)容請(qǐng)大家閱讀源碼。

總結(jié)

以上是生活随笔為你收集整理的Android插件框架VirtualAPK的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。