滴滴插件化項目VirtualAPK開源！

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

我們在 2016 年開始研究這方面的技術，經過半年的開發、測試、適配和線上驗證，目前推出了一款比較完善的插件化框架：VirtualAPK。

之所以現在推出來，是因為 VirtualAPK 在我們內部已經得到了很好的驗證，我們在迭代過程中不斷地做機型適配和細節特性的支持，目前已經達到一個非常穩定的狀況，足以支撐滴滴部分乃至全部業務的動態發版需求。目前 VirtualAPK 應用於滴滴乘客端和優步 APP 中，大家可以去體驗。

為了更好地體現出 VirtualAPK 的價值，我們決定將其開源，請猛擊

。

VirtualAPK 也是滴滴公司的首個對外開源項目，歡迎大家 star、發送 pull request，也歡迎大家來使用 VirtualAPK，我們會給予一定的技術支持。

在傳統的 APP 發布過程中，總是存在著固定的發版節奏，比如兩周或者一個月更新一次，這固然沒有問題。但考慮一種情況，如果一個版本剛發布出去，卻發現存在大量 crash，這個時候我們會怎麼辦？大多數公司都會選擇立刻發一個緊急版本，然後一批人需要手忙腳亂甚至加班來準備這個版本，所以緊急版本還是越少越好。

其實不僅僅是因為致命 crash 而緊急發版，比如一個早期創業公司，需要通過迅速的「試錯」來嘗試找准市場的方向，這個時候就需要更加緊湊的發版方式，有些時候甚至想一天發一次版。在正常的發版流程中，這顯然是不現實的。但是如果這家創業公司必須要隨時可以發版，否則就可能被競爭對手搶佔先機，這個時候該怎麼辦呢？

上述的這兩個問題，通過 VirtualAPK，將不再是問題。通過 VirtualAPK 將業務模塊插件化，然後就可以隨時通過更新插件的方式來發布新功能，不管是修復致命 crash 還是進行業務「試錯」，都是一種很爽快的體驗。

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 和主流的插件化框架之間的對比。

已經有那麼多優秀的開源的插件化框架，滴滴為什麼要重新造一個輪子呢？

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

• 兼容性問題嚴重，大部分開源方案不夠健壯 由於國內 Rom 嘗試深度定製 Android 系統，這導致插件框架的兼容性問題特別多，而目前已有的開源方案中，除了 DroidPlugin，其他方案對兼容性問題的適配程度是不足的。

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

DroidPlugin 側重於載入第三方獨立插件，比如微信，並且插件不能訪問宿主的代碼和資源。而在滴滴打車中，其他業務模塊均需要宿主提供的訂單、定位、賬號等數據，因此插件不可能和宿主沒有交互。

其實在大部分產品中，一個業務模塊實際上並不能輕而易舉地獨立出來，它們往往都會和宿主有交互，在這種情況下，DroidPlugin 就有點力不從心了。

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

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

通俗易懂地說——

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

• 如果你是要載入一個內部業務模塊，並且這個業務模塊很難從主工程中解耦，那麼 VirtualAPK 是最好的選擇。

抽象地說——

• 如果你要載入一個插件，並且這個插件無需和宿主有任何耦合，也無需和宿主進行通信，並且你也不想對這個插件重新打包，那麼推薦選擇 DroidPlugin；

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

VirtualAPK 對插件沒有額外的約束，原生的 apk 即可作為插件。插件工程編譯生成 apk 后，即可通過宿主 App 載入，每個插件 apk 被載入后，都會在宿主中創建一個單獨的 LoadedPlugin 對象。如下圖所示，通過這些 LoadedPlugin 對象，VirtualAPK 就可以管理插件並賦予插件新的意義，使其可以像手機中安裝過的 App 一樣運行。

第一步： 初始化插件引擎

第二步：載入插件

當插件入口被調用后，插件的後續邏輯均不需要宿主幹預，均走原生的 Android 流程。 比如，在插件內部，如下代碼將正確執行：

• Activity 採用宿主 manifest 中占坑的方式來繞過系統校驗，然後再載入真正的 activity；

• Service 動態代理 AMS，攔截 service 相關的請求，將其中轉給 Service Runtime 去處理，Service Runtime 會接管系統的所有操作；

• Receiver 將插件中靜態註冊的 receiver 重新註冊一遍；

• ContentProvider 動態代理 IContentProvider，攔截 provider 相關的請求，將其中轉給 Provider Runtime 去處理，Provider Runtime 會接管系統的所有操作。

如下是 VirtualAPK 的整體架構圖，更詳細的內容請大家閱讀源碼和 wiki。