支付寶小程式框架淺析及如何在 mPaaS 內深度整合

小程式開發 · 發表 2018-12-01 16:35:57

摘要：本文將結合闊懸在 iWeb 杭州站沙龍現場的分享《支付寶小程式在 mPaaS 中的深度整合實踐》，介紹支付寶小程式框架的設計原理，以及如何在 mPaaS 體系中的深度整合支付寶小程式。分享內容將從以下兩個方面展開：支付寶小程式框架的系統介紹（支付寶小程式框架概述、應用層...

本文將結合闊懸在 iWeb 杭州站沙龍現場的分享《支付寶小程式在 mPaaS 中的深度整合實踐》，介紹支付寶小程式框架的設計原理，以及如何在 mPaaS 體系中的深度整合支付寶小程式。

分享內容將從以下兩個方面展開：

支付寶小程式框架的系統介紹 （支付寶小程式框架概述、應用層框架、Native SDK）
mPaaS 技術架構與助力 （mPaaS 小程式、mPaaS 小程式 IDE、mPaaS MDS）

2. 小程式簡介：移動網際網路新熱點

近來，小程式儼然成為了移動網際網路的新熱點。繼 2017 年初微信正式推出微信小程式後，各個大廠陸續釋出了各自的小程式 —— 支付寶小程式、百度小程式、頭條小程式，小程式成為了各家移動網際網路生態佈局的重要一環。

通過小程式生態可以引入大量的外部服務，不僅豐富了平臺的能力，而且可以為平臺帶來大量的使用者流量，從而使得平臺具備無限的潛能。

3. 支付寶小程式簡介

支付寶小程式是一種全新的開發模式，它執行在支付寶客戶端，可以被便捷地獲取和傳播，為終端使用者提供更優的使用者體驗。為方便小程式的開發者，支付寶小程式具有類似微信小程式的 DSL 和開發環境，降低小程式開發者的學習成本。

4. 支付寶小程式框架淺析

1. 基礎需求

小程式的本質需求是讓第三方開發者可以接入，使得第三方開發的小程式可以在平臺級應用中執行。

對於這個需求，最簡單的實現方案是：讓外部開發者開發純 H5 應用，在應用的

H5 容器裡開啟，容器提供一些原生的介面供H5使用。比如在支付寶和微信上的“滴滴出行”以 H5 的形式執行在各自的平臺中，這種模式看似還不錯，但是實際上這種簡單的方案不能滿足這兩個小程式的基礎需求：

體驗： 作為一個“小程式”需要讓體驗接近原生，而上述像滴滴出行這些普通 H5 的體驗不太行，包括啟動速度、頁面切換流暢度都有問題，跟原生體驗沒法比。
管控： 作為一個平臺必須對接入的應用有管控能力，必須能儘量精確控制應用的內容和型別，畢竟若出現非法應用平臺是要承擔責任的，H5 的方式太過自由，開發者可以隨時改變整個應用的內容，平臺難以檢測到這些改變，無法管控。另外 H5 開發質量參差不齊，平臺也無法管控。

2. 框架概述

為了實現小程式並滿足上述的小程式的兩個需求，小程式框架應運而生。我們先看下小程式框架大圖，自上而下看。

小程式程式碼： 這是小程式開發者使用小程式 DSL 及各種元件開發的小程式。
小程式元件及 API： 這是小程式的元件及 API 層，提供了小程式所需的各種元件和小程式 API。小程式開發者只需要在基於這一層提供的元件及 API 進行小程式的開發。
小程式應用層框架： 這是小程式執行的框架層，它基於 React 實現了小程式的執行框架。該層主要包含小程式的邏輯處理引擎及渲染層。
Native SDK： 該層提供了小程式所需的 Native 能力，通過J avaScriptCore 為小程式的 JS 層框架提供大量的 Native API，此外該層還提供了小程式包管理、後臺保活等基礎能力。
React 和 React Native： 這一層是小程式底層執行環境，分別對應於 Web 和 Native 環境，使得小程式可執行在 WebView 和 iOS/Android 上。
系統層： 即 Web 核心、iOS 和 Android，是系統級的平臺層。

目前支付寶的小程式使用的是 React 版，螞蟻內部的其他 App 有在使用 React Native 版的小程式。

3. 應用層框架

我們一起看下小程式應用層框架。每個小程式的程式碼分為兩部分——邏輯處理和檢視渲染，分別執行在 worker （js 引擎）以及 render （渲染層）中。

worker 執行小程式的邏輯處理程式碼 ，包括事件處理，api 呼叫以及框架的生命週期管理。 worker 只有一個，方便 App 資料在頁面間的共享和互動。
render 執行小程式的渲染程式碼 ，主要包括模版、樣式和框架的跨終端的 js 元件或 native 元件，獲取邏輯層的資料操作渲染引擎（React/ReactNative）進行渲染，render 在小程式中可以有多個。
worker 和所有的 render 都建立連線 ，將需要渲染的資料傳遞給對應的 render 進行渲染，worker 也會將 api 呼叫轉給 Native SDK 處理。
render 則將元件的觸發事件送到對應的 worker 處理 ，同時接受 worker 的呼叫進行重新渲染。 render 可以看作一個無狀態的渲染終端，小程式的狀態都保留在 worker 內。

可見該框架可以做到，JS 邏輯程式碼與頁面渲染分離並行執行，不會出現 JS 程式碼執行時卡住頁面渲染的情況，進而提升渲染效能。多個頁面可以共享一個 JS 執行環境，資料可以很方便地共享，整個小程式生命週期裡共享同一個上下文，更接近 App 的開發體驗。小程式的模板樣式是自定義的格式，這樣可以做到開發時使用固定的 DSL，不依賴底層的渲染引擎，這樣引擎的優化升級不會造成上層的小程式程式碼的不相容，並且渲染行為是完全是可控的。

4. Native SDK

我們再看 Native 層，在支付寶中是由 Nebula H5 容器負責實現，它為小程式提供 Native 能力，為小程式提供的包管理、後臺保活等功能。

Native API ：小程式呼叫的 API 中有部分功能需要在 native 中實現，這部分 API 通過橋接呼叫進入對應的 Native API。
包管理 ：負責小程式包的下載、儲存、載入。小程式包的下載具有多種策略，可以滿足小程式的預下載、強制更新等需求。
後臺保活 ：小程式在後臺可以存活 5 分鐘，使得使用者在下次開啟時可以獲得更好的體驗。

5. 小結

現在讓我們回到前面提到的兩個小程式的基本需求，體驗和管控。我們看下框架是如何實現這兩個需求的。對於體驗需求，主要有以下幾點：

框架對小程式做了邏輯處理和檢視渲染的分離以提升渲染效能
對於較重的元件（地圖）使用 Native 實現以提升效能
小程式公共資源預置在小程式框架以提升載入效能
後臺保活機制提高二次啟動速度

對於管控需求，主要有兩點：

小程式開發只能使用框架提供的自定義的模板樣式
JS 程式碼執行在與 Webview 隔離的 JS 引擎中，無法操作瀏覽器 DOM

5. mPaaS 技術架構與助力

1. 支付寶小程式與 mPaaS

小程式這麼有優勢，那能否把支付寶小程式放到其他 APP 中執行呢？答案是肯定的，藉助 mPaaS，小程式技術不僅在螞蟻金服內部使用，也能夠提供給外部使用者使用。

首先簡單介紹下什麼是 mPaaS，mPaaS 全稱是 Mobile Platform as a Service，即移動端的 PaaS 。作為螞蟻金服獨創的移動研發平臺，它源於支付寶近 10 年的移動技術的沉澱，為移動開發、測試、運營及運維提供雲到端的一站式解決方案，能有效降低技術門檻、減少研發成本、提升開發效率，協助生態夥伴快速搭建穩定高質量的移動 App。

2. mPaaS 小程式

再來看下什麼是 mPaaS 小程式，它是在支付寶小程式的基礎上做了瘦身、去依賴的小程式 SDK，為了能便捷的輸出給其他 App 快速地搭建出小程式平臺。它保持和支付寶小程式一樣的模板樣式和通用 API，僅僅少量的像授權這樣的開放的 API 需要客戶自定義開發。藉助 mPaaS 小程式，可以做到一套小程式程式碼，在支付寶和自己的 App 上雙端投放和執行，甚至可以構建出自己的小程式生態體系。

這裡和大家分享下 mPaaS 小程式在其他 App 中整合時可能需要解決的問題：

SDK 整合衝突，這個是多個 SDK 整合可能會遇到的共性問題，一般通過去除不要的 SDK 或者對 SDK 中部分符號名做針對性的修改。
開放 API 定製開發，開放 API 依賴後端的服務，比如使用者授權這個 API，它需要獲取使用者的賬號資訊，那麼就需要重寫這個 API 的具體實現，去訪問 App 的使用者中心服務以實現授權功能。小程式框架提供了一套自定義和重寫 API 的外掛機制，能快速的去重寫某個 API，甚至新增一個新的 API。

3. mPaaS 小程式 IDE

小程式的開發除了可使用支付寶小程式開放平臺提供的 IDE，還可以使用 mPaaS 版的小程式 IDE。通過 mPaaS 版的 IDE 可以匯出本地的小程式包，後續在 mPaaS 釋出平臺中使用這個本地包直接釋出。未來，小程式 IDE 將會與 mPaaS 直接打通，在 IDE 中可以直接完成 mPaaS 小程式的開發、測試和釋出這一系列的開發運維體驗。