近日，螞蟻金服開展了“共戰‘疫情’，技術破局”數字課堂線上直播，我們將系列演講整理併發布在 “螞蟻金服科技” 公眾號上。
今天，將為大家分享圍繞支付寶在移動端如何實現輕耦合、彈性動態的開發模式，深度解析其技術選型及實戰經驗。演講嘉賓是來自螞蟻金服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已經上架到了阿里雲對外輸出了，歡迎大家試用。
閱讀更多 螞蟻金服科技 的文章
