摘要： 支付寶作為國民級應用，當前全球使用者已經超過 10 億，提供了超過 200 項以上的服務，而崩潰率始終維持在萬分之五以下，而且每天支付寶都上線新的功能和改進。做到今天這樣的成績，並不容易，是經過長時間的實踐經驗積累下來的。
導語
本文基於重嶽在 2018 年 Arch Summit 北京站的分享內容進行總結，希望通過本篇文章介紹近些年來支付寶在移動端架構的上演進和思考，期冀能給讀者們帶來些許幫助。
支付寶作為國民級應用，當前全球使用者已經超過 10 億，提供了超過 200 項以上的服務，而崩潰率始終維持在萬分之五以下，而且每天支付寶都上線新的功能和改進。做到今天這樣的成績，並不容易，是經過長時間的實踐經驗積累下來的。
支付寶的架構演進主要經歷了三個階段，如果用比喻的話，可以分為獨木舟、戰列艦和航空母艦三個階段。
獨木舟時代
支付寶剛推出移動端時，它的結構非常之簡單，除了一些工具元件被劃分為模組，業務程式碼都是糅合在一起。剛開始並沒有太大問題，但是當我們的研發人員迅速增長時，問題開始變得棘手起來，僅僅舉幾個例子便可見一斑。
- 研發同學晚上提交的可以執行的程式碼，到第二天早上來更新一下就完全不能用，原因是其他不相干團隊提交程式碼覆蓋或者汙染了自己的程式碼。
- 臨近釋出點的時候，通常是最忙的，但不是忙著趕功能，而是忙著解決合併程式碼產生的各種問題，不僅浪費時間，還耽誤測試同學的寶貴時間。
- 即使最後勉強釋出了，穩定性和效能也是非常糟糕的，因為各個模組只管自己的，沒有統一的規範，也缺乏統一的監控。
- 最令 Android 開發頭痛的是 65535 的問題，彼時 Google 還沒有推出 multi-dex 的方案。
這些嚴重的問題讓我們的產品研發迭代變得無法持續下去，因此我們決定來一次徹底的重構，於是步入了戰列艦時代。
戰列艦時代
當設計新一代的客戶端架構時，我們從三個方向進行思考：團隊協作、研發效率、效能與穩定。
團隊協作方面，我們希望整個架構分層合理，基礎層面，將通用能力下沉，為更多的上層業務服務，避免重複創造輪子；業務層面，各個業務團隊能夠獨立開發管理，不會對不相關的業務造成影響。基於這個初衷，我們形成了下圖這樣的架構：
整個客戶端架構總共分成四層：業務層、服務層、元件層、框架層。
- 業務層：只需專注於業務邏輯與介面的實現，當需要呼叫如支付這樣的通用能力時，研發同學直接使用下層提供的服務能力，不需自己開發，如此能夠保證核心能力有收口，方便監控。
- 服務層：常用模組，如登入、支付、營銷等，它們不僅自己是業務，也向其他業務提供自己的服務，我們將此類模組歸類到服務層。
- 元件層：這一層提供的是客戶端通用能力，如安全、網路、多媒體、儲存這些，它們提供穩定的介面給上層使用者，同時不斷優化自身內部的效能和穩定性，作為客戶端的基石，它們至關重要。
- 框架層：最為關鍵的部分，包括容器、微應用、服務框架以及 Pipeline，客戶端的微應用化、啟動管理都依賴框架層的運作。
我們將服務層、元件層和框架層合稱為 mPaaS，即移動端上的 PaaS 服務。這些 PaaS 服務可以複用，我們不僅在支付寶裡使用它們，也在其他集團應用，如螞蟻財富、網商銀行等中使用。
業務分治
要實現業務分治，最好的方式就在程式碼上能夠進行隔離，大家不必在同一個 Codebase 中開發，避免程式碼合併衝突的現象，這個通常在 Android 上通常可以 aar 的方式來實現，但是可惜的是我們重構的時候 aar 還沒出來，而且即使有 aar，也存在打包時間隨程式碼體積增大線性增長的問題。
我們的解決方案借鑑 OSGi 的概念，將整個客戶端以 Bundle 為單位劃分，每個 Bundle 可以包含自己的程式碼、頁面和資源。讀者可能會想，這究竟和 aar 有什麼分別呢？其實區別很大！
首先，Bundle 裡的程式碼部分是已編譯的 dex，當編譯 apk 時，我們只需要合併 dex 即可，不需要像 aar 那樣將 class 編譯成 dex 再進行合併，這樣大大節省了打包時間；其次，Bundle 是可以獨立執行於自己的 ClassLoader 中的，並且我們可以通過殼代理的方式載入 Activity 等基礎元件，使得動態下發業務成為可能；最後，Bundle 裡還包含微應用、服務和 Pipeline 相關的配置資訊，框架會根據這些資訊啟動相應的元件。
mPaaS 的服務，即 Service 類似於 Spring 框架中的 Service，它對外提供介面服務，而使用者不需要知道如何初始化服務的例項以及生命週期管理，這些完全由框架來託管。使用者只需要知道目標服務介面類的方法引數即可，呼叫時通過框架提供的 API 來獲取例項。
對於服務的釋出者來說，他在自己的 bundle 中宣告介面類以及實現介面類派生的例項類，並註冊相關資訊到 bundle 的 manifest 檔案中。這種做法的本質思想是 Inversion of Control，減少類之間的複雜依賴，避免繁瑣的初始化工作。以依賴介面的方式進行開發，能夠解除服務使用者對服務提供者的依賴，在服務提供者尚未完全開發完成時，使用者可以完全以 mock 的方式來模擬服務，而不需要修改自己的業務程式碼，當然，前提是雙方協商好服務介面的協議。
支付寶中的頁面非常多，直接啟動 Activity 或者 ViewController 對我們來說遠遠不夠，我們選擇在它們上面增加 MicroApp，即微應用的概念。微應用具備唯一的應用 ID，在框架中標識自己的存在。微應用具有統一的入口，根據使用方傳入的字典引數來管理 Activity 或 ViewController。這樣能夠帶來很多好處：
- 只要應用 ID 和引數協議不變，使用方不需擔心目標應用內部重構帶來的影響，直接使用 Activity 或者 ViewController 類名造成的引用氾濫的問題不復存在。
- 微應用的 ID 和字典引數特性，很容易生成 URL，從而實現外部應用使用 URL 跳轉應用內頁面。
- 從資料的角度，我們可以按業務維度來統計使用者行為資料。
- 微應用的概念不僅適用於原生頁面，同樣也適用於 H5 和小程式。註冊為 H5 或者小程式型別的應用 ID，框架會自動將啟動過程 delegate 給 H5 或者小程式容器，而使用者完全不必關心應用 ID 對應的應用型別。
綜上所述，微應用化和服務介面所賦予的特性極大提高團隊間協作效率，各研發小組之間的依賴更加簡單，可以各行其道，更關注於自身服務的打造建設。
效能優化
我們一方面在架構上作出重大改變來提高研發效率，另一方面也在不斷的進行效能優化，改善使用者體驗。我們主要從三個層面來著手：
框架層面
- 制定統一開發規範，業務方使用統一的執行緒池、儲存、網路等元件，並按需進行載入，避免不必要的啟動和耗時操作。
- 引入 Pipeline 機制，業務模組如需在應用啟動時進行初始化工作，必須使用 Pipeline。框架依據業務優先順序確定業務初始化實際。
- 利用 AOP 切面，對常用路徑進行耗時統計，追蹤效能瓶頸。
基礎指標
對於常用指標，如閃退、ANR、記憶體、儲存、電量、流量等，進行長期追蹤。我們能夠明確獲悉每個版本之間這些指標上的差異，並進行取樣分析，定位並解決問題。
向下突破
我們不僅僅在應用層面進行優化，同時也向下探索效能提升的可能性。在這方面，我們也收穫頗豐，比如在 Android 上某些系統版本，通過在啟動階段禁用 GC 的方式獲得 20%~30% 的啟動時間縮減；在 iOS 上，利用系統本身的 Background Fetch 機制提高程式活躍時間，實現應用秒起。
航母時代
隨著移動支付的不斷普及，面對海量的使用者和業務需求，高可用、彈性動態成為支付寶客戶端更為艱鉅的挑戰。支付寶作為集支付、金融、生活為一體的服務平臺，需要能夠快速穩定的釋出服務和引入第三方服務，同時對於使用者的反饋和訴求必須能夠積極迅速的響應。
動態研發模式
我們在研發模式上作出改變以業務快速迭代的要求，業務逐步由原生頁面向 Web 混合頁面遷移。原有的研發模式能夠很好的滿足團隊協作的要求，但是隨著業務規模的不斷增大，程式碼量相應膨脹導致安裝包太大，在iOS上一度超過程式碼段上限，無法通過 AppStore 稽核，另外基於集中時間點的迭代釋出，通常是一個月釋出一個版本，遠不能滿足業務的更新速度要求。相較於原生應用開發，Web應用的優勢非常明顯：
- 只需要一套程式碼，Web 應用可以在 iOS 和 Android 客戶端中執行，能夠相對減少人員的投入。
- 每個使用者日常使用的功能僅僅是支付寶龐大平臺中的一小部分，H5 應用可以做到動態下發，因此可以消除冗餘的儲存，降低包大小。
- 近些年來 React Native，Weex 等動態渲染引擎在社群非常活躍，但經過小範圍的應用以及考慮到 Web 技術的不斷髮展以及其在業界公認的地位，我們最終還是選擇 Web 技術作為動態研發模式的基礎。
- Web 應用迭代擺脫了客戶端集中時間點發布的束縛，各業務線迭代計劃變得自主可控。
打磨 Web 體驗
儘管 Web 應用優勢明顯，但在移動端上的短板也是顯而易見的，它提供的使用者體驗、效能以及能力上的限制與原生應用有相當大的差距。為了彌補這些差距，我們做了大量的改進，主要在以下幾個方面：
- 前後端分離，我們將頁面資源離線化，這樣節省了資源請求消耗的時間，使得頁面開啟速度提升明顯，解決了在網路環境較差下容易出現白屏的問題。同時，資料請求使用 native 網路通道，可優化的空間更大，安全性更高。
- 差量更新，客戶端更新某業務應用版本時，不需下載完整的新版本資源包，而是下載由釋出平臺根據客戶端本地安裝版本計算生成的體積更小的差量包，這樣不僅能夠節省頻寬和流量，也提升了業務更新的速度。
- 推拉結合，解決業務最新版本覆蓋率的問題，每次釋出新版本時，業務可主動觸發訊息到客戶端，客戶端收到通知後會更新該業務應用版本。同時，客戶端會定時去檢查服務端是否有版本釋出，這樣能夠保證版本釋出後大多數使用者在短時間內獲得最新的應用。
- 容錯補償，客戶端可能由於網路、安全或者儲存許可權等原因，不能使用或者及時獲得離線包，這種情況我們也考慮進來了。我們在釋出離線資源時，釋出平臺會自動生成對應的線上 URL 並配置到應用資訊中，當客戶端載入 Web 應用時發現離線包不可用，會立刻啟用該url載入內容，能夠最大程度保證業務可用性。
- Android 獨立瀏覽器核心，Android 碎片化的問題自其誕生之初業已存在，而且目前看上去沒有得以解決的跡象。不同系統、不同廠商中的瀏覽器核心同樣存在差異，這導致層出不窮的相容性問題令研發同學頭疼不已，這也違背 Web 一統天下的願景。為了徹底解決並掌控這些問題，我們引入了獨立的 UC 瀏覽器核心並整合在應用中，這樣所有的問題都集中到UC團隊解決，變得非常可控，根據資料統計，使用 UC 瀏覽器核心後瀏覽器相關的閃退和 ANR 有明顯的下降。同時，安全上出現的漏洞，我們可以在第一時間修復併發布，遠比廠商升級更有效率。
- Web 應用全方位監控，資源載入異常、JS執行異常、白屏、載入耗時等效能資料會被收集上報至後臺，可以及時發現異常。
小程式
我們不僅自身提供各種各樣的服務，也需要引入第三方服務來服務更多的人群，以往我們只能引入簡單的第三方 H5 頁面，它們只能使用支付寶提供的少量功能，而且開發人員能力的差異導致使用者體驗不是很理想。小程式將支付寶的能力全面開放出來，從開發到測試皆有完整的 IDE 等工具鏈支援，同時 DSL 簡單易用，對於第三方來說，能夠快速開發上線一款體驗和功能比以往更強大的小程式。
本文作者：josephjin
本文為雲棲社群原創內容，未經允許不得轉載。