根據(jù)公開的 2018 年移動(dòng)互聯(lián)網(wǎng)行業(yè)分析報(bào)告，目前支付寶的月活躍用戶已經(jīng)超過 QQ ，成為國內(nèi)第二大 App。

支付寶一開始僅僅只是一個(gè)單體應(yīng)用的工具型 App，讓用戶可以在手機(jī)完成支付寶相關(guān)的業(yè)務(wù)查詢和操作。2013 年后，支付寶逐步轉(zhuǎn)型為平臺型 App， 平臺型 App 具有服務(wù)化、模塊化、工具組件化的特點(diǎn)。這個(gè)時(shí)候支付寶的業(yè)務(wù)不僅僅是支付，還需要給客戶提供很多生活相關(guān)的服務(wù)，例如余額寶、繳電費(fèi)等。2015 年后支付寶成長為超級 App，此時(shí)支付寶里面需要支持大量復(fù)雜的業(yè)務(wù)，同時(shí)開放自己的商業(yè)能力，用自己流量助力合作伙伴，因此整個(gè) App 面臨開放、動(dòng)態(tài)化、高可用的挑戰(zhàn)，面對這些挑戰(zhàn)，我們把它總結(jié)為以下三點(diǎn)：

1. 如何應(yīng)對復(fù)雜的業(yè)務(wù)協(xié)同？

2. 如何滿足業(yè)務(wù)快速迭代的需求？

3. 如何構(gòu)建面向未來的開放生態(tài)？

利用 Hybrid App 架構(gòu)，應(yīng)對復(fù)雜的業(yè)務(wù)協(xié)同

App 的業(yè)務(wù)越來越復(fù)雜，不僅僅是內(nèi)部業(yè)務(wù)，還包含了大量外部的合作伙伴。如果采用傳統(tǒng)的 App 開發(fā)方式很難應(yīng)對日趨復(fù)雜的業(yè)務(wù)場景。

1.1 Hybrid 技術(shù)方案選型

在 Hybrid 技術(shù)方案選型方面，我們通過“開發(fā)成本、用戶體驗(yàn)、動(dòng)態(tài)性、復(fù)雜業(yè)務(wù)支持能力、研發(fā)難度”五個(gè)方面綜合考量。我們篩選出 HTML5、ReactNative/Weex、Flutter 作為備選，并將原生開發(fā)作為基準(zhǔn)線完成對比。（考慮到近期 Flutter 的熱度持續(xù)走高，因此我們納入 Flutter 一并分析。）

首先我們從業(yè)務(wù)開發(fā)成本角度來看：

• 原生作為最基礎(chǔ)的開發(fā)模式，需要雙端都進(jìn)行開發(fā)，無疑成本是最高的；

• 其次是 ReactNative/Weex，即使是一次開發(fā)，同時(shí)運(yùn)行在雙端，但由于是 JS 轉(zhuǎn)成 Native 組件渲染，實(shí)際運(yùn)行起來仍然存在些許差異，導(dǎo)致開發(fā)者在寫業(yè)務(wù)界面時(shí)，部分差異需要通過 Native 端定制開發(fā)來解決。整體而言，ReactNative/Weex 已幫助業(yè)務(wù)方大幅降低開發(fā)成本；

• 接下來是 Flutter，從業(yè)務(wù)開發(fā)的角度來說，F(xiàn)lutter 針對雙端對齊真的下了大功夫。在大多數(shù)場景下，Android 端開發(fā)完畢之后能無縫跑在 iOS 端，當(dāng)然這和它自研的引擎有關(guān)。只不過 Flutter 需基于 Dart 語言開發(fā)，因此對于開發(fā)者而言，部分老業(yè)務(wù)移植的工作量需考慮在內(nèi)；

• 最后是 HTML5，帶著成熟的語言，成熟的開發(fā)模式，雙端幾乎一樣的表現(xiàn)等特性表明 HTML5 仍然是目前我們能落地的開發(fā)成本最低的方案。

接下來我們討論用戶體驗(yàn)：

• 首先，原生的體驗(yàn)毋庸置疑是最好的；

• 其次是自有渲染引擎的 Flutter，無論是性能還是控件的展現(xiàn)形式，可以說是不亞于原生的體驗(yàn)；

• 接下來便是 ReactNative/Weex 方案，通過將前端代碼渲染成本地 Natvie 控件。在早期版本中，由于部分控件優(yōu)化不到位導(dǎo)致 App 卡頓，因此用戶體驗(yàn)的表現(xiàn)不足；

• 最后是 HTML5，完全通過瀏覽器內(nèi)核進(jìn)行渲染，借助預(yù)置資源、內(nèi)核優(yōu)化等技術(shù)，HTML5 可以做到接近原生的體驗(yàn)，但總體性能仍有差異。

接著是動(dòng)態(tài)性的支持：

在本文第二章節(jié)“離線包機(jī)制+發(fā)布平臺”，我們會(huì)從快速迭代的角度深度分析動(dòng)態(tài)性在支撐高并發(fā)業(yè)務(wù)場景下的重要性。

首先，動(dòng)態(tài)性最優(yōu)的就是 HTML5 方案：可以訪問在線頁面，服務(wù)端即時(shí)生效，也可以通過下發(fā)資源的方式，進(jìn)行動(dòng)態(tài)更新；

其次是 ReactNative/Weex 方案，通過一定的定制，開發(fā)者可以將前端包熱部署、熱更新。不過相較于 HTML5 具備的“在線+離線”的動(dòng)態(tài)性，該方案仍然存在一定差距；

接下來是原生，Android/iOS 雙端均可以通過一些黑科技手段，進(jìn)行動(dòng)態(tài)更新，不過由于 iOS 政策禁止，因此在動(dòng)態(tài)性上，原生方案暫時(shí)不推薦；

最后是 Flutter，雖然有很強(qiáng)大的熱重載機(jī)制，不過由于 Google 的限制，線上版本 iOS 無法做到熱更新，因此在動(dòng)態(tài)性評估中將 Flutter 排在最后。

最后我們聊下各個(gè)方案的實(shí)現(xiàn)起來的研發(fā)難度：

• 這里我們暫時(shí)將 HTML5 放在第一位，因?yàn)樽?HTML5 Hybrid 方案，離不開內(nèi)核優(yōu)化，內(nèi)核優(yōu)化就需要有一定內(nèi)核研發(fā)能力，因此在開發(fā)者視角下 HTML5 研發(fā)難度最高。如果只是單純的 HTML5 容器，研發(fā)難度就會(huì)大幅降低；

• 其次是 Flutter，目前在實(shí)際業(yè)務(wù)應(yīng)用案例方面，國內(nèi)較大體量的 App 暫時(shí)只有閑魚團(tuán)隊(duì)引用了 Flutter；同時(shí)在 Flutter 的 GitHub 中仍然存在大量的 Open Issues 等待解決。而在實(shí)戰(zhàn)開發(fā)運(yùn)用過程中，F(xiàn)lutter 的生命周期管理，視圖棧管理，原生頁面切換等問題都需要開發(fā)者在前期選型過程中便要重視；

• 接下來是 ReactNative/Weex，由于這兩個(gè)方案開源，且有大量成熟的技術(shù)社區(qū)支持，方案的研發(fā)難度對于開發(fā)者而言并不高，同時(shí)開源代碼方便修改，更容易上手；

• 最后是原生方案，如果不考慮做熱修復(fù)的話，原生方案無需做任何改動(dòng)，直接使用即可；若考慮熱修復(fù)方案，目前市面也有一些成熟的開源熱修復(fù)方案可以直接使用。

綜上所述，我們再考慮了各方的優(yōu)劣之后，決定采用“HTML5 容器+內(nèi)核優(yōu)化”的方式來應(yīng)對復(fù)雜業(yè)務(wù)的開發(fā)問題。接下來我們就介紹下容器的架構(gòu)。

1.2 容器架構(gòu)

最上層是原生的 HTML5 代碼，這塊就是大家常見的 Web 開發(fā)環(huán)境，包括 HTML、CSS、JavaScript等。

下面一層即離線包管理，這個(gè)我們在第二章節(jié)內(nèi)進(jìn)行詳細(xì)介紹。

再往下是 HTML5 容器層，HTML5 容器作為中間層，將瀏覽器和支付寶底層框架有機(jī)結(jié)合起來，同時(shí)還提供各種生命周期機(jī)制、事件機(jī)制、擴(kuò)展插件等內(nèi)容。

在 HTML5 容器里面有個(gè)非常重要的概念： JSBridge。通過 JSBridge，HTML5 容器將支付寶框架底層以及中間件層提供的各種能力和 HTML5 前端代碼進(jìn)行聯(lián)通，其中包括 RPC（遠(yuǎn)程過程調(diào)用，用來實(shí)現(xiàn) App 和服務(wù)器通信）、支付、掃一掃等。

最下面是支付寶底層框架，提供微應(yīng)用，微服務(wù)等概念。一個(gè) HTML5 應(yīng)用，也會(huì)被框架模擬成一個(gè)微應(yīng)用，通過應(yīng)用 ID 進(jìn)行解耦。

1.2.1 JSBridge 介紹

JSBridge 是 HTML5 容器的基石，橋接了 JS 環(huán)境與 Native，實(shí)現(xiàn)了 Native 代碼和瀏覽器環(huán)境的雙向通信，Native 代碼可以通過調(diào)用瀏覽器提供的接口運(yùn)行JS，從而實(shí)現(xiàn)調(diào)用 JS 函數(shù)、傳遞參數(shù)到 JS 環(huán)境等；而瀏覽器到JS環(huán)境的通信是通過 Native 攔截瀏覽器的請求來實(shí)現(xiàn)，請求可以是網(wǎng)絡(luò)請求或者是一些內(nèi)部函數(shù)的調(diào)用。

1.2.2 H5 容器定制化擴(kuò)展

HTML5 容器提供了 2 種擴(kuò)展方式：

• JSAPI

JSAPI 方式給 HTML5 頁面增加了 Native 功能調(diào)用接口，通過實(shí)現(xiàn)自定義 JSAPI 類中的 Handler 方式，可以以 Native 的形式實(shí)現(xiàn)特定功能，例如調(diào)用 Native 加密函數(shù)。

• 事件

HTML5 容器在狀態(tài)變化時(shí)會(huì)發(fā)送事件，通過監(jiān)聽 HTML5 容器特定事件，可以實(shí)現(xiàn)對 HTML5 容器生命周期的處理，比如修改加載進(jìn)度條顏色、修改頁面導(dǎo)航欄等。事件提供了更強(qiáng)的定制性，完全可以滿足對 HTML5 容器的各種自定義需求

1.3 容器穩(wěn)定性

上面在研發(fā)難度中，我們提及到了，HTML5 方式的研發(fā)難度是最高的，因?yàn)樾枰ㄖ苹瘍?nèi)核進(jìn)行性能及穩(wěn)定性優(yōu)化。目前支付寶采用的是阿里集團(tuán)的 UC 自研內(nèi)核，并針對支付寶的 HTML5 容器進(jìn)行了深度優(yōu)化和定制。如圖所示，UC 內(nèi)核和系統(tǒng)內(nèi)核的卡頓卡死率的數(shù)據(jù)對比效果非常顯著，我們可以直觀地看到 Webview 穩(wěn)定性的提升。

離線包機(jī)制+發(fā)布平臺，滿足業(yè)務(wù)即時(shí)更新

目前支付寶業(yè)務(wù)的另外一個(gè)特點(diǎn)就是需要快速迭代，變化的政策、突發(fā)事件都需要我們可以快速把新的業(yè)務(wù)需求觸達(dá)給用戶。但是對于 App 開發(fā)者有一個(gè)不容忽視的問題，就是應(yīng)用商店審核。由于審核的存在，App 上開發(fā)的業(yè)務(wù)會(huì)有一個(gè)統(tǒng)一排期，比如說月底會(huì)有新版本，那么所有的業(yè)務(wù)進(jìn)度都得考慮 App 的排期計(jì)劃。

2.1 離線包機(jī)制

為了做到良好的用戶體驗(yàn)，我們在容器中引入了離線包機(jī)制。通過離線包機(jī)制，我們將原有從線上加載的 HTML5 應(yīng)用，提前下發(fā)到本地，通過讀取 IO，或者是內(nèi)存，進(jìn)行頁面的渲染，達(dá)到接近原生的用戶體驗(yàn)。

通過發(fā)布平臺，我們可以將不同的 HTML5 離線包，以單獨(dú)應(yīng)用的形式，進(jìn)行不同維度的下發(fā)，使原來 all in 的 Native 發(fā)布模式，改為各業(yè)務(wù)線自行定制發(fā)布計(jì)劃，自行制定發(fā)布標(biāo)準(zhǔn)，自行發(fā)布的并行發(fā)布形式，來滿足業(yè)務(wù)的快速迭代。

2.1.1 加載機(jī)制

通過內(nèi)存提前加載，定時(shí)更新，啟動(dòng)預(yù)加載內(nèi)存等手段，我們將一個(gè)業(yè)務(wù)包需要用到的資源加載到內(nèi)存，從而使啟動(dòng)過程盡量無感知，頁面秒開無白屏。同時(shí)，我們還有 Fallback 手段，保證在包損壞或者是未下載完成時(shí)，可以通過在線頁面的形式，保證業(yè)務(wù)的 100% 可用性。

2.1.2 公共資源包機(jī)制

所謂公共資源包，即所有 HTML5 離線包都可能會(huì)用到的公共資源的集合。公共資源包解決多個(gè) HTML5 應(yīng)用使用同一資源產(chǎn)生的冗余問題。如 React 應(yīng)用使用 ReactJS 框架代碼。您可以將公共資源放入全局資源包，以降低 HTML5 應(yīng)用體積。

通過公共資源包機(jī)制，可有效降低各 HTML5 應(yīng)用的包體積，從而使更新率提高，頁面開啟速度加快。

2.2 發(fā)布平臺

為了滿足快速迭代的需求，一個(gè)強(qiáng)大的發(fā)布平臺也是必不可少的。發(fā)布平臺的核心指標(biāo)，就是將發(fā)布內(nèi)容高效、精準(zhǔn)的投放到指定的設(shè)備上，為了實(shí)現(xiàn)這個(gè)目標(biāo)，我們做了如下的努力。

2.2.1 離線包大小管控及差量包機(jī)制

HTML5 容器離線包提供了更新機(jī)制，以單個(gè)離線包作為更新維度。因?yàn)閱蝹€(gè)離線包業(yè)務(wù)很簡單，所以離線包的大小是可控的，通常小于 500KB。我們通過大量的實(shí)踐，總結(jié)出來“500KB”這個(gè)值，既可以滿足單個(gè)業(yè)務(wù)的內(nèi)容，也可以更高效地發(fā)布到設(shè)備上。500KB，在 4G 的時(shí)代，幾乎可以做到用戶無感知更新，即便是 2G/3G 也可以保證一個(gè)高的到達(dá)率。

上面說的是一個(gè) HTML5 應(yīng)用的大小。實(shí)際上，我們更新的包會(huì)更小，發(fā)布平臺會(huì)通過 diff 算法，計(jì)算出相同 HTML5 應(yīng)用兩個(gè)不同的版本的差量包，差量包通常也就在幾 KB 至幾十 KB 不等，可以做到更高的下載成功率，下載成功率一定程度就意味著實(shí)際到達(dá)率。

2.2.2 Fallback 機(jī)制

在一些極端網(wǎng)絡(luò)場景下，新的業(yè)務(wù)資源包更新失敗，而我們又期望用戶使用的是最新的業(yè)務(wù)，這個(gè)時(shí)候 Fallback 訪問機(jī)制就會(huì)發(fā)揮作用。每個(gè)離線包資源都會(huì)在發(fā)布服平臺上存放一份，在剛剛說到的極端場景下，用戶會(huì)訪問服務(wù)器的 Fallback 地址獲取資源，從而保障頁面可用。

2.2.3 多維發(fā)布

另外，針對剛開發(fā)好的應(yīng)用，我們可以通過發(fā)布平臺的灰度發(fā)布進(jìn)行發(fā)放，通過外部灰度的形式，對業(yè)務(wù)指標(biāo)進(jìn)行驗(yàn)證，達(dá)到標(biāo)準(zhǔn)后，方可正式發(fā)布，做到可灰度，可回滾。

更優(yōu)越的 Hybrid 方案：小程序差異化解析

作為超級 App，一個(gè)最主要的特征就是開放。開放就是共享 App 的流量，讓外部伙伴的業(yè)務(wù)可以通過支付寶觸達(dá)用戶，這就面臨一個(gè)質(zhì)量管控的問題。支付寶需要保證這些業(yè)務(wù)是合法合規(guī)的，保障用戶的財(cái)產(chǎn)安全。

3.1 離線包 VS 小程序

如果開發(fā)一方業(yè)務(wù)，離線包肯定是非常好的選擇。不過，要是開放給第三方合作伙伴構(gòu)建生態(tài)的話，純 HTML5 頁面就有一些劣勢。

上圖是 HTML5 離線包和小程序的細(xì)節(jié)對比?？偨Y(jié)來說，對于開放給第三方的生態(tài)，從應(yīng)用體驗(yàn)來講，小程序更加統(tǒng)一，質(zhì)量有保障；從應(yīng)用安全角度來講，小程序是訪問我方發(fā)布服務(wù)器，不會(huì)直接訪問第三方鏈接，安全可控；從研發(fā)門檻上來說，小程序是更簡單的前端開發(fā)方式，同時(shí)也提供了非常豐富的組件。

3.2 小程序解析

小程序其實(shí)和離線包本質(zhì)是類似的，都是一種 Hybrid 應(yīng)用，但小程序是基于一個(gè)定制的 DSL 語言，不是前端的標(biāo)準(zhǔn)，但是類似。在 DSL 規(guī)則下業(yè)務(wù)進(jìn)行小程序的開發(fā)，不支持直接操作 DOM，這種 DSL 規(guī)則下的自由可以有效的進(jìn)行質(zhì)量管控。

小程序作為一個(gè)應(yīng)用，他擁有完整的生命周期。從開發(fā)到關(guān)閉，開發(fā)者都可以感受到，這點(diǎn)也是 HTML5 所不具備的。另外，每個(gè)小程序之間從運(yùn)行時(shí)和持久化上，都是完全隔離的，而且小程序運(yùn)行在特定進(jìn)程中，所以和支付寶也是隔離開的。

在渲染性能上，小程序采用雙線程模式將頁面渲染和業(yè)務(wù)邏輯分別放在兩個(gè)單獨(dú)的線程中，renderer 運(yùn)行在 WebView 中，負(fù)責(zé)渲染界面；小程序業(yè)務(wù)邏輯運(yùn)行在單獨(dú)的 worker 線程，負(fù)責(zé)事件處理、API 調(diào)用和生命周期管理。兩個(gè)線程之間通過 postMessage 以及 onMessage 進(jìn)行數(shù)據(jù)交換，數(shù)據(jù)可以從 worker 線程傳遞到 render 重新渲染界面，同時(shí) renderer 也可以將事件傳遞給對應(yīng)的 worker 處理。一個(gè) worker 可以對應(yīng)多個(gè) renderer，方便頁面間數(shù)據(jù)共享和交互。

在資源加載方面，小程序采用離線化方式加載，也就是說當(dāng)打開小程序時(shí)，小程序離線包必須下載到本地，由于每個(gè)版本只下載一次，一方面節(jié)省了每次請求的資源開銷，另一方面啟動(dòng)速度大大提升了。當(dāng)有新的版本時(shí)，發(fā)布平臺自動(dòng)比對本地安裝的版本和最新版本產(chǎn)生并下發(fā)差量包，客戶端不需要下載整個(gè)包即可更新小程序至最新版。

3.3 構(gòu)建生態(tài)

通過引入相同的小程序架構(gòu)，使得小程序，可以作為生態(tài)進(jìn)行多端互投。在支付寶中投放的小程序，可以只經(jīng)過一些開放接口的適配，即可跑在基于相同小程序架構(gòu)的 App 中。未來，開發(fā)者或第三方服務(wù)更多是面向小程序來開發(fā)，而 App 則是提供一個(gè)統(tǒng)一的架構(gòu)，真正做到開放生態(tài)，用完即走的理念。

關(guān)于支付寶自研 HTML5 容器方案

mPaaS 離線包源自于支付寶原生方案，經(jīng)歷了嚴(yán)苛的業(yè)務(wù)考驗(yàn)，讓你直接和支付寶使用同一套框架層代碼，擁有統(tǒng)一容器及內(nèi)核，相對系統(tǒng)內(nèi)核獲取更低 Crash 率和 ANR 率，適配性強(qiáng)，并具備良好的、彈性的擴(kuò)展能力，結(jié)合具體業(yè)務(wù)需求定制 JSAPI。

它可以幫助減少 App 白屏、解決 Hybrid App 跨平臺兼容與適配，提升 App 性能并大幅優(yōu)化原生開發(fā)下的包大小。

目前 mPaaS 離線包 Demo 源碼已更新在 GitHub 上，歡迎 Star：

https://github.com/alipay/mpaas-demo

探索 Android 內(nèi)存優(yōu)化方法

船長的 2019 ，年報(bào)元年

全新的視圖綁定工具 — ViewBinding 使用指南

（正文已結(jié)束）

推薦閱讀：松下zs70

免責(zé)聲明及提醒：此文內(nèi)容為本網(wǎng)所轉(zhuǎn)載企業(yè)宣傳資訊，該相關(guān)信息僅為宣傳及傳遞更多信息之目的，不代表本網(wǎng)站觀點(diǎn)，文章真實(shí)性請瀏覽者慎重核實(shí)！任何投資加盟均有風(fēng)險(xiǎn)，提醒廣大民眾投資需謹(jǐn)慎！