在 Android 插件化技術(shù)日新月異的今天,，開發(fā)并落地一款插件化框架到底是簡單還是困難,，這個(gè)問題不同人會有不同的答案。但是我相信,，完成一個(gè)插件化框架的 demo 并不是多難的事,，但是要開發(fā)一款完善的插件化框架卻不是一件容易的事，尤其在國內(nèi),，各大 Rom 廠商都對 Android 系統(tǒng)做了一定程度的定制,，這進(jìn)一步加劇了 Android 本身的碎片化問題。

我們在 2016 年開始研究這方面的技術(shù),，經(jīng)過半年的開發(fā),、測試、適配和線上驗(yàn)證,，目前推出了一款比較完善的插件化框架：VirtualAPK,。

之所以現(xiàn)在推出來，是因?yàn)?VirtualAPK 在我們內(nèi)部已經(jīng)得到了很好的驗(yàn)證,，我們在迭代過程中不斷地做機(jī)型適配和細(xì)節(jié)特性的支持,，目前已經(jīng)達(dá)到一個(gè)非常穩(wěn)定的狀況，足以支撐滴滴部分乃至全部業(yè)務(wù)的動態(tài)發(fā)版需求,。目前 VirtualAPK 應(yīng)用于滴滴乘客端和優(yōu)步中國 APP 中,，大家可以去體驗(yàn)。

為了更好地體現(xiàn)出 VirtualAPK 的價(jià)值,，我們決定將其開源,，請猛擊

https://github.com/didi/VirtualAPK 。

VirtualAPK 也是滴滴公司的首個(gè)對外開源項(xiàng)目,，歡迎大家 star,、發(fā)送 pull request，也歡迎大家來使用 VirtualAPK,，我們會給予一定的技術(shù)支持,。

在傳統(tǒng)的 APP 發(fā)布過程中,，總是存在著固定的發(fā)版節(jié)奏,，比如兩周或者一個(gè)月更新一次，這固然沒有問題。但考慮一種情況,，如果一個(gè)版本剛發(fā)布出去,，卻發(fā)現(xiàn)存在大量 crash，這個(gè)時(shí)候我們會怎么辦,？大多數(shù)公司都會選擇立刻發(fā)一個(gè)緊急版本,，然后一批人需要手忙腳亂甚至加班來準(zhǔn)備這個(gè)版本，所以緊急版本還是越少越好,。

其實(shí)不僅僅是因?yàn)橹旅?crash 而緊急發(fā)版,，比如一個(gè)早期創(chuàng)業(yè)公司，需要通過迅速的“試錯(cuò)”來嘗試找準(zhǔn)市場的方向,，這個(gè)時(shí)候就需要更加緊湊的發(fā)版方式,，有些時(shí)候甚至想一天發(fā)一次版。在正常的發(fā)版流程中,，這顯然是不現(xiàn)實(shí)的。但是如果這家創(chuàng)業(yè)公司必須要隨時(shí)可以發(fā)版,，否則就可能被競爭對手搶占先機(jī),，這個(gè)時(shí)候該怎么辦呢？

上述的這兩個(gè)問題,，通過 VirtualAPK,，將不再是問題。通過 VirtualAPK 將業(yè)務(wù)模塊插件化,，然后就可以隨時(shí)通過更新插件的方式來發(fā)布新功能,，不管是修復(fù)致命 crash 還是進(jìn)行業(yè)務(wù)“試錯(cuò)”，都是一種很爽快的體驗(yàn),。

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

• 支持幾乎所有的 Android 特性,；

• 四大組件方面

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

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

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

3. Receiver：支持靜態(tài)注冊和動態(tài)注冊的 Receiver；

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

5. 自定義 View：支持自定義 View，支持自定義屬性和 style,，支持動畫,；

6. PendingIntent：支持 PendingIntent 以及和其相關(guān)的 Alarm、Notification 和 AppWidget,；

7. 支持插件 Application 以及插件 manifest 中的 meta-data,；

8. 支持插件中的 so。

• 兼容市面上幾乎所有的 Android 手機(jī),，這一點(diǎn)已經(jīng)在滴滴出行客戶端中得到驗(yàn)證,；

• 資源方面適配小米、Vivo,、Nubia 等,，對未知機(jī)型采用自適應(yīng)適配方案；

• 極少的 Binder Hook,，目前僅僅 hook 了兩個(gè) Binder：AMS 和 IContentProvider,，hook 過程做了充分的兼容性適配；

• 插件運(yùn)行邏輯和宿主隔離,，確?？蚣艿娜魏螁栴}都不會影響宿主的正常運(yùn)行。

• 插件開發(fā)等同于原生開發(fā),，四大組件無需繼承特定的基類,；

• 精簡的插件包，插件可以依賴宿主中的代碼和資源,，也可以不依賴,；

• 插件的構(gòu)建過程簡單，通過 Gradle 插件來完成插件的構(gòu)建,，整個(gè)過程對開發(fā)者透明,。

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

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

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

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

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

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

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

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

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

通俗易懂地說——

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

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

抽象地說——

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

• 除此之外,，在同類的開源中，推薦大家選擇 VirtualAPK,。

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

第一步： 初始化插件引擎

第二步：加載插件

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

• 合并宿主和插件的 ClassLoader 需要注意的是,，插件中的類不可以和宿主重復(fù)

• 合并插件和宿主的資源 重設(shè)插件資源的 packageId，將插件資源和宿主資源合并

• 去除插件包對宿主的引用 構(gòu)建時(shí)通過 Gradle 插件去除插件對宿主的代碼以及資源的引用

• Activity 采用宿主 manifest 中占坑的方式來繞過系統(tǒng)校驗(yàn),，然后再加載真正的 activity,；

• Service 動態(tài)代理 AMS，攔截 service 相關(guān)的請求,，將其中轉(zhuǎn)給 Service Runtime 去處理,，Service Runtime 會接管系統(tǒng)的所有操作；

• Receiver 將插件中靜態(tài)注冊的 receiver 重新注冊一遍,；

• ContentProvider 動態(tài)代理 IContentProvider,，攔截 provider 相關(guān)的請求，將其中轉(zhuǎn)給 Provider Runtime 去處理,，Provider Runtime 會接管系統(tǒng)的所有操作,。

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