本文將圍繞支付寶在移動端架構(gòu)的演進(jìn)逐步展開，分享我們在“App 動態(tài)性”“提升研發(fā)效率”等方面所做的思考和具體實(shí)踐。同時(shí)，針對 mPaaS 小程序能力的開放，也將展開介紹我們?nèi)绾螌?shí)現(xiàn)“小程序代碼只寫一次，多端投放”，而這將給開發(fā)者帶來完全不同的開發(fā)體驗(yàn)。

支付寶 App 發(fā)展歷程

首先讓我們先回顧看看支付寶 App 在近幾年的具體發(fā)展歷程。

支付寶一開始僅僅只是一個(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ù)。2018 年，隨著小程序的推出，支付寶開始開放自己的商業(yè)能力，用自己流量助力合作伙伴，因此整個(gè) App 面臨開放、動態(tài)化、高可用的挑戰(zhàn)，面對這些挑戰(zhàn)，我們把它總結(jié)為以下三個(gè)方面：

1.動態(tài)性及體驗(yàn)
· 面對多樣的需求，如何保證業(yè)務(wù)的快速迭代？
· 保證 App 動態(tài)更新的前提下，如何保障用戶體驗(yàn)？

2.研發(fā)效率
· 如何做到代碼一次編寫，多端復(fù)用？
· 沒有客戶端開發(fā)經(jīng)驗(yàn)，如何提升開發(fā)效率？

3.開放生態(tài)
· 如何將能力開放給更多開發(fā)者？
· 如何連接更多生態(tài)平臺，豐富自身 App 場景？

有了問題，我們會通過技術(shù)手段，來解決這些問題，我們從上面的三個(gè)方向出發(fā)，來進(jìn)行技術(shù)選型。

首先我們從業(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)等特性標(biāo)明 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)，但總體性能仍有差異。

接著是動態(tài)性的支持：
· 首先，動態(tài)性最優(yōu)的就是 HTML5 方案：可以訪問在線頁面，服務(wù)端即時(shí)生效，也可以通過下發(fā)資源的方式，進(jìn)行動態(tài)更新；
· 其次是 ReactNative/Weex 方案，通過一定的定制，開發(fā)者可以將前端包熱部署、熱更新。不過相較于 HTML5 具備的“在線+離線”的動態(tài)性，該方案仍然存在一定差距；
· 接下來是 Flutter，雖然有很強(qiáng)大的熱重載機(jī)制，不過由于 Google 的限制，正式版本 iOS 無法做到熱更新，目前的話，可以通過修改引擎，修改JIT和AOT方式來做到iOS熱更，或是采取運(yùn)行時(shí)解析渲染來做到動態(tài)化，但相比于上面兩個(gè)方案，在動態(tài)性上，flutter略差一些。
· 最后原生，Android/iOS 雙端均可以通過一些黑科技手段，進(jìn)行動態(tài)更新，不過由于 iOS 政策禁止，因此在動態(tài)性上，原生方案暫時(shí)不推薦；

分析完四種方案的不同的幾個(gè)方向，那么 mPaaS 帶來的答案是：
「兼顧動態(tài)性、體驗(yàn)、開發(fā)效率、開放性的 Hybrid 架構(gòu)方案，即 mPaaS 小程序」。

mPaaS 小程序技術(shù)解析

什么是小程序呢？
根據(jù) w3c 小程序白皮書對小程序的定義，小程序，是一種依賴 Web 技術(shù)，集成了原生能力的，新的移動應(yīng)用程序格式。它具有獲取「便捷、連接穩(wěn)定、安全可靠、性能優(yōu)異」這四個(gè)特點(diǎn)。

mPaaS 小程序，基于 Web 技術(shù)，學(xué)習(xí)成本低。
一套小程序代碼，同時(shí)支持 iOS 和 Android，接近原生體驗(yàn)。
同時(shí)提供豐富的組件和 API，如獲取用戶信息、本地存儲、支付功能等。

接下來我們來拆解小程序完整的技術(shù)架構(gòu)，試著通過「運(yùn)行階段、開發(fā)階段、發(fā)布階段」將小程序整體的架構(gòu)展開。

· 運(yù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ù)共享和交互。

對于渲染速度、交互響應(yīng)要求高的場景，如地圖，小程序?qū)⒃貓D組件嵌入到 WebView 上，相比在 Canvas 上渲染地圖，繪制速度和效率更高。

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

· 開發(fā)與發(fā)布階段
應(yīng)用開發(fā)必然不能缺少完善工具鏈的支持，小程序 IDE 集合了編碼、調(diào)試、預(yù)覽以及發(fā)布等能力?？蛻舳私?jīng)過簡單的適配，即可在真機(jī)應(yīng)用中實(shí)時(shí)預(yù)覽和調(diào)試小程序。

對小程序架構(gòu)有了初步的了解之后，我們接下來看看 mPaaS 小程序?qū)⑷绾螌?shí)現(xiàn)動態(tài)發(fā)布。這恰恰是 mPaaS 小程序核心的亮點(diǎn)，借助「包發(fā)布和管理」的能力，App 的研發(fā)與迭代效率得以深度優(yōu)化。

如上圖所示，我們重新定義了研發(fā)模式與發(fā)布流程，每個(gè)小程序都可以作為獨(dú)立產(chǎn)品，有自己的發(fā)布流程，無需等待其他團(tuán)隊(duì)。各業(yè)務(wù)團(tuán)隊(duì)進(jìn)行完全拆分，每個(gè)業(yè)務(wù)獨(dú)立演進(jìn)，獨(dú)立發(fā)布。

在發(fā)布過程中，要遵守以下流程：
1.指標(biāo)線性，定義每次發(fā)布的業(yè)務(wù)和性能指標(biāo)；
2.智能灰度，內(nèi)部灰度、外部灰度、指定灰度；
3.實(shí)時(shí)監(jiān)控，修復(fù)循環(huán)；
4.線上運(yùn)維修復(fù)手段技術(shù)兜底。

然后我們再聊下小程序的安全。
· 連接安全
基于阿里巴巴無線保鏢能力，保障小程序請求安全，篡改后的請求無法通過校驗(yàn)。
· 包體安全
包體經(jīng)過加密、加簽，保障下載過程安全，篡改后的小程序包無法正常使用。
· 權(quán)限安全
完整的權(quán)限管理體系，針對不同小程序開放不同權(quán)限，保障用戶的隱私安全。

接著我們看下小程序框架能力擴(kuò)展體系。

mPaaS 小程序本身已集成近上百個(gè)常用的 API，包括網(wǎng)絡(luò)、媒體、存儲、定位、掃碼、藍(lán)牙等等，這些 API 同樣可以完美的運(yùn)行在支付寶中。不僅如此，應(yīng)用開發(fā)者可以將自己特色的功能 mPaaS 小程序擴(kuò)展能力透出給小程序開發(fā)者。這塊擴(kuò)展主要包括三個(gè)方面：
· 能力擴(kuò)展：提供自定義事件能力，支持“小程序 -> 原生”，以及“原生 -> 小程序”
· 樣式擴(kuò)展：提供多種原生樣式定制，包括導(dǎo)航欄，加載動畫，啟動動畫等原生樣式
· 組件擴(kuò)展：提供自定義組件能力，擴(kuò)展小程序標(biāo)簽

最后我們再聊聊小程序的多端投放與生態(tài)。

基于 mPaaS 小程序體系，我們可以將非常多的小程序標(biāo)準(zhǔn)，通過工具轉(zhuǎn)化成標(biāo)準(zhǔn)小程序產(chǎn)物，例如開發(fā)者自己寫的 mPaaS 小程序，抑或是 mPaaS 小程序市場的小程序，或者支付寶 or 其他三方小程序。通過 IDE 轉(zhuǎn)化完成后，我們可以通過兩種渠道，投放到不同的端上。使用 mPaaS 發(fā)布平臺，即可投放到自有 App 中，使用其他三方開放平臺，即可投放到對應(yīng)的端上，一次開發(fā)，僅需少量適配，即可多端投放。

當(dāng)然，對于自身 App 內(nèi)業(yè)務(wù)場景相對匱乏的情況，基于 mPaaS 統(tǒng)一的小程序框架能力，阿里系的三方業(yè)務(wù)場景，能夠?qū)崿F(xiàn)無縫投放，從而滿足開發(fā)者豐富自身業(yè)務(wù)場景的需求。

基于 mPaaS 小程序的移動端能力構(gòu)建

上面介紹完了 mPaaS 小程序的技術(shù)架構(gòu)以及能力，接下來我們聊下基于 mPaaS 小程序在具體研發(fā)向的思考。
· 移動中臺能力建設(shè)

所謂移動中臺能力建設(shè)，我們希望通過整合整個(gè) App 架構(gòu)：在基礎(chǔ)層面，將通用的組件下沉，避免重復(fù)創(chuàng)造輪子，同時(shí)標(biāo)準(zhǔn)化服務(wù)接口，為更多的上層業(yè)務(wù)提供優(yōu)質(zhì)、穩(wěn)定且標(biāo)準(zhǔn)的服務(wù)。
那么我們就需要從兩個(gè)方面來處理這個(gè)事情。

• 基礎(chǔ)組件
  我們在開發(fā)過程中可能會存在這樣一個(gè)問題，就是兩個(gè)團(tuán)隊(duì)協(xié)作開發(fā)，可能大家有自己沉淀的一些經(jīng)典組件，我們可以對這些組件進(jìn)行沉淀，同時(shí)，還可以通過小程序的自定義組件能力，對小程序提供服務(wù)。

• 核心能力服務(wù)化
  組件沉淀后，對于一些核心的業(yè)務(wù)能力，我們需要將這部分能力進(jìn)行服務(wù)化，抽象出標(biāo)準(zhǔn)的服務(wù)接口or小程序API，供其他團(tuán)隊(duì)或是第三方生態(tài)調(diào)用。比如說支付寶的支付服務(wù)、芝麻信用服務(wù)等，都是依托于服務(wù)化，最終良好的為其他業(yè)務(wù)提供服務(wù)的。

移動前臺建設(shè)

在我們完成移動中臺能力建設(shè)之后，整體的能力就已經(jīng)具備了，剩下的就是結(jié)合小程序框架，建設(shè)我們的移動前臺能力。

• 核心業(yè)務(wù)體驗(yàn)優(yōu)化
  針對一些非常核心的業(yè)務(wù)邏輯，比如支付報(bào)的支付，以及一些對性能要求比較高的業(yè)務(wù)，比如首頁，亦或是一些特殊交互的頁面。通常我們是希望通過使用原生頁面或是 flutter 等原生技術(shù)來實(shí)現(xiàn)頁面。因?yàn)檫@些頁面，通常不會有大改，所以對動態(tài)化能力要求不是很嚴(yán)格，同時(shí)原生又能滿足這些頁面多種多樣用戶體驗(yàn)的需求。

• 復(fù)雜業(yè)務(wù)小程序化
  對一些復(fù)雜的二級業(yè)務(wù)，可能業(yè)務(wù)本身會頻繁的進(jìn)行迭代，那么對于原生 native 將會是災(zāi)難般的開發(fā)體驗(yàn)，這時(shí)候，我們需將這部分業(yè)務(wù)剝離出來，通過前端技術(shù)將業(yè)務(wù)改造成小程序，再通過發(fā)布服務(wù)將離線包發(fā)布到應(yīng)用上。這樣，就滿足了我們業(yè)務(wù)復(fù)雜多變的場景。

• 三方生態(tài)化
  我們不僅自身提供各種各樣的服務(wù)，也需要引入第三方服務(wù)來服務(wù)更多的人群，傳統(tǒng)的 H5 頁面由于過于寬泛的前端標(biāo)準(zhǔn)，加上有一定的技術(shù)門檻，這里就不如規(guī)范、簡單的小程序了。同時(shí)，在利用上面我們介紹的移動中臺建設(shè)，對第三方小程序提供多種多樣的自有中臺能力，完成場景多樣化。

圍繞著小程序如何幫助我們改造自身的業(yè)務(wù)模塊，并且逐步逐步形成動態(tài)化更新，相信大家有了更全面的認(rèn)識。目前 mPaaS 小程序已開放免費(fèi)試用，歡迎接入體驗(yàn)。在接入測試階段，有任何答疑需求，也歡迎使用釘釘搜索“32843812”加群。

我和我的同事等待你的到來。

原文鏈接： https://developer.aliyun.com/article/767886?utm_content=g_1000163105