VirtualAPK：滴滴 Android 插件化的實踐之路

一、前言

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

滴滴出行在插件化上的探索起步較晚，由於業務發展較快，迭代佔據了大量的時間，這使得我們在2016年纔開始研究這方面的技術。經過半年的開發、測試、適配和線上驗證，今天，我們正式推出一款較爲完善的插件化框架——VirtualAPK。之所以現在推出，是因爲 VirtualAPK 在內部已經得到了很好的驗證，我們在迭代過程中不斷地做機型適配和細節特性的支持，目前已達到一個非常穩定的狀況，足以支撐滴滴部分乃至全部業務的動態發版需求。目前滴滴出行最新版本（v5.0.4）上，小巴和接送機業務均爲插件，大家可以去體驗。

二、插件化的現狀

到目前爲止，業界已經有很多優秀的開源項目，比如早期的基於靜態代理思想的 DynamicLoadApk，隨後的基於佔坑思想的 DynamicApk、Small，還有360手機助手的 DroidPlugin。它們都是優秀的開源項目，很大程度上促進了國內插件化技術的發展。

儘管有如此多的優秀框架存在，但是兼容性問題仍然是制約插件化發展的一大難題。一款插件化框架，也許可以在一款手機上完美運行，但是在數以千萬的設備上卻總是容易存在這樣那樣的兼容性問題。我相信上線過插件化的工程師應該深有體會。滴滴爲什麼還要自研一款新的插件化框架？因爲我們需要一款功能完備、兼容性優秀、適用於滴滴業務的插件化框架，目前市面上的開源不能滿足我們的需求，所以必須重新造輪子，於是 VirtualAPK 誕生了。

三、VirtualAPK 的誕生

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

1. 功能完備

• 支持幾乎所有的 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。

2. 優秀的兼容性

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

3. 入侵性極低

• 插件開發等同於原生開發，四大組件無需繼承特定的基類；
• 精簡的插件包，插件可以依賴宿主中的代碼和資源，也可以不依賴；
• 插件的構建過程簡單，通過Gradle插件來完成插件的構建，整個過程對開發者透明。

四、VirtualAPK 的工作過程

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

1. VirtualAPK 的運行形態

我們計劃賦予 VirtualAPK 兩種工作形態，耦合形態和獨立形態。目前 VirtualAPK 對耦合形態已經有了很好的支持，接下來將計劃支持獨立形態。

• 耦合形態：插件對宿主可以有代碼或者資源的依賴，也可以沒有依賴。這種模式下，插件中的類不能和宿主重複，資源 id 也不能和宿主衝突。這是 VirtualAPK 的默認形態，也是適用於大多數業務的形態。
• 獨立形態：插件對宿主沒有代碼或者資源的依賴。這種模式下，插件和宿主沒有任何關係，所以插件中的類和資源均可以和宿主重複。這種形態的主要作用是用於運行一些第三方 apk。

2. 如何使用

第一步： 初始化插件引擎

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

第二步：加載插件

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

我們對上述加載過程進行了一些封裝，通過如下方式即可異步地去加載一個插件。

// 示例：啓動插件中的Activity
DownloadManager downloadManager = DownloadManager.getInstance(this);
downloadManager.loadModule("com.ryg.test", true, this, new ILoadListener() {
    @Override
    public void onLoadEnd(int resultCode) {
        if (resultCode == ILoadListener.LOAD_SUCCESS) {
            Intent intent = new Intent();
            intent.setClassName("com.ryg.test", "com.ryg.test.MainActivity");
            startActivity(intent);
        } else {
            // todo load plugin failed
        }
    }
});

當插件入口被調用後，插件的後續邏輯均不需要宿主幹預，均走原生的 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);
}

五、探究原理

1. 基本原理

• 合併宿主和插件的ClassLoader：需要注意的是，插件中的類不可以和宿主重複；
• 合併插件和宿主的資源：重設插件資源的packageId，將插件資源和宿主資源合併；
• 去除插件包對宿主的引用：構建時通過 Gradle 插件去除插件對宿主的代碼以及資源的引用。

2. 四大組件的實現原理

• Activity：採用宿主 manifest 中佔坑的方式來繞過系統校驗，然後再加載真正的 Activity；
• Service：動態代理 AMS，攔截 Service 相關的請求，將其中轉給一個虛擬空間（Matrix）去處理，Matrix 會接管系統的所有操作；
• Receiver：將插件中靜態註冊的 Receiver 重新註冊一遍；
• ContentProvider：動態代理 IContentProvider，攔截 Provider 相關的請求，將其中轉給一個虛擬空間（Matrix）去處理，Matrix 會接管系統的所有操作。

以下是 VirtualAPK 的整體結構圖。

六、填坑之路

在實踐中我們遇到了很多很多的問題，比如機型適配、API 版本適配、Binder Hook 的穩定性保證等問題，這裏拿一個典型的資源適配問題來說明。

其實這是一個很無奈的問題，由於國內各大 ROM 廠商喜歡深度定製 Android 系統，所以就出現了這種適配問題。

正常情況下我們通過如下代碼去創建插件的 Resources 對象：

Resources newResources = new Resources(assetManager,
 hostResources.getDisplayMetrics(), hostResources.getConfiguration());

然後在 Vivo 手機上，竟然出現瞭如下的類型轉換錯誤，看起來是 Vivo 自己派生了 Resources 的子類。

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.sdu.didi.psnger/com.didi.virtualapk.core.A$1}: java.lang.ClassCastException: android.content.res.Resources cannot be cast to android.content.res.VivoResources
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2196)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245)
    at android.app.ActivityThread.access$800(ActivityThread.java:140)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1202)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loop(Looper.java:136)
    at android.app.ActivityThread.main(ActivityThread.java:5143)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:515)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:602)
    at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassCastException: android.content.res.Resources cannot be cast to android.content.res.VivoResources
    at android.app.ResourcesManager.getTopLevelResources(ResourcesManager.java:236)
    at android.app.ContextImpl.<init>(ContextImpl.java:2057)
    at android.app.ContextImpl.createActivityContext(ContextImpl.java:2008)
    at android.app.ActivityThread.createBaseContextForActivity(ActivityThread.java:2207)
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2140)
    ... 11 more

於是反編譯了下 Vivo 的 Framework 代碼，果不其然，在如下代碼中進行了類型轉換，所以在加載插件資源的時候就報錯了。

@VivoHook(hookType = VivoHookType.NEW_METHOD)
    public Resources getTopLevelResources(String pkgName, String resDir, int displayId, Configuration overrideConfiguration, CompatibilityInfo compatInfo, IBinder token) {
        Resources resources = getTopLevelResources(resDir, displayId, overrideConfiguration, compatInfo, token);
        if (resources != null) {
            ((VivoResources) resources).init(pkgName);
        }
        return resources;
    }

爲了解決這個問題，我們分析了 VivoResources 的代碼實現，然後在創建插件資源的時候，採用瞭如下的代碼。

private static final class VivoResourcesCompat {
    private static Resources createResources(Resources hostResources, AssetManager assetManager) throws Exception {
        Class resourcesClazz = Class.forName("android.content.res.VivoResources");
        Resources newResources = (Resources)ReflectUtil.invokeConstructor(resourcesClazz,
                new Class[]{AssetManager.class, DisplayMetrics.class, Configuration.class},
                new Object[]{assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration()});
        return newResources;
    }
}

除了 Vivo 以外，有類似問題的還有 MIUI、Nubia 以及其他不知名的機型。而且在 Vivo 手機上，除了類型轉換錯誤的問題，還有其他很坑的問題。

事實上我們還處理了很多其他的坑，這裏無法一一說明，所以說如何保證插件化的穩定性是一件很有技術挑戰的事情。

七、一些暫時不支持的特性

由於種種原因，VirtualAPK 目前未能支持所有的 Android 的特性，已知的有如下幾點：

• 不支持 Activity 的部分屬性，比如 process、configChanges 等；
• 暫不支持 overridePendingTransition(int enterAnim, int exitAnim) 這種形式的轉場動畫；
• 插件中彈通知，不能使用插件中的資源，比如圖片。

八、開源計劃

我們的目標是打造一款功能完備的插件化框架，使得各個業務線都能以插件的形式集成，從而實現 Android App 的熱更新能力。

目前 VirtualAPK 還有一些特性需要進一步完善，待完善後，將會進行開源計劃。我們期望 VirtualAPK 開源後，可以讓其他 App 能夠無縫集成，無需考慮細節實現和兼容性問題即可輕鬆擁有熱更新能力。

轉載用於交流,如冒犯,請聯繫刪除。

原文