讓小程式在自有App中啟動的技術來了：mPaaS小程式架構深度解析

簡介： mPaaS 小程式架構作為一款 App 通用架構，幫助開發者面向自身的 App 實作小程式投放。不止如此，小程式代碼僅需撰寫一次，便可多端投放至自有 App、支付寶、釘釘甚至其他小程式開放平台。

⚅ 點選觀看《mPaaS 小程式新品釋出會》回放 > >

随着小程式技術的愈發成熟，不同平台的優勢和典型使用場景各有側重，同時越來越多的開發者可以結合自身的業務特色，通過小程式作為業務載體，形成單一平台或多平台的協同關系。

而今天，小程式技術的開放，mPaaS 小程式架構作為一款 App 通用架構，幫助開發者面向自身的 App 實作小程式投放。不止如此，小程式代碼僅需撰寫一次，便可多端投放至自有 App、支付寶、釘釘甚至其他小程式開放平台。

本文将圍繞支付寶在移動端架構的演進逐漸展開，分享我們在“App 動态性”“提升研發效率”等方面所做的思考和具體實踐。同時，針對 mPaaS 小程式能力的開放，也将展開介紹我們如何實作“小程式代碼隻寫一次，多端投放”，而這将給開發者帶來完全不同的開發體驗。

支付寶 App 發展曆程

首先讓我們先回顧看看支付寶 App 在近幾年的具體發展曆程。

支付寶一開始僅僅隻是一個單體應用的工具型 App，讓使用者可以在手機完成支付寶相關的業務查詢和操作。2013 年後，支付寶逐漸轉型為平台型 App， 平台型 App 具有“服務化、子產品化、工具元件化”的特點。這個時候支付寶的業務不僅僅是支付，還需要給客戶提供很多生活相關的服務，例如餘額寶、繳電費等。2015 年後支付寶成長為超級 App，此時支付寶裡面需要支援大量複雜的業務。2018 年，随着小程式的推出，支付寶開始開放自己的商業能力，用自己流量助力合作夥伴，是以整個 App 面臨開放、動态化、高可用的挑戰，面對這些挑戰，我們把它總結為以下三個方面：

1.動态性及體驗

• 面對多樣的需求，如何保證業務的快速疊代？

• 保證 App 動态更新的前提下，如何保障使用者體驗？

2.研發效率

• 如何做到代碼一次編寫，多端複用？

• 沒有用戶端開發經驗，如何提升開發效率？

3.開放生态

• 如何将能力開放給更多開發者？

• 如何連接配接更多生态平台，豐富自身 App 場景？

有了問題，我們會通過技術手段，來解決這些問題，我們從上面的三個方向出發，來進行技術選型。

首先我們從業務開發成本角度來看：

• 原生作為最基礎的開發模式，需要雙端都進行開發，無疑成本是最高的；

• 其次是 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 具備的“線上+離線”的動态性，該方案仍然存在一定差距；

• 接下來是 Flutter，雖然有很強大的熱重載機制，不過由于 Google 的限制，正式版本 iOS 無法做到熱更新，目前的話，可以通過修改引擎，修改JIT和AOT方式來做到iOS熱更，或是采取運作時解析渲染來做到動态化，但相比于上面兩個方案，在動态性上，flutter略差一些。

• 最後原生，Android/iOS 雙端均可以通過一些黑科技手段，進行動态更新，不過由于 iOS 政策禁止，是以在動态性上，原生方案暫時不推薦；

分析完四種方案的不同的幾個方向，那麼 mPaaS 帶來的答案是：

「兼顧動态性、體驗、開發效率、開放性的 Hybrid 架構方案，即 mPaaS 小程式」。

mPaaS 小程式技術解析

什麼是小程式呢？

根據 w3c 小程式白皮書對小程式的定義，小程式，是一種依賴 Web 技術，內建了原生能力的，新的移動應用程式格式。它具有擷取「便捷、連接配接穩定、安全可靠、性能優異」這四個特點。

mPaaS 小程式，基于 Web 技術，學習成本低。

一套小程式代碼，同時支援 iOS 和 Android，接近原生體驗。

同時提供豐富的元件和 API，如擷取使用者資訊、本地存儲、支付功能等。

接下來我們來拆解小程式完整的技術架構，試着通過「運作階段、開發階段、釋出階段」将小程式整體的架構展開。

• 運作階段

小程式采用雙線程模式将頁面渲染和業務邏輯分别放在兩個單獨的線程中，renderer 運作在 WebView 中，負責渲染界面；小程式業務邏輯運作在單獨的 worker 線程，負責事件處理、API 調用和生命周期管理。兩個線程之間通過postMessage 以及 onMessage 進行資料交換，資料可以從 worker 線程傳遞到 render 重新渲染界面，同時renderer也可以将事件傳遞給對應的 worker 處理。一個 worker 可以對應多個 renderer，友善頁面間資料共享和互動。

對于渲染速度、互動響應要求高的場景，如地圖，小程式将原生地圖元件嵌入到 WebView 上，相比在 Canvas 上渲染地圖，繪制速度和效率更高。

資源加載方面，小程式采用離線化方式加載，也就是說當打開小程式時，小程式離線包必須下載下傳到本地，由于每個版本隻下載下傳一次，一方面節省了每次請求的資源開銷，另一方面啟動速度大大提升了。當有新的版本時，釋出平台自動比對本地安裝的版本和最新版本産生并下發差量包，用戶端不需要下載下傳整個包即可更新小程式至最新版。

• 開發與釋出階段

應用開發必然不能缺少完善工具鍊的支援，小程式 IDE 集合了編碼、調試、預覽以及釋出等能力。用戶端經過簡單的适配，即可在真機應用中實時預覽和調試小程式。

對小程式架構有了初步的了解之後，我們接下來看看 mPaaS 小程式将如何實作動态釋出。這恰恰是 mPaaS 小程式核心的亮點，借助「包釋出和管理」的能力，App 的研發與疊代效率得以深度優化。

如上圖所示，我們重新定義了研發模式與釋出流程，每個小程式都可以作為獨立産品，有自己的釋出流程，無需等待其他團隊。各業務團隊進行完全拆分，每個業務獨立演進，獨立釋出。

在釋出過程中，要遵守以下流程：

1.名額線性，定義每次釋出的業務和性能名額；

2.智能灰階，内部灰階、外部灰階、指定灰階；

3.實時監控，修複循環；

4.線上運維修複手段技術兜底。

然後我們再聊下小程式的安全。

• 連接配接安全

基于阿裡巴巴無線保镖能力，保障小程式請求安全，篡改後的請求無法通過校驗。

• 包體安全

包體經過加密、加簽，保障下載下傳過程安全，篡改後的小程式包無法正常使用。

• 權限安全

完整的權限管理體系，針對不同小程式開放不同權限，保障使用者的隐私安全。

接着我們看下小程式架構能力擴充體系。

mPaaS 小程式本身已內建近上百個常用的 API，包括網絡、媒體、存儲、定位、掃碼、藍牙等等，這些 API 同樣可以完美的運作在支付寶中。不僅如此，應用開發者可以将自己特色的功能 mPaaS 小程式擴充能力透出給小程式開發者。這塊擴充主要包括三個方面：

• 能力擴充：提供自定義事件能力，支援“小程式 -> 原生”，以及“原生 -> 小程式”

• 樣式擴充：提供多種原生樣式定制，包括導航欄，加載動畫，啟動動畫等原生樣式

• 元件擴充：提供自定義元件能力，擴充小程式标簽

最後我們再聊聊小程式的多端投放與生态。

基于 mPaaS 小程式體系，我們可以将非常多的小程式标準，通過工具轉化成标準小程式産物，例如開發者自己寫的 mPaaS 小程式，抑或是 mPaaS 小程式市場的小程式，或者支付寶 or 其他三方小程式。通過 IDE 轉化完成後，我們可以通過兩種管道，投放到不同的端上。使用 mPaaS 釋出平台，即可投放到自有 App 中，使用其他三方開放平台，即可投放到對應的端上，一次開發，僅需少量适配，即可多端投放。

當然，對于自身 App 内業務場景相對匮乏的情況，基于 mPaaS 統一的小程式架構能力，阿裡系的三方業務場景，能夠實作無縫投放，進而滿足開發者豐富自身業務場景的需求。

基于 mPaaS 小程式的移動端能力建構

上面介紹完了 mPaaS 小程式的技術架構以及能力，接下來我們聊下基于 mPaaS 小程式在具體研發向的思考。

• 移動中台能力建設

所謂移動中台能力建設，我們希望通過整合整個 App 架構：在基礎層面，将通用的元件下沉，避免重複創造輪子，同時标準化服務接口，為更多的上層業務提供優質、穩定且标準的服務。

那麼我們就需要從兩個方面來處理這個事情。

• 基礎元件

  我們在開發過程中可能會存在這樣一個問題，就是兩個團隊協作開發，可能大家有自己沉澱的一些經典元件，我們可以對這些元件進行沉澱，同時，還可以通過小程式的自定義元件能力，對小程式提供服務。

• 核心能力服務化

  元件沉澱後，對于一些核心的業務能力，我們需要将這部分能力進行服務化，抽象出标準的服務接口or小程式API，供其他團隊或是第三方生态調用。比如說支付寶的支付服務、芝麻信用服務等，都是依托于服務化，最終良好的為其他業務提供服務的。

移動前台建設

在我們完成移動中台能力建設之後，整體的能力就已經具備了，剩下的就是結合小程式架構，建設我們的移動前台能力。

• 核心業務體驗優化

  針對一些非常核心的業務邏輯，比如支付報的支付，以及一些對性能要求比較高的業務，比如首頁，亦或是一些特殊互動的頁面。通常我們是希望通過使用原生頁面或是 flutter 等原生技術來實作頁面。因為這些頁面，通常不會有大改，是以對動态化能力要求不是很嚴格，同時原生又能滿足這些頁面多種多樣使用者體驗的需求。

• 複雜業務小程式化

  對一些複雜的二級業務，可能業務本身會頻繁的進行疊代，那麼對于原生 native 将會是災難般的開發體驗，這時候，我們需将這部分業務剝離出來，通過前端技術将業務改造成小程式，再通過釋出服務将離線包釋出到應用上。這樣，就滿足了我們業務複雜多變的場景。

• 三方生态化

  我們不僅自身提供各種各樣的服務，也需要引入第三方服務來服務更多的人群，傳統的 H5 頁面由于過于寬泛的前端标準，加上有一定的技術門檻，這裡就不如規範、簡單的小程式了。同時，在利用上面我們介紹的移動中台建設，對第三方小程式提供多種多樣的自有中台能力，完成場景多樣化。

圍繞着小程式如何幫助我們改造自身的業務子產品，并且逐漸逐漸形成動态化更新，相信大家有了更全面的認識。目前 mPaaS 小程式已開放免費試用，歡迎接入體驗。在接入測試階段，有任何答疑需求，也歡迎使用釘釘搜尋“32843812”加群。

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

點選或掃碼檢視 「mPaaS 小程式」更多資訊 > >

END

原文連結：

https://developer.aliyun.com/article/767886?

版權聲明： 本文中所有内容均屬于阿裡雲開發者社群所有，任何媒體、網站或個人未經阿裡雲開發者社群協定授權不得轉載、連結、轉貼或以其他方式複制釋出/發表。申請授權請郵件[email protected]，已獲得阿裡雲開發者社群協定授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿裡雲開發者社群，原文作者姓名"，違者本社群将依法追究責任。 如果您發現本社群中有涉嫌抄襲的内容，歡迎發送郵件至：[email protected] 進行舉報，并提供相關證據，一經查實，本社群将立刻删除涉嫌侵權内容。