含ppt下載|解析支付寶移動端彈性動態架構

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

今天，將爲你們分享圍繞支付寶在移動端如何實現輕耦合、彈性動態的開發模式，深度解析其技術選型及實戰經驗。演講嘉賓是來自螞蟻金服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獲取地址：https://files.alicdn.com/tpsservice/45b8e88badbc2a652216ec49d0740811.pdf