支付寶 App架構的原理與實戰

時間 2020-01-03

原文原文鏈接

本文來源：mPaaS

根據公開的 2018 年移動互聯網行業分析報告，目前支付寶的月活躍用戶已經超過 QQ ，成爲國內第二大 App。前端

支付寶一開始僅僅只是一個單體應用的工具型 App，讓用戶能夠在手機完成支付寶相關的業務查詢和操做。2013 年後，支付寶逐步轉型爲平臺型 App，平臺型 App 具備服務化、模塊化、工具組件化的特色。這個時候支付寶的業務不只僅是支付，還須要給客戶提供不少生活相關的服務，例如餘額寶、繳電費等。2015 年後支付寶成長爲超級 App，此時支付寶裏面須要支持大量複雜的業務，同時開放本身的商業能力，用本身流量助力合做夥伴，所以整個 App 面臨開放、動態化、高可用的挑戰，面對這些挑戰，咱們把它總結爲如下三點：git

如何應對複雜的業務協同？
如何知足業務快速迭代的需求？
如何構建面向將來的開放生態？

利用 Hybrid App 架構，應對複雜的業務協同

App 的業務愈來愈複雜，不只僅是內部業務，還包含了大量外部的合做夥伴。若是採用傳統的 App 開發方式很難應對日趨複雜的業務場景。github

1.1 Hybrid 技術方案選型面試

在 Hybrid 技術方案選型方面，咱們經過「開發成本、用戶體驗、動態性、複雜業務支持能力、研發難度」五個方面綜合考量。咱們篩選出 HTML五、ReactNative/Weex、Flutter 做爲備選，並將原生開發做爲基準線完成對比。（考慮到近期 Flutter 的熱度持續走高，所以咱們歸入 Flutter 一併分析。）算法

首先咱們從業務開發成本角度來看：小程序

原生做爲最基礎的開發模式，須要雙端都進行開發，無疑成本是最高的；
其次是 ReactNative/Weex，即便是一次開發，同時運行在雙端，但因爲是 JS 轉成 Native 組件渲染，實際運行起來仍然存在些許差別，致使開發者在寫業務界面時，部分差別須要經過 Native 端定製開發來解決。總體而言，ReactNative/Weex 已幫助業務方大幅下降開發成本；
接下來是 Flutter，從業務開發的角度來講，Flutter 針對雙端對齊真的下了大功夫。在大多數場景下，Android 端開發完畢以後能無縫跑在 iOS 端，固然這和它自研的引擎有關。只不過 Flutter 需基於 Dart 語言開發，所以對於開發者而言，部分老業務移植的工做量需考慮在內；
最後是 HTML5，帶着成熟的語言，成熟的開發模式，雙端幾乎同樣的表現等特性代表 HTML5 仍然是目前咱們能落地的開發成本最低的方案。

接下來咱們討論用戶體驗：瀏覽器

首先，原生的體驗毋庸置疑是最好的；
其次是自有渲染引擎的 Flutter，不管是性能仍是控件的展示形式，能夠說是不亞於原生的體驗；
接下來即是 ReactNative/Weex 方案，經過將前端代碼渲染成本地 Natvie 控件。在早期版本中，因爲部分控件優化不到位致使 App 卡頓，所以用戶體驗的表現不足；
最後是 HTML5，徹底經過瀏覽器內核進行渲染，藉助預置資源、內核優化等技術，HTML5 能夠作到接近原生的體驗，但整體性能仍有差別。

接着是動態性的支持：安全

在本文第二章節「離線包機制+發佈平臺」，咱們會從快速迭代的角度深度分析動態性在支撐高併發業務場景下的重要性。服務器

首先，動態性最優的就是 HTML5 方案：能夠訪問在線頁面，服務端即時生效，也能夠經過下發資源的方式，進行動態更新；網絡

其次是 ReactNative/Weex 方案，經過必定的定製，開發者能夠將前端包熱部署、熱更新。不過相較於 HTML5 具有的「在線+離線」的動態性，該方案仍然存在必定差距；

接下來是原生，Android/iOS 雙端都可以經過一些黑科技手段，進行動態更新，不過因爲 iOS 政策禁止，所以在動態性上，原生方案暫時不推薦；

最後是 Flutter，雖然有很強大的熱重載機制，不過因爲 Google 的限制，線上版本 iOS 沒法作到熱更新，所以在動態性評估中將 Flutter 排在最後。

最後咱們聊下各個方案的實現起來的研發難度：

這裏咱們暫時將 HTML5 放在第一位，由於作 HTML5 Hybrid 方案，離不開內核優化，內核優化就須要有必定內核研發能力，所以在開發者視角下 HTML5 研發難度最高。若是隻是單純的 HTML5 容器，研發難度就會大幅下降；
其次是 Flutter，目前在實際業務應用案例方面，國內較大致量的 App 暫時只有閒魚團隊引用了 Flutter；同時在 Flutter 的 GitHub 中仍然存在大量的 Open Issues 等待解決。而在實戰開發運用過程當中，Flutter 的生命週期管理，視圖棧管理，原生頁面切換等問題都須要開發者在前期選型過程當中便要重視；
接下來是 ReactNative/Weex，因爲這兩個方案開源，且有大量成熟的技術社區支持，方案的研發難度對於開發者而言並不高，同時開源代碼方便修改，更容易上手；
最後是原生方案，若是不考慮作熱修復的話，原生方案無需作任何改動，直接使用便可；若考慮熱修復方案，目前市面也有一些成熟的開源熱修復方案能夠直接使用。

綜上所述，咱們再考慮了各方的優劣以後，決定採用「HTML5 容器+內核優化」的方式來應對複雜業務的開發問題。接下來咱們就介紹下容器的架構。

1.2 容器架構

最上層是原生的 HTML5 代碼，這塊就是你們常見的 Web 開發環境，包括 HTML、CSS、JavaScript等。

下面一層即離線包管理，這個咱們在第二章節內進行詳細介紹。

再往下是 HTML5 容器層，HTML5 容器做爲中間層，將瀏覽器和支付寶底層框架有機結合起來，同時還提供各類生命週期機制、事件機制、擴展插件等內容。

在 HTML5 容器裏面有個很是重要的概念： JSBridge。經過 JSBridge，HTML5 容器將支付寶框架底層以及中間件層提供的各類能力和 HTML5 前端代碼進行聯通，其中包括 RPC（遠程過程調用，用來實現 App 和服務器通訊）、支付、掃一掃等。

最下面是支付寶底層框架，提供微應用，微服務等概念。一個 HTML5 應用，也會被框架模擬成一個微應用，經過應用 ID 進行解耦。

1.2.1 JSBridge 介紹

JSBridge 是 HTML5 容器的基石，橋接了 JS 環境與 Native，實現了 Native 代碼和瀏覽器環境的雙向通訊，Native 代碼能夠經過調用瀏覽器提供的接口運行JS，從而實現調用 JS 函數、傳遞參數到 JS 環境等；而瀏覽器到JS環境的通訊是經過 Native 攔截瀏覽器的請求來實現，請求能夠是網絡請求或者是一些內部函數的調用。

1.2.2 H5 容器定製化擴展

HTML5 容器提供了 2 種擴展方式：

JSAPI

JSAPI 方式給 HTML5 頁面增長了 Native 功能調用接口，經過實現自定義 JSAPI 類中的 Handler 方式，能夠以 Native 的形式實現特定功能，例如調用 Native 加密函數。

事件

HTML5 容器在狀態變化時會發送事件，經過監聽 HTML5 容器特定事件，能夠實現對 HTML5 容器生命週期的處理，好比修改加載進度條顏色、修改頁面導航欄等。事件提供了更強的定製性，徹底能夠知足對 HTML5 容器的各類自定義需求

1.3 容器穩定性

上面在研發難度中，咱們說起到了，HTML5 方式的研發難度是最高的，由於須要定製化內核進行性能及穩定性優化。目前支付寶採用的是阿里集團的 UC 自研內核，並針對支付寶的 HTML5 容器進行了深度優化和定製。如圖所示，UC 內核和系統內核的卡頓卡死率的數據對比效果很是顯著，咱們能夠直觀地看到 Webview 穩定性的提高。

離線包機制+發佈平臺，知足業務即時更新

目前支付寶業務的另一個特色就是須要快速迭代，變化的政策、突發事件都須要咱們能夠快速把新的業務需求觸達給用戶。可是對於 App 開發者有一個不容忽視的問題，就是應用商店審覈。因爲審覈的存在，App 上開發的業務會有一個統一排期，好比說月底會有新版本，那麼全部的業務進度都得考慮 App 的排期計劃。

2.1 離線包機制

爲了作到良好的用戶體驗，咱們在容器中引入了離線包機制。經過離線包機制，咱們將原有從線上加載的 HTML5 應用，提早下發到本地，經過讀取 IO，或者是內存，進行頁面的渲染，達到接近原生的用戶體驗。

經過發佈平臺，咱們能夠將不一樣的 HTML5 離線包，以單獨應用的形式，進行不一樣維度的下發，使原來 all in 的 Native 發佈模式，改成各業務線自行定製發佈計劃，自行制定發佈標準，自行發佈的並行發佈形式，來知足業務的快速迭代。

2.1.1 加載機制

經過內存提早加載，定時更新，啓動預加載內存等手段，咱們將一個業務包須要用到的資源加載到內存，從而使啓動過程儘可能無感知，頁面秒開無白屏。同時，咱們還有 Fallback 手段，保證在包損壞或者是未下載完成時，能夠經過在線頁面的形式，保證業務的 100% 可用性。

2.1.2 公共資源包機制

所謂公共資源包，即全部 HTML5 離線包均可能會用到的公共資源的集合。公共資源包解決多個 HTML5 應用使用同一資源產生的冗餘問題。如 React 應用使用 ReactJS 框架代碼。您能夠將公共資源放入全局資源包，以下降 HTML5 應用體積。

經過公共資源包機制，可有效下降各 HTML5 應用的包體積，從而使更新率提升，頁面開啓速度加快。

2.2 發佈平臺

爲了知足快速迭代的需求，一個強大的發佈平臺也是必不可少的。發佈平臺的核心指標，就是將發佈內容高效、精準的投放到指定的設備上，爲了實現這個目標，咱們作了以下的努力。

2.2.1 離線包大小管控及差量包機制

HTML5 容器離線包提供了更新機制，以單個離線包做爲更新維度。由於單個離線包業務很簡單，因此離線包的大小是可控的，一般小於 500KB。咱們經過大量的實踐，總結出來「500KB」這個值，既能夠知足單個業務的內容，也能夠更高效地發佈到設備上。500KB，在 4G 的時代，幾乎能夠作到用戶無感知更新，即使是 2G/3G 也能夠保證一個高的到達率。

上面說的是一個 HTML5 應用的大小。實際上，咱們更新的包會更小，發佈平臺會經過 diff 算法，計算出相同 HTML5 應用兩個不一樣的版本的差量包，差量包一般也就在幾 KB 至幾十 KB 不等，能夠作到更高的下載成功率，下載成功率必定程度就意味着實際到達率。

2.2.2 Fallback 機制

在一些極端網絡場景下，新的業務資源包更新失敗，而咱們又指望用戶使用的是最新的業務，這個時候 Fallback 訪問機制就會發揮做用。每一個離線包資源都會在發佈服平臺上存放一份，在剛剛說到的極端場景下，用戶會訪問服務器的 Fallback 地址獲取資源，從而保障頁面可用。

2.2.3 多維發佈

另外，針對剛開發好的應用，咱們能夠經過發佈平臺的灰度發佈進行發放，經過外部灰度的形式，對業務指標進行驗證，達到標準後，方可正式發佈，作到可灰度，可回滾。

更優越的 Hybrid 方案：小程序差別化解析

做爲超級 App，一個最主要的特徵就是開放。開放就是共享 App 的流量，讓外部夥伴的業務能夠經過支付寶觸達用戶，這就面臨一個質量管控的問題。支付寶須要保證這些業務是合法合規的，保障用戶的財產安全。

3.1 離線包 VS 小程序

若是開發一方業務，離線包確定是很是好的選擇。不過，要是開放給第三方合做夥伴構建生態的話，純 HTML5 頁面就有一些劣勢。

上圖是 HTML5 離線包和小程序的細節對比。總結來講，對於開放給第三方的生態，從應用體驗來說，小程序更加統一，質量有保障；從應用安全角度來說，小程序是訪問我方發佈服務器，不會直接訪問第三方連接，安全可控；從研發門檻上來講，小程序是更簡單的前端開發方式，同時也提供了很是豐富的組件。

3.2 小程序解析

小程序其實和離線包本質是相似的，都是一種 Hybrid 應用，但小程序是基於一個定製的 DSL 語言，不是前端的標準，可是相似。在 DSL 規則下業務進行小程序的開發，不支持直接操做 DOM，這種 DSL 規則下的自由能夠有效的進行質量管控。

小程序做爲一個應用，他擁有完整的生命週期。從開發到關閉，開發者均可以感覺到，這點也是 HTML5 所不具有的。另外，每一個小程序之間從運行時和持久化上，都是徹底隔離的，並且小程序運行在特定進程中，因此和支付寶也是隔離開的。

在渲染性能上，小程序採用雙線程模式將頁面渲染和業務邏輯分別放在兩個單獨的線程中，renderer 運行在 WebView 中，負責渲染界面；小程序業務邏輯運行在單獨的 worker 線程，負責事件處理、API 調用和生命週期管理。兩個線程之間經過 postMessage 以及 onMessage 進行數據交換，數據能夠從 worker 線程傳遞到 render 從新渲染界面，同時 renderer 也能夠將事件傳遞給對應的 worker 處理。一個 worker 能夠對應多個 renderer，方便頁面間數據共享和交互。

在資源加載方面，小程序採用離線化方式加載，也就是說當打開小程序時，小程序離線包必須下載到本地，因爲每一個版本只下載一次，一方面節省了每次請求的資源開銷，另外一方面啓動速度大大提高了。當有新的版本時，發佈平臺自動比對本地安裝的版本和最新版本產生並下發差量包，客戶端不須要下載整個包便可更新小程序至最新版。

3.3 構建生態