近日，螞蟻金服開展了“共戰‘疫情’，技術破局”數字課堂線上直播，我們將系列演講整理并發布在 “螞蟻金服科技” 公眾號上。

今天，將為大家分享圍繞支付寶在移動端如何實現輕耦合、彈性動態的開發模式，深度解析其技術選型及實戰經驗。演講嘉賓是來自螞蟻金服mPaaS客戶端核心開發的溫盛章，以下為演講整理全文：

我們提供了一個移動開發平臺叫做mPaaS，現在在阿里上面已經正式的發布了。他首先是源自于我們支付寶的一個移動端的組件，目的是為了打造快速迭代的架構和動態化的能力。它是一整套的方案，包括了移動端的開發SDK，然后移動端的構建工具和后端的一整套的服務和工具作為一個整體體系的產品。我們主要要做的事情是使用移動開發平臺mPaaS來打造一個性能更優的APP。今天我們在這邊直播分享的內容是，支付寶使用mPaaS的過程中的一些動態化的實踐。

彈性動態的端上架構解析

我們在這邊，首先要介紹的一個點是彈性動態端的能力。首先我們在支付寶中面臨的一些問題是有海量的業務，然后傳統方面上的一些Hybrid方案，這是一個老生常談的話題了。然后第二個是高可用和及時快速發布的監控運維體系，這里面包含了像局部條件、灰度的能力，然后快速回滾的能力和快速迭代的一些能力。然后第三點就是開放出來我們的Hybrid的一些解決方案。

Part1：利用 Hybrid 架構應對海量業務需求

第一部分我們介紹一下如何使用一個Hybrid的價格去應對海量的業務需求。我們知道支付寶它是一個國民級的APP，它里面承載了非常多的業務，如果使用傳統的迭代方式，肯定滿足不了我們現在這些業務的需求，比如說我可能需要一個雙11的活動，雙十二的活動或者是一些別的運營活動的時候，我們需要非常快速的一些迭代的能力，不僅在IOS端和安卓端都需要有，而且也需要進行一些快速回滾。我們目前的話，在移動的端上有4種這樣的能力。這里是舉個例子的4種能力，一種是Native，然后是Html5，ReactNative，Flutter是最新的一個跨端的解決方案，目前也是在我們嘗試的范圍之內。

我們可以看一下這4個能力，它的對比的情況是這樣的。對于Native的開發同學來說，Native的開發成本是最低的，因為我們出身于Native開發，所以基本上不需要去學習一些什么特殊的東西，所以我們對整套的一個UI架構的體系和UI的API的調用之類的都是非常的熟悉，然后它的用戶體驗也是低的，我們基于像iOS UIKit以及 Android一整套的UI架構，如果是使用原生方案的話，它的體驗在目前的移動端的硬件能力上體驗都是非常好的，但是他的動態性就變得非常的弱了。

我們沒有辦法去下發新的Native一些能力，包括甚至去寫一個營銷組件，這樣的方式也是做不到的。由此我們再找移動端早期的時候，為了引用重大問題，我們第一想到的就是Html5的方案。他的話是基于WebView的這么一個技術棧，然后把前端的頁面寫進來。同時為了和Native這邊進行交互，我們介入了當時講了非常多的一個叫JsBridge的一些組件，IOS的JsBridge和安卓的JsBridge規律。基于兩套的JsBridge的方案，我們可以跟Native之間的能力進行打通，打通之后我們能獲得一些簡單的交互上的簡單的交互和復雜的運營的能力。

比如說這個時候我們需要動態的下發一個運營頁面，那么我們可以使用Html的寫一個Html的網頁，然后把它發布到我們的平臺上，然后這時候下發到Native端，快速的去渲染出這樣的頁面。在隨著 Html5技術的發展，我們開始去思考能否使用Html這種DSL去寫，Html去寫一些我們想要的東西。在當時那個階段的話，我們就產生了像React-JS、React-Native這種這種方案。

然后React-Native是使用React的DSL然后去渲染出Native的組建的這么方案。對于我們來說，首先是需要對于Native來說是需要學習前端開發的一些語言，但是他因為能使用前端開發的語言，繞過WebView同時又提供了一些動態化的能力，所以它的實際體驗起來是像是與Native一樣流暢。但是在這個問題上，又因為他為了兼容兩端的特性，所以導致了他在處理的過程中有發生了非常多的問題，那么我們在這種問題的解決方案上投入非常多的精力，但是解決起來同時也不是非常的順手。但是他的動態性卻是我們非常看重的一個東西，因為首先它基于它的前端的和模型精簡成了一個就flex這么一種模型。然后拋棄了原先的一些layout的一些系統的layout的管理工具。所以在這種階段上，RN是我們延伸出了非常多方案，淘寶這邊也有像Weex這樣的一個方案，然后最近Google發布了Flutter這個方案，其實算是徹底顛覆了原先的Native的開發模式。其實它對于我們來說，全從頭到腳都是新的。

像在Android上在IOS上都是基于canvas的一個從Native的角度去看，它是基于canvas的方案，他在canvas上進行繪制，然后同時去接管canvas的一些事件，然后在他自己的一個單引擎上去進行執行一些渲染的動作和響應，響應用戶交互的一些請求。對Flutter來說的話，首先我們要去學習它的dart語言，這是第一個成本。dart語言學完之后，我們還要去了解它整個Flutter引擎的工作流，這是第二個成本。之后，它對于動態性的支持，從官方正式的層面來說，目前是處于一種放棄的狀態。它并不打算說有動態下發的一種能力，它基于skia引擎的方案，skia因為是一個性能良好的渲染引擎，所以它的用戶體驗也是非常不錯。這是我們這4種能力的一個差別，這里是4個能力的對比。我們看一下，基于H5的一個方案的話，提供了這么一個容器加離線包的一個架構。

在傳統的H5頁面里面，我們只是一個在客戶端本身接了一個WebView，然后提供了幾個JS的API，往后希望我們的html頁面再下載到我們本地的時候，既能跟服務端進行通信，又能獲得一些本地的能力。但是我們知道它的渲染性能，還有像首屏的白屏那種問題都是沒有解決的，所以說我們為了解決這些問題，使得它的體驗更加靠近native體驗的時候，我們就提供了其當前的這種架構。我們在這邊使用，首先第1個解決的問題是在Android上使用UC內核的這么一個方案，因為uc內核對于我們來說，他能去鋪平各個不同Android的版本，各種不同機型上的外部必有的差異的一些問題，這是我們前端領域中最容易碰到的一個瀏覽器的兼容問題。

我們在解決這個問題的基礎之上，希望賦予容器更多的能力，我們首先要去統一掉容器的JS bridge的性能。這是當中這一層，第3層綠色的這一層的方案。我們在這一層去鋪平之后，那么對于前端來說，他只剩下他的業務細節和具體的業務流程。我們的容器有包含了一個離線包的拉取，離線包對于我們來說是一個解決首屏渲染問題最大的一個抓手。我們使用把離線包的整個能力去集合在容器里面的時候，搭配我們的像MDS的一個我們這邊叫做MDS的一個發布平臺。

搭配發布平臺的話，我們就能很快的發布我們的離線包到用戶的手機上，那么在用戶去打開我們頁面的時候，并不需要過多的時間就可以快速的打開我們的頁面。那么離線包的發布和離線包的更新都在我們的管控之下。同時我們可以基于一些算法，快速的先去預測用戶是否需要快速的打開這項業務，如果需要打開這樣業務，可以提前傳到用戶的手機上，然后用戶在打開業務的時候，就能快速的使用離線包了。

然后在容器以下的這幾層的話，我們跟原先的Native的能力做了一層打通，就是封裝了相同的一些API接口，比如像網絡、多媒體，Push。然后容器本身是可以快速升級的。我們在下發的過程中，可以把最新的優勢內核給分發到用戶的手機上，用戶可以無感知的升級它的uc內核，去體驗最新的一些功能。那么在這之上，我們把每一個的業務叫做一個應用。

那么我們這里面有ABCD比如說到N個業務，那么每一個應用都是在我們這都是一個業務級的概念。那么業務和業務之間是挺隔離的，在隔離的情況下，我們就可以很好的對發板和rollback做一層控制，這樣子就能更好的控制故障的發生。整個H5的應用的啟動流程的話，我們大概有分為這么好幾層。首先的話，他的入口部分可以使用URL，或者說Native的一些按鈕去啟動。那么對于我們每個H5的應用來說，我們都給他都給它抽象成一層叫做APP的概念。

在入口的地方，我們可以傳入一些我們啟動的參數，然后傳給我們的H5的容器叫做Nebula。那么啟動了應用之后，我們這里面就會有一些像框架的生命周期的回調。MicroAPP的話對我們來說就有 onLaunch,onStart,onStop之類的生命周期的回調。那么Native這一層的話，像Android的這邊就會有一個Activity像跟Manager和Fragment之間的被調用，然后調用完之后就會創建一個頁面，這個頁面的話就是我們的H5的容器的頁面，然后它會有一些像腳本加載，像我們內置寫的一些插件的加載，比如說你要對于一些請求，對一些業務的指標做一層監控的話，在這邊寫一個插件是一個非常不錯的選擇。

我們對于外部的容器做的更多的事情，是希望我們的Native和外部之間有暢通的通信通道。在這里的話，我們演示PPT里面講的就是一個JS Bridge概念。我們Native會使用EvaluateJavascript的方式，把JS的代碼傳到外端，web的這邊會使用console的一些消息，把消息發回到Native這邊，我們希望把web的體驗做到一個極致，web體驗無非是幾個概念，首先是一個首頁的加載問題，然后是不同平臺之間的差異問題。最后是一些離線資源的緩存的問題，那么在這些問題之上，我們提供了這么多的解決方案。

首先第一點，我們把網絡請求這一塊的東西，從WebView的那一層去提煉到我們的Native的那層，因為我們native對于網絡有更好的一些能力，比如說我們可以使用除了HTTP和websocket之類的協議以外，做一些其他的協議的構建，那么同時也解決了一些跨越的問題。因為 APP是受我們管控的，所以說我們對于訪問的域名也可以做一些管控。那么在這個基礎上，我們就可以解決一個前后端分離的問題。頁面資源的話可以提早的去加載，那么對于前端來說，前端只關心了他的業務數據的溝通。

第二點的話，我們提供了一個差量更新的一個能力，差量更新的概念是什么？比如說我這次去下發了一兆的離線包，然后我發現以離線包里面有一些bug，那么對它做了一個修復，比如說發布了一點1.0.1版本，那么兩個離線包的改動可能非常的小，比如說只有一個字符串改動或者說幾行代碼的改動，這個時候就可以使用差量更新去把只有改動的部分提交到我們的MDS發布平臺，那么MDS會在合適的時機把這一部分差量的數據量下發到我們的端上，那么端上根據差量就可以自動合并出一個新的離線包。

那么，用戶在下次打開的時候，你的離線包已經被更新了，那么這個過程既可以使得流量的使用量變得很小，同時又能快速的響應業務端的需求。

第三點我們講的是一個推拉結合的概念，其實還是蠻有意思的一個點。因為我們在傳統的HT模型里面，我們永遠是一個拉的概念，我在客戶端提起這request，然后服務端去返回response，當然http2的話是有了serverpush的一個概念，那么我們不是說是在serverpush上做了一個加強，我們本身有一個組件叫做sync，對于mPaaS平臺來說，它就是一個穩定的長連接。那么，那么服務端可以通過長鏈接、提前的向端上去發一些想要的東西，比如說提前去發送離線包這樣的概念，或者說其他的一些數據，特別是基于事件的一些數據。

然后第四點的情況就是當我們的離線包發布如果失敗的情況下，我們可以設置一個fallback走線上的一個流程。這個流程的話是防止我們的離線包下載失敗的時候所做的事情，這一點是為了做正確性的事情。然后一個是我講過的獨立瀏覽器內核的問題，可能在之前我們遭遇的情況比較多一點，現在的我們這邊的話支持的版本還是在4.3, 4.4以上，還會存在一些問題，那么我們的離線包，我們的UC WebView是實時動態更新的，他并不跟著安卓系統走，所以我們提早下發的更新可以幫助用戶更好的去穩定他們離線包的體驗和減少前端bug的產生。

后面一點的話，我們講的是一些深度自定義的組件，這一塊的話，我們有提供了Ant Design之類的一些方案，可以讓用戶快速的介入去構造一個頁面。那么最后一點是監控。其實監控是在這邊最枯燥乏味，但是是最重要的一個環節。因為我們需要對于業務穩定性和本身的業務點做一些監控，那么這些監控做完之后，我們就可以快速的響應用戶的需求，去解決用戶碰到的一些問題，同時我們可以收集一些運營的數據，然后對下一次產品的改進和bug修復做提供非常有效的幫助。

我們H5的容器包含了非常巨大的擴展性，我們首先提供了一些JS的API，可以使H5的代碼有調用，Native的能力在前面已經說過了。他不僅是一些普通的能力，還包括像數據存儲、全球廣播，然后還能自定義的擴展API，然后我們在Nebula容器上提供了一些容器的插件，容器插件的話，它是基于事件去響應的，我們在這邊H5里面有提供了一系列的容器上的生命周期，那么當生命周期回調響應的時候，我們就可以在插件中收到這塊生命周期的事件。

那么，基于這個事件，我們可以去做出各種各樣功能，然后開關這一塊其實是做ABTest之類的需求是最好用的一塊功能。那么我們可以在特定的條件下做一些開關的配置，比如說以人群，以機型，地域之類的方式去做這些開發配置，那么我們可以給特定的地域、特定的人群做提前的灰度，或者說AB的能力。我們的H5的容器最顯著的一個特性，是要比原生的WebView的穩定性要高出很多。這邊我們有兩個指標，一個是PV的崩潰率，一個是PV ANR的概率，那么崩潰率就是Crash率，那么我們這邊的話比傳統的容器要高一倍以上，那么ANR的概念就是你在劃的過程中卡死的概率，我們這邊主要核心解決的兩個問題，是WebView穩定性和WebView體驗不一致的問題。

Part2：監控 發布平臺，滿足業務穩定運行、快速迭代

然后講一下我們的監控和發布平臺，因為這塊是圍繞著我們H5容器的生態，需要去做到的一個非常大的后端能力。首先第一點，我們需要有快速發布的能力，因為我們知道基于原生的H5頁面，其實它是本身就具有實時發布的，實時發布的概念就是你自己如果擁有一臺服務器，那么你去發布你的前端頁面的時候，它是實時更新的。如果使用離線包的話，他的確是喪失一些快速發布的能力，但是我們在這里需要把快速發布的能力給他補償回來。

所以我們首先去接入我們的MDS的時候，我們的離線包首先是發布的MDS上，那么MDS會根據你之前配置的一系列的東西，去把我們的離線包發布到CDN上，然后根據我們之前客戶端上的一些條件，比如說你是否打開了灰度開關，或者說是全網Release，如果是灰度開通開關的話，還需要根據你灰度的一些配置，然后通過客戶端和服務端這些客戶端和MDS之間的一些請求，然后把我們的離線包的地址下發到客戶端上，那么客戶端會拿到這個地址，從CPN上把我們的離線包下載過來，這是我們的提供的一個快速發布的能力。那么快速發布既要擁有智能灰度的能力，同時也需要提供增量拆分離線包的能力，這個能力對于客戶來說是不可見的。因為客戶只用把兩個版本的離線包上傳到我們的服務端，我們服務端自動會算出這兩個離線包之間的差異，然后把差異下發到客戶端，我們同時需要保證我們的MDS的性能需要達到非常高的要求。那么我們的MDS的性能QPS可以達到5萬每秒，那么對于端的一個觸達率有達到99.99%。

然后接下來講的是一個監控和診斷，那么監控其實是我們一個非常需要重點關注的維度，因為我們把業務開發完畢，去下發到用戶端的時候，如果用戶體驗非常不好的話，那么我們的留存率是非常低的。所以說我們需要針對于閃退、流暢度、電量，流量之類的，還有不可用的一些一些業務都需要做一些埋點。我們去埋點之后，就是收集完用戶的一個使用情況的時候，我們需要去上報。那么如果做到實時上報的話，這個上報的策略其實是不合理的。

因為第一會影響用戶的體驗，因為實時上報的話，我們可能一直開著一個進程，或者說還有一條線程去上報。第二，對于用戶的流量也會有非常大的影響。那么同時我們還需要考慮用戶在使用我們APP過程中的一個的情況，比如說做一些定制化的開關，或者說需要做一些特殊的一些采樣。比如說如果這個時候一個用戶跟我們去報他使用APP的過程中產生的Crash，那么我們并不需要收集全網Crash情況，因為用戶他自己的使用場景可能會比較特別，所以說我們需要有對于特定的用戶有一個固定抓取的能力。

然后我們上報的方式有有三種，第一種就是自動上傳，第二種是周期性的檢查上傳，比如說每隔一小時或者每隔一天。第三點是診斷指令驅動的上傳，這個意思就是我剛剛說的一個場景，一個用戶報Crash了，那么我們需要用戶比如說上報一下他的郵箱，或者說賬號名字之類的，那么我們可以精準的在用戶手機上去抓取一段日志。那么我們根據用戶上傳的一些日志，我們可以進行進行頁面的一個跳轉路徑的分析，然后還有APP自己產生的一些日志做一些分析，那么分析完之后，我們就可以做出一些決策，比如說該怎么優化這些東西，那么如果我們的Crash去和ANR的率到達了一定程度的時候，我們需要有熔斷的一些措施，比如說把離線包的頁面或者禁用掉，那么或者說走fallback，或者走修復這三個流程。

這個是我們提供的四個能力。首先第一點的話是故障隔離，就是說如果我們發現這個頁面產生了一個故障的話，我們需要提前的去開啟某個開關，如果它是一個新業務的話，比如說他開關是開著的情況下，我們需要立即把它關掉，然后屏蔽掉之后，進行一個止血的過程。

那么第二點，如果我們的閃屏頁面發生過程，因為這個時候用戶可能進不了我們的APP,那么需要我們去進一個安全模式，這個時候需要對安全模式里面的一些數據進行一些診斷上傳。然后把我們的APP里面的一些數據清除掉，然后再重新開啟。這個是一個自動恢復的能力。

第三點，我們是需要進行一些流量的熔斷，比如說我們的網絡調用到達一定請求或者說一定程度大概率是出現在比如說我們這邊的服務器或者說客戶這邊的APP端業務端受到一個DDOS的一個場景，那么這個時候我們需要對流量做聲做成一個熔斷。

第四點就是我們一個非常重要的動態化能力的修復。那么這里面包含了好幾個內容，第一點是剛才之前說的開關。第二點是離線包的一個版本更新，我們比如說前面的離線包發生了一些問題，那么我們需要及時的修復、去上傳，然后快速的全網發布。然后第三點是基于原生代碼的一個Hotpatch，那么安卓上的Hotpatch的話，我們還是使用的是DexPatch的方案，那么能修復Native上的Java代碼，然后他同時可以做到監控，可以回滾，在我們的mPaaS后臺去點擊一個回滾的按鈕，那么我們快速的把這幾個下發的新的東西做一個回滾，因為誰也沒辦法去保證自己下次寫的代碼沒有bug。

所以說只要我們如果驗證沒有問題，那么我們的修復可以發放，如果說熱修復是有問題的，那么我還要做到一個快速回本，去發一個新的Patch，那么對于我們來說的話，我們的Native發板可能會做得比較慢，那么如果在我們上了H5的方案之后，那么我們H5的發版肯定是比Native的發版要走得快的。假設說我們在一個APP里面有N個產品，那么他們之間的發展節奏像是這個樣子，那么他們的整個產品的一個生命周期是左邊的一個環形的架構，其實還是蠻傳統的一個交流，首先的話是業務這邊去制定目標，然后開發這邊進行代碼構建，然后我們進行一個灰度持續的監控，最后正式發布完之后，我們進行一個運維的監控，運維監控之后，我們再做一個灰度的驗證，然后制定一個新的目標。

對于不同的版本的話，這里面重點講的是一個灰度的概念。對于灰度來說，我們需要知道用戶這邊的一些條件，比如說我們這次需要做一個基于安卓手機的性能優化的方案，那么我們需要去用條件去篩選出我們安卓里面，比如說CPU是驍龍600系列或者500系列的一個低端的CPU的話，然后去驗證我們的這一次的性能修復的包的表現。

Part3：更優異的 Hybrid 方案，HTML5 與小程序差異化解析

我們這邊需要去講一下最近非常火的小程序的方案，小程序是在H5發解決方案之上更加升級的一個架構。

首先小程序是一個基于Web技術，然后又集成了原生能力的一個新的移動應用格式。那么對于小程序來說，跟H5一個最大的不同是H5本身其實是技術是開放的，但小程序就等于是給了一套完整的開發框架。那么你繼續跟著開發框架和DSL編寫出了相應的業務代碼之后，然后編譯成一個小程序的包，然后發到相應的平臺上，平臺可以根據你這一套DSL去渲染出它的一個頁面，當然它的渲染引擎是可以隨時更換的，不一定是WebView的渲染引擎，他比如說可以根據 skia的渲染進去寫一套基于skia渲染去做。那么小程序的優勢有四種，一個是獲取便捷，比如說掃二維碼就能直接去打開，他不需要你去架設服務器，不需要去考慮CDN之類的一些東西。第二個就是小程序和小程序鏈接的一個能力。然后還有小程序跟Native之間的一些連接的能力。第三個的話小程序的安全性和可靠性是由各個大平臺去保障。第四點小程序的渲染，它是由你各個去指定的標簽去決定的，比如說我可以使用原生的組件去渲染小程序上一些DSL的組建，在這種情況下，它的渲染能力反而是會比H5的渲染能力會更高一點。那么整個小程序的架構是像圖上這樣子，小程序的渲染層和邏輯層是徹底分開的。

大家可以認為渲染層里面是有一個WebView有選擇，那么渲染才是WebView，那么實際上它的一些事件執行，像一些邏輯的執行，是開了另外一個JS引擎去做這個事情。那么它們之間通過Native層的一層JS Bridge進行通訊，那么每次邏輯層把需要更改的配置的一些信息去成立到Native層，Native層獲取到渲染層里面已經渲染了的DOM信息，然后計算出差分邏輯，最后下發到我們的渲染層。那么渲染成每次去更新UI的時候，都是會把差異化的一些數據把它給渲染出來。那么在這種情況下，我們的渲染層和邏輯層之間的執行是完全隔離的，這個是我們所講的小程序雙線程的一個概念。同時小程序因為有平臺的容器作保障，所以說我們這邊能快速的打通Native層的一些存儲網絡多媒體的能力。在這種情況下，我們使用小程序開發的時候，可以用最少的成本去開發出性能最好，動態能力最強的一個框架。

那么同時我們小程序提供了一個ID構建和發布的一個能力，ID構建的話，我們現在支付寶這邊有提供小程序的IDE，同時開發支付寶小程序，淘寶小程序，還有mPaaS小程序，它們三者之間雖然技術架構不太一樣，但是它們之間的DSL是相同的，你可以使用同一套代碼去開發。那么Native這一層，首先先對你傳遞的參數做一層解析，解析完之后去提前加載小程序的資源，然后去創建一個渲染頁面，比如說這里面Render我講了，目前來說是基于UC WebView，但是它同時也可以不基于UC WebView，這個對于業務來說是完全沒有感知的，那么在渲染層初始化完畢之后，我們這邊會創建了一個JS的worker，那么這個worker就是我們剛剛講的邏輯層的一個概念。worker創建完之后，會對于原先小程序里面執行的小程序JS代碼里面執行的一些事件做監聽，那么會回到小程序里面的一些事件的callback，然后小程序的JS引擎里面，對于業務代碼層面上對這些callback做出一些響應，比如說Set Data之類的回調。調完之后，會傳遞到Native這一層，Native這一層把原先去更改的一些數據傳遞給渲染成層，然后渲染層在下一次事件循環中，把這次傳的數據做一個差分的渲染，然后做完之后，我們就能看到我們想要的一個產品，那么這個就是我們剛說的小程序的雙線程的概念。邏輯上在worker這邊，然后渲染層在Render這邊。

小程序的特征是非常規范的提供了這么幾個能力，首先第1個包體的構造是在一個標準要求之下的，我們必須提供這樣的一個包體的結構，然后UI組件和API是另外提供的一個能力，然后入口規范的情況下，我們能快速的把我們小程序的內容和小程序的整體的頁面的管控，收斂到一個比較小的口子上,那么能最大的防止各種風險。

同時它的安全和隱私的管控，在于我們的Native的容器里面已經包裝好了，比如說小程序想獲得一些隱私相關權限的時候，需要我們的Native這邊在UI層面上作出一些響應，比如說想要獲得用戶定位的能力，或者說想去獲得用戶的手機號，這些東西我們都需要在Native這一層去向用戶去申請權限。然后同時我們又提供了一些小部件，小部件到是一個可以認為是插件，或者說是像UI組件這樣的一個東西。

然后我們的小程序的整個生態，目前來說，支付寶的mPaaS小程序有在各個地方都使用，比如說像餓了么、高德，淘票票之類的東西都在用。

在這種情況下，我們把我們整個小程序能力做了一個封裝，通過mPaaS的一個方式去去分發給各個用戶。那么用戶去集成了我們mPaaS的容器之后，也能基于這一套生態去開發出自己想要的小程序，然后在自己的APP上進行運行。我們希望我們正常開放的生態環境，希望能讓用戶因為小程序而受益。然后也能擁有自己的一個動態化能力。我們希望能提升用戶的粘性，然后連接海量的服務，然后服務的話，希望能快速的觸達到多端。

然后我們mPaaS是支付寶里面整合出了一套完整的引擎，那么我們mPaaS就提供了好幾種從服務端到客戶端的完整方案，那么對于客戶端來說，有提供客戶端的SDK和客戶端的框架。那么，客戶端和服務端之間的連接，通過我們自定義 RPC協議，包括推和拉結合，推的話，剛剛說的Sync組件，拉的話我自定義的HTPR的一些協議，那么mPaaS的中臺還有提供網關，然后把用戶的一些行為數據進行分析，然后還有消息推送，然后發布，還有開關等等。

后端的mPaaS的話是有一些計量計費的管控，然后多租戶的管控，這一塊是我們這邊自己的一些能力。然后整體的話我們mPaaS現在是基于阿里云去做的。

目前，mPaaS已經上架到了阿里云對外輸出了，歡迎大家試用。