支付寶移動端 Hybrid 解決方案探索與實踐 | mPaaS 線下沙龍 CodeDay#1 分享實錄

支付寶 · 發表 2019-04-01 20:40:24

摘要：根據公開的 2018 年移動網際網路行業分析報告，目前支付寶的月活躍使用者已經超過 QQ ，成為國內第二大 App。支付寶一開始僅僅只是一個單體應用的工具型 App，讓使用者可以在手機完成支付寶相關的業務查詢和操作。2013 年後，支付寶逐步轉型為平臺型 App，平...

根據公開的 2018 年移動網際網路行業分析報告，目前支付寶的月活躍使用者已經超過 QQ ，成為國內第二大 App。

支付寶一開始僅僅只是一個單體應用的工具型 App，讓使用者可以在手機完成支付寶相關的業務查詢和操作。2013 年後，支付寶逐步轉型為平臺型 App，平臺型 App 具有服務化、模組化、工具元件化的特點。這個時候支付寶的業務不僅僅是支付，還需要給客戶提供很多生活相關的服務，例如餘額寶、繳電費等。2015 年後支付寶成長為超級 App，此時支付寶裡面需要支援大量複雜的業務，同時開放自己的商業能力，用自己流量助力合作伙伴，因此整個 App 面臨開放、動態化、高可用的挑戰。

從單體應用到超級 App 的轉變，其實體現了一個使用者對 App 需求的變化：移動網際網路使用者需求的本質是服務，而不是 App，使用者高頻使用的 App 是少數。在超級 App 時代，支付寶主要面臨的挑戰是：

支援複雜業務

App 的業務越來越複雜，不僅僅是內部業務，還包含了大量外部的合作伙伴。如果採用傳統的 App 開發方式很難應對日趨複雜的業務場景。
滿足業務快速迭代的需求

當前業務的另外一個特點就是需要快速迭代，變化的政策、突發事件都需要我們可以快速把新的業務需求觸達給使用者。但是對於 App 開發者有一個不容忽視的問題，就是應用商店稽核。由於稽核的存在，App 上開發的業務會有一個統一排期，比如說月底會有新版本，那麼所有的業務進度都得考慮 App 的排期計劃。
開放平臺

作為超級 App，一個最主要的特徵就是開放。開放就是共享 App 的流量，讓外部夥伴的業務可以通過支付寶觸達使用者，這就面臨一個質量管控的問題。支付寶需要保證這些業務是合法合規的，保障使用者的財產安全。

在超級 App 時代，使用純 Native 開發會遇到很大的侷限性（這裡純 Native 開發指的是，iOS 使用 Objective-C 或者 Swift 開發、Android 使用 Java 或者 Kotlin開發）。純 Native 開發，業務邏輯的變化都需要通過釋出新版本來觸達使用者，所以會面臨前面提到的釋出稽核週期長的問題。另一方面，使用者每次需要使用新功能，都需要更新一次 App ，這對使用者來說是一個成本很高的問題，會導致新業務很難在短時間覆蓋使用者。

站在開發的角度，純 Native 的開發效率會比前端低很多，而且同時需要 iOS 和 Android 的開發人員。包大小也是需要考慮的問題，如果目前支付寶的業務都是用 Native 開發，大家看到的包大小得增加好幾倍，這進一步增加了使用者的升級成本。作為開放平臺，Native 程式碼的許可權和版本管理會變得異常的複雜，每次發版本就都需要同時協調內部和外部夥伴的業務，事情就變得非常糟糕了。

所以，現在 App 開發肯定離不開 Hybrid 方案，Hybrid 方案就是混合開發，同時結合了 Native 開發和 Web 開發技術。Web 開發經過 20 年的發展，已經將「結構 HTML、表現 CSS 和行為 JS 」3 部分拆開，因此具有很高的開發效率。Hybrid 方案同時具有跨平臺的特徵，一份程式碼同時釋出到 iOS 和 Android，節省開發時間。基於 Hybrid 方案開發的業務可以快速釋出，而不用考慮 App 發版實踐，給業務很大的靈活性。相比於 Web 開發，Hybrid 方案提供了豐富的裝置 API，讓更多業務形態成為可能。

1. 支付寶 Hybrid 方案建設與演進

目前支付寶有 2 套 Hybrid 方案： H5 容器與小程式。小程式是最近幾年才出來，H5 容器已經有了很長時間的歷史，所以我們就先從 H5 容器說起。

H5 容器

在支付寶中，H5 容器架構如圖所示：

最上層是瀏覽器，這塊就是大家常見的 Web 開發環境，包括 HTML、CSS、JavaScript等。H5 容器作為中間層，將瀏覽器和支付寶底層框架有機結合起來，在 H5 容器裡面有 2 個非常重要的概念： JSBridge 和離線包，後面會做詳細介紹。支付寶底層框架會給 H5 容器提供 Native 的能力，這其中就包括 RPC（遠端過程呼叫，用來實現 App 和伺服器通訊）、支付、掃一掃等。

JSBridge

JSBridge 是 H5 容器的基石，橋接了 JS 環境與 Native，實現了 Native 程式碼和瀏覽器環境的雙向通訊，Native 程式碼可以通過呼叫瀏覽器提供的介面執行JS，從而實現呼叫 JS 函式、傳遞引數到 JS 環境等；而瀏覽器到JS環境的通訊是通過 Native 攔截瀏覽器的請求來實現，請求可以是網路請求或者是一些內部函式的呼叫。

那麼 JSBridge 會帶來什麼好處呢，在傳統的 Web 開發場景，H5 頁面會通過 HTTP 的 GET 或者 POST 請求到後臺獲取資料，就會用到 jQuery 等 AJAX 框架。但是 H5 頁面中的 JS 函式公開的，沒法做一些加密邏輯。這幾年隨著 4G 和流量卡的普及，讓手機網路變得更快、更便宜，在這之前大量使用者會面臨流量不足、訊號差、網路不穩定的情況，這些場景在現在依然存在，而純 Web 方案是沒法提供相關的網路優化。

H5 容器提供的 JSBridge 解決了這個問題，所有 H5 頁面需要從後臺獲取的資料都通過 JS Bridge 呼叫 Native 的 RPC SDK 來獲取。這樣實際 App 請求的資料都是由 RPC SDK 來發送，從而可以實現安全加密、簽名校驗、弱網優化、流量優化的功能。Native 層的這些功能是 Web 頁面開發人員無感知的，所以業務開發人員只需要專注其自身的業務開發即可。安全性由支付寶底層 SDK 保障。

H5 容器提供了 2 種擴充套件方式：

JSAPI

JSAPI 方式給 H5 頁面增加了 Native 功能呼叫介面，通過實現自定義 JSAPI 類中的 handler 方式，可以以 Native 的形式實現特定功能，例如呼叫 Native 加密函式。
事件

H5 容器在狀態變化時會發送事件，通過監聽 H5 容器特定事件，可以實現對 H5 容器生命週期的處理，比如修改載入進度條顏色、修改頁面導航欄等。事件提供了更強的定製性，完全可以滿足對 H5 容器的各種自定義需求。
- H5 容器離線包
H5 容器離線包是 H5 容器使用者體驗的關鍵。

在 App 裡面開啟一個線上頁面的時候，通常會有一個白屏的階段，這是瀏覽器需要從伺服器下載 HTML 資源。由於手機網路的限制，這個時間會很不確定，通常會花費 300ms 以上的時間，使用者在這個時間裡面就會看到頁面白屏。

為了優化 H5 容器使用者體驗，減少白屏時間，支付寶在 H5 容器中引入了離線包技術。離線包可以簡單理解為一個 zip 壓縮包，其中包含前端頁面所需的 HTML、CSS、JS、圖片等資源。內建到客戶端後，H5 容器開啟離線包頁面時會直接從離線包中獲取資源，這個是毫秒的訪問時間，消除了開啟頁面白屏現象。

在支付寶中，離線包分為 2 種： 普通的業務資源包 和 公共資源包 。先說公共資源包吧，公共資源包中會包含一些框架 JS、CSS、常見圖片等，這些資源在整個 App 裡面就只儲存一份；而業務資源包中只儲存該業務所需的頁面靜態資源，業務之間是相互獨立解耦的。這樣一個業務的頁面資源就會同時來自其業務資源包和公共資源包，公共資源包的存在優化了 App 大小。

為了滿足快速釋出的需求，H5 容器離線包提供了更新機制，以單個離線包作為更新維度。因為單個離線包業務很簡單，所以離線包的大小是可控的，通常小於 500KB，這樣單個離線包的更新時間可控，可以做到使用者無感知。在一些極端網路場景下，新的業務資源包更新超過，而我們又期望使用者使用的是最新的業務，這個時候 fallback 訪問機制就會發揮作用。每個離線包資源都會在伺服器存放一份，在剛剛說到的極端場景下，使用者會訪問伺服器的 fallback 地址獲取資源，從而保障頁面可用。

結合前面說到的離線包後，整個 H5 容器渲染流程如下。其中離線包資源的更新、下載對使用者無感知，頁面訪問的資源是來自離線包還是來自 fallback 地址對前端是無感知的。
- UC Webview 核心
為了提高 H5 容器穩定性，支付寶在安卓系統上使用了 UC Webview，UC Webview 的崩潰率和 ANR 率遠低於系統瀏覽器，而且徹底規避了安卓系統 Webview 碎片化問題，相信做過安卓前端頁面相容的同學一定可以體會到使用一個瀏覽器核心的好處。

H5 容器作為一個成熟的 Hybrid 方案可以滿足大部分的業務場景需求，但是其依然存在一些侷限性。H5 容器的業務開發部分還保持著前端開發思維，畢竟整個過程都是使用的前端技術，只需要在業務開發完成後整合到 App 中完成測試。但是客戶端開發其中還有很多關鍵的概念，例如 iOS 的 ViewController 、Android 的 Activity 等，對客戶端頁面棧有清楚的瞭解更有助於開發 H5 容器。同時 H5 容器還存在一個致命的問題就是無法管控質量，寬泛的前端規範讓管控變得異常困難。
- 支付寶小程式
為了解決 H5 容器的侷限性，順應當前 App 共享開放的需求，支付寶推出了新的 Hybrid 方案：支付寶小程式。支付寶小程式一種全新的開放模式，它執行在支付寶客戶端，可以被便捷地獲取和傳播，為終端使用者提供更優的使用者體驗。支付寶小程式基於 Web 技術，因此學習成本低；其一套程式碼同時支援 iOS 和 Android；並提供了豐富元件和 API；完全為 App 開發而生。目前支付寶小程式已經提供 2000 多個開放介面，API 日呼叫次數超過 25 億次，擁有超過 100 萬的合作伙伴和超過 10 萬個活躍服務商。

支付寶小程式同時還支援了阿里系多個 App，包括口碑、高德和釘釘。

那麼支付寶小程式是怎麼解決 H5 容器的侷限性呢？首先支付寶小程式是基於一個定製的 DSL 語言，不是前端的標準，但是類似。在 DSL 規則下業務進行小程式的開發，不支援直接操作 DOM，這種 DSL 規則下的自由可以有效的進行質量管控。另外支付寶小程式可以提供比 H5 小程式更優秀的效能、體驗和相容性，可以無感替換底層框架，應對遇到的效能問題。

目前支付寶小程式也支援前面提到的 H5 容器所使用的離線包技術，同時也支援 JSAPI 和事件的擴充套件方式，提供了更大的靈活性。