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

今天，將為大家分享圍繞支付寶在移動端如何實現輕耦合、彈性動態的開發模式，深度解析其技術選型及實戰經驗。演講嘉賓是來自螞蟻金服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已經上架到了阿里雲對外輸出了，歡迎大家試用。

PPT獲取地址：