隨著小程式技術的愈發成熟，不同平台的優勢和典型使用情境各有側重，同時越來越多的開發人員可以結合自身的業務特色，通過小程式作為業務載體，形成單一平台或多平台的協同關係。 而今天，小程式技術的開放，mPaaS 小程式架構作為一款 App 通用架構，協助開發人員面向自身的 App 實現小程式投放。不止如此，小程式代碼僅需撰寫一次，便可多端投放至自有 App、支付寶、DingTalk甚至其他小程式開放平台。
本文將圍繞支付寶在移動端架構的演化逐步展開，分享我們在“App 動態性”“提升研發效率”等方面所做的思考和具體實踐。同時，針對 mPaaS 小程式能力的開放，也將介紹我們如何?“小程式代碼唯寫一次，多端投放”，而這將給開發人員帶來完全不同的開發體驗。
支付寶 App 發展曆程
首先讓我們回顧一下支付寶 App 在近幾年的具體發展曆程。
支付寶一開始僅僅只是一個單體應用的工具型 App，讓使用者可以在手機完成支付寶相關的業務查詢和操作。2013 年後，支付寶逐步轉型為平台型 App， 平台型 App 具有“服務化、模組化、工具組件化”的特點。這個時候支付寶的業務不僅是支付，還需要給客戶提供很多生活相關的服務，例如餘額寶、繳電費等。2015 年後支付寶成長為超級 App，此時支付寶裡面需要支援大量複雜的業務。2018 年，隨著小程式的推出，支付寶開始開放自己的商業能力，用自身流量助力夥伴，因此整個 App 面臨開放、動態化、高可用的挑戰，面對這些挑戰，我們把它總結為以下三個方面：
動態性及體驗
面對多樣的需求，如何保證業務的快速迭代？
在保證 App 動態更新的前提下，如何保證使用者體驗？
研發效率
如何做到代碼一次編寫，多端複用？
沒有用戶端開發經驗，如何提升開發效率？
開放生態
如何將能力開放給更多開發人員？
如何串連更多生態平台，豐富自身 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 技術，整合了原生能力的，新的行動裝置 App程式格式。它具有擷取「便捷、串連穩定、安全可靠、效能優異」這四個特點。
mPaaS 小程式，基於 Web 技術，學習成本低。 一套小程式代碼，同時支援 iOS 和 Android，接近原生體驗。 同時提供豐富的組件和 API，如擷取使用者資訊、本機存放區、支付功能等。
接下來我們來拆解小程式完整的技術架構，試著通過「運行階段、開發階段、發布階段」將小程式整體的架構展開。
運行階段 小程式採用雙線程模式將頁面渲染和商務邏輯分別放在兩個單獨的線程中，renderer 運行在 WebView 中，負責渲染介面；小程式商務邏輯運行在單獨的 worker 線程，負責事件處理、API 呼叫和生命週期管理。兩個線程之間通過 postMessage 以及 onMessage 進行資料交換，資料可以從 worker 線程傳遞到 render 重新渲染介面，同時 renderer 也可以將事件傳遞給對應的 worker 處理。一個 worker 可以對應多個 renderer，方便頁面間資料共用和互動。
對於渲染速度、互動響應要求高的情境，如地圖，小程式將原生地圖組件嵌入到 WebView 上，相比在 Canvas 上渲染地圖，繪製速度和效率更高。
資源載入方面，小程式採用離線包機制，通過該機制在初次開機時需下載完整離線包至本地，由於每個版本僅需下載一次，既降低了重複請求的資源消耗，又顯著提升了啟動效率；在此基礎上，當檢測到新版本時，發布平台會自動比對本地安裝版本與最新版本差異並產生差量包，用戶端無需下載完整包體即可實現小程式的平滑更新。
開發與發布階段 應用開發必然不能缺少完善工具鏈的支援，小程式 IDE 集合了編碼、調試、預覽以及發布等能力。用戶端經過簡單的適配，即可在真機應用中即時預覽和調試小程式。
對小程式架構有了初步的瞭解之後，我們接下來看看 mPaaS 小程式將如何?動態發布。這恰恰是 mPaaS 小程式核心的亮點，藉助「包發布和管理」的能力，App 的研發與迭代效率得以深度最佳化。
如上圖所示，我們重新定義了研發模式與發布流程，每個小程式都可以作為獨立產品，有自己的發布流程，無需等待其他團隊。各業務團隊進行完全拆分，每個業務獨立演化，獨立發布。
在發布過程中，要遵守以下流程：
指標線性，定義每次發布的業務和效能指標；
智能灰階，內部灰階、外部灰階、指定灰階；
即時監控，修複迴圈；
線上營運修複手段技術兜底。
然後我們再聊下小程式的安全。
串連安全 基於阿里巴巴無線保鏢能力，保障小程式請求安全，篡改後的請求無法通過校正。
包體安全 包體經過加密、加簽，保障下載過程安全，篡改後的小程式包無法正常使用。
許可權安全 完整的許可權管理體系，針對不同小程式開放不同許可權，保障使用者的隱私安全。
接著我們看下小程式架構能力擴充體系。
mPaaS 小程式已內建近百個常用 API，覆蓋網路、媒體、儲存、定位、掃碼、藍芽等核心情境，這些能力在支付寶平台實現無縫相容；同時，應用開發人員可通過 mPaaS 的擴充介面，將自身特色功能模組化封裝後開放給小程式開發人員調用，形成生態級能力共用。這塊擴充主要包括三個方面：
能力擴充：提供自訂事件能力，支援“小程式 > 原生”，以及“原生 > 小程式”。
樣式擴充：提供多種原生樣式定製，包括導覽列、載入動畫、啟動動畫等原生樣式。
組件擴充：提供自訂群組件能力，擴充小程式標籤。
最後我們再聊聊小程式的多端投放與生態。
基於 mPaaS 小程式體系，我們可以通過工具將多種小程式標準轉化為標準小程式產物。這些標準包括：開發人員自主開發的 mPaaS 小程式、mPaaS 小程式市場中的小程式，以及支付寶或其他第三方小程式等。通過 IDE 轉化完成後，我們可以通過兩種渠道，投放到不同的端上。使用 mPaaS 發布平台，即可投放到自有 App 中，使用其他三方開放平台，即可投放到對應的端上，一次開發，僅需少量適配，即可多端投放。
當然，對於自身 App 內業務情境相對匱乏的情況，基於 mPaaS 統一的小程式架構能力，阿里系的三方業務情境，能夠實現無縫投放，從而滿足開發人員豐富自身業務情境的需求。
基於 mPaaS 小程式的移動端能力構建
上面介紹完了 mPaaS 小程式的技術架構以及能力，接下來我們聊下基於 mPaaS 小程式在具體研發方向的思考。
移動中台能力建設
所謂移動中台能力建設，我們希望通過整合整個 App 架構：在基礎層面，將通用的組件下沉，避免重複創造輪子，同時標準化服務介面，為更多的上層業務提供優質、穩定且標準的服務。 那麼我們就需要從兩個方面來處理這件事情。
基礎組件
我們在開發過程中可能會存在這樣一個問題，就是兩個團隊協作開發，可能大家有自己沉澱的一些經典組件，我們可以對這些組件進行沉澱，同時，還可以通過小程式的自訂群組件能力，對小程式提供服務。 核心能力服務化
組件沉澱後，對於一些核心的業務能力，我們需要將這部分能力進行服務化，抽象出標準的服務介面或小程式 API，供其他團隊或是第三方生態調用。比如說支付寶的支付服務、芝麻信用服務等，都是依託於服務化，最終良好地為其他業務提供服務的。
移動前台建設
在我們完成移動中台能力建設之後，整體的能力就已經具備了，剩下的就是結合小程式架構，建設我們的移動前台能力。
核心業務體驗最佳化
針對一些非常核心的商務邏輯，比如支付寶的支付，以及一些對效能要求比較高的業務，比如首頁，或是一些特殊互動的頁面。通常我們是希望通過使用原生頁面或是 Flutter 等原生技術來實現頁面。因為這些頁面，通常不會有大改變，所以對動態化能力要求不是很嚴格，同時原生又能滿足這些頁面多種多樣使用者體驗的需求。
複雜業務小程式化
對一些複雜的二級業務，可能業務本身會頻繁地進行迭代，那麼對於原生 native 將會是災難般的開發體驗，這時候，我們需要將這部分業務剝離出來，通過前端技術將業務改造成小程式，再通過發布服務將離線包發布到應用上。這樣，就滿足了我們業務複雜多變的情境。
三方生態化
我們不僅需要自身提供各種各樣的服務，也需要引入第三方服務來服務更多的人群，傳統的 H5 頁面由於過於寬泛的前端標準，加上有一定的技術門檻，這裡就不如規範、簡單的小程式了。同時，再利用上面我們介紹的移動中台建設，對第三方小程式提供多種多樣的自有中台能力，完成情境多樣化。
圍繞著小程式如何協助我們改造自身的業務模組，並且逐步形成動態化更新，相信大家有了更全面的認識。
目前 mPaaS 小程式已開放免費試用，歡迎接入體驗。在接入測試階段，如有任何答疑需求，也歡迎搜尋DingTalk群 145930007362 進行交流。