摘要： 本文將介紹支付寶 Android 容器化框架設計的基本思路。

1. 前言

由本章節開始，我們將從支付寶客戶端的架構設計方案入手，細分拆解客戶端在“容器化框架設計”、“網路優化”、“效能啟動優化”、“自動化日誌收集”、“RPC 元件設計”、“移動應用監控、診斷、定位”等具體實現，帶領大家進一步瞭解支付寶在客戶端架構上的迭代與優化歷程。

本節將介紹支付寶 Android 容器化框架設計的基本思路。

1.1 開發背景

隨著 Android 應用程式所能實現的功能越來越強大和複雜，隨之而來的是：

• Android 程式的的程式碼和資源越來越多，APK 檔案的 size 越來越大，Android 程式也越來越複雜；
• 隨著應用的迭代、專案的擴張，團隊數量以及團隊人數的同時增多，基於傳統架構模式的並行開發也變得愈加困難。

此外，移動客戶端通常需要面對動態化開發的挑戰；Bug 緊急修復等運維需求；同時也有一些線上運營的需求，如動態下發廣告，推送接入活動等。如果每次有運維、運營需求，都需要一次客戶端發版，那將是傳統的開發人員的夢魘。

Android 開發者們深切體會到一個穩健可靠、可擴充套件的、支援大規模並行開發的客戶端開發框架對於平臺級別的客戶端 App 的重要性。事實上，客戶端框架設計的健壯性和擴充套件性，在面對上述需求和解決困難上，往往能達到事半功倍的效果，尤其是 Android 客戶端開發人員將深受其利。

那麼，作為平臺級別的 Android 客戶端 App 究竟該如何的進行框架設計，才能滿足千變萬化的移動網際網路時代的困難和需求？

1.2 平臺級客戶端框架面臨的問題

我們可以歸納為：平臺級客戶端框架必須要解決的是模組化和 動態化這兩大核心問題。

（本篇文章我們著重關注模組化相關內容，後續我們通過其他文章分析 動態化的能力。）

1.3 框架設計原則

為了解決上述模組化的問題，我們要遵循以下原則去設計客戶端框架：

• 根據基礎技術層級、客戶端的業務線等原則，對客戶端應用程式進行模組化拆分。
• 每一個模組由獨立的小團隊或者個人來進行開發、維護、測試、整合。
• 模組與模組之間要做到徹底解耦，模組之間可以通過介面進行依賴。
• 每一個模組可以進行熱插拔，單個模組的插拔不影響整體的工程的編譯執行。

2. Quinox 簡介

Quinox 客戶端框架是類 OSGi（ like-as）框架的實現。Quinox 一詞來源於著名的 OSGi 框架的實現 Equinox。

基於此框架的客戶端 App，都是由一個個的積木搭建而成，這些積木被稱之為：Bundle。

3. Bundle 介紹

3.1 什麼是 Bundle

Bundle 是 OSGi 規範的模組化基本單位，與 Android 裡的 android.os.Bundle 是兩個完全不同的概念。
OSGi 裡的 Bundle 指的是 Java 應用程式的基本單位，它是一個模組單元（Jar 格式），也是上文 Quinox 簡介裡提到的積木。
基於 Quinox 容器框架開發的應用程式也是由眾多的 Bundle（APK 格式）構成。

本章節將從專案開發的三個不同的時期對 Bundle 的形態進行闡述：

3.2 Bundle 工程

常規的 Android 專案開發，程式碼工程通常有兩種(兩級)型別

基於 Quinox 容器框架開發的 Android 專案，程式碼工程則有三種(三級)型別

關於 Bundle 工程，我們需要了解以下三點：

• Bundle 工程跟常規的 Android Application 工程非常的類似：它內部也會有多個 Library（Android Module）；它的輸出形式也是 APK 格式。
• 雖然 Bundle 包檔案本質上是 APK 格式，但是該 APK 是無法執行的。同時，Bundle 工程被 deploy 到 mvn 倉庫裡時，它的字尾名是會改為.jar。
• 基於 Quinox 容器的 Application 工程（可稱之為 Portal 工程）則是將眾多 Bundle（APK）合併成一個 APK（Final）的過程。這裡是合併，而不是編譯，所以生成最終 APK 的速度將會非常快，因為編譯已經被分散式的進行在各個 Bundle 中了。基於 Quinox 容器開發的客戶端程式，需使用 mPaaS 定製的構建工具（即打包外掛）。

關於 Bundle 工程的結構圖請參考：

3.3 Bundle 包

如上所述，Bundle 工程的輸出也是 APK 檔案。

在 OSGi 規範中，Bundle 是有很多屬性的。Bundle 工程輸出的 APK 與常規的 APK 有一個不同點，mPaaS 外掛會將 Bundle 的所有屬性生成一個特殊的檔案放在這個 APK 中，供容器去解讀。

除了 APK 檔案之外，Bundle 工程的構建結果還包含：

• AndroidMannifest.xml
• Bundle 介面包（可以理解為一個 jar 包，它包含且暴露該 Bundle 提供的介面類）
• mapping.txt

Bundle 包檔案，在構建完成之後，通常要 deploy 到本地/遠端的 mvn 倉庫中，以供其他 Bundle 工程引用，或是被 Portal 工程整合。

3.4 Bundle 基線

前面已經講述過，構建 Final APK 其實主要就是將很多的 Budnle APK 合併成最終的 APK 的過程，而這些眾多的 Bundle APK 們都存放於 mvn 倉庫中。

因此我們將這些 Bundle 的 GAV（GroupId，ArtifactId，Vesion）的集合，稱之為基線。

當某一個團隊/個人開完一個 Bundle 工程的新功能，並經過測試達到可釋出狀態，就可以更新基線裡的版本號。我們將這個過程稱之為進基線。我們認為：基線裡打出來的 APK 是穩定可執行的；沒有穩定 Bundle 工程包不應該進基線。

Bundle 基線機制可以很好的隔離了模組之間的相互影響，保障了不同團隊間開發環境的和諧與穩定，達到了我們之前的設計的初衷，因此可以很好的支援多團隊並行開發。

3.5 Bundle 包屬性及配置辦法

關於 Bundle 屬性，我們可以參考 OSGi 的 Bundle 屬性。Quinox 容器框下定義的 Bundle 屬性要簡單的多。

下表將列舉 Bundle 的所有屬性以及配置方法：

4. 資源管理

4.1 資源管理器

作為 Android 開發人員，我們知道通過 android.content.res.Resources 物件可以獲取字串、佈局、圖片、動畫等資源。

在 Quinox 容器化的框架內，原生的資源管理肯定無法實現多 Bundle 的資源管理，這時候，我們就構建了 Bundle 資源管理器，來專門處理各個 Bundle 的資源的載入、呼叫等工作，替代了 Android 原生的資源管理邏輯。

但是，由於所有 Bundle 包都是獨立編譯的，它們中的資源極可能存在著相同的資源 id。因此，當存在相同資源時，就可能存在衝突，那麼如何解決資源 id 的衝突呢？

4.2 資源 id

作為 Android 程式設計師，我們都知道資源 id 是一個 int 值，它包含4個 byte。它是在構建 APK 工程時，由 aapt 工具生成，定義在 R 檔案中。

示例程式碼：

public final class R {
    public static final class drawable {
        public static int xxx_bg=0x1e020000;
    }
    public static final class id {
        public static int xxx_id=0x1e050001;
    }
    public static final class layout {
        public static int xxx_layout=0x1e030000;
    }
    public static final class string {
        public static int xxx_str=0x1e040001;
    }
}

這四個 byte 含義如下：

• 第一個位元組為：pacakgeId。
• 第二個位元組為：typeId。它表示的是不同的資源型別，如字串，佈局，圖片，動畫等。
• 第三第四兩個位元組合起來為：資源名稱的 id

如下圖所示：

到這裡，很多讀者應該已經理解到了，Quinox 容器框架關於資源 id 衝突的解決方案是，讓 mPaaS 打包外掛使用改造過 aapt 工具，對每一個 Bundle 工程都指定不同 packageId，進行分割槽隔離，從而確保不同的 Bundle 之間資源 id 是不會重複的。這也是為什麼 Bundle 工程裡需要指定 packageId 的緣故。

5.容器化

關於 Quinox 容器化這裡，由於目前為止，Quinox 暫未開源，所以本章節內，我們暫時不涉及到原始碼分析。

上面我們聊了很多關於 Bundle 的話題，那麼整個容器化的核心，也是如何管理各個 Bundle。這時就要引出我們的容器管理器了，容器管理器的主要工作就是協調各個 Bundle，對各種資訊進行增刪改查。

在應用啟動後，我們的容器管理器會讀取配置資訊，生成各 Bundle 的資訊例項。

5.1 容器管理器：增、刪

Quinox 容器框架的目標是解決 Android 客戶端 App 模組化和動態化這兩大核心問題。增、刪這兩項能力，更多的是用來實現動態化能力的，方便容器對各個 Bundle 進行動態新增、刪除。由於本文著重描寫模組化的能力，所以這部分，我們後續單開專題來分析容器的動態化能力。

5.2 容器管理器：改

關於容器管理器的改的能力，Quinox 主要是利用改的能力，做一些啟動效能的優化，以及機型適配上的工作，這裡涉及原始碼較多，我們不做過多分析。

5.3 容器管理器：查

容器管理器使用最頻繁的功能介面應該是查詢介面：

• 根據 BundleName 進行查詢（還記得 Bundle 的 Require-Bundle 屬性麼？）
• 根據 packageId 進行查詢（非27的 Bundle）
• 根據 Android Component 類名進行查詢（還記得 Bundle 的 Component-Name 屬性麼？）

通過管理器的查詢介面，我們進行各個 Bundle 之間的協調、通訊，完成容器化的功能。

5.4 元件的啟動

除了容器管理器，還有一個重要的點就是元件的啟動器。Quinox 容器定製類原生 Android Activity 的啟動流程，從而自主管理 Activity 的建立以及生命週期。

同時，由於 Activity 是我們自主的啟動器進行的建立，我們還可以對 Activity 進行一些定製化的改造，方便其更好的適配容器這套體系。比如說給 Activity 賦予我們自定義的資源管理器，管理 Activity 堆疊並對外提供介面，對 Activity 各生命週期做一些切面工作等等。

定製化的元件啟動器，還有一個好處就是可以做到 Activity 的動態執行。所謂動態執行，是指執行出廠未註冊在 Manifest 中的 Activity。這塊功能，更多是為了支援容器動態化的能力。

由於 Activity 動態執行的實現邏輯涉及較多的核心技術點，所以我們暫時不進行具體實現的剖析。

6. 小結

通過本節內容，我們已經初步瞭解了 mPaaS 在安卓端容器化框架的設計思路和相應模組。由於篇幅限制，很多技術要點我們無法一一展開。

閱讀原文