長沙APP開發(fā)公司教您如何快速開發(fā)一款A(yù)PP?今天，智企云為大家分享圍繞支付寶在移動端如何實現(xiàn)輕耦合、彈性動態(tài)的開發(fā)模式，深度解析其技術(shù)選型及實戰(zhàn)經(jīng)驗，長沙APP開發(fā)公司智企云至始至終都是保持著一顆永久學習的心，今天為大家整理學習的是來自螞蟻金服mPaaS客戶端核心開發(fā)的溫盛章，以下為演講整理全文：我們提供了一個移動開發(fā)平臺叫做mPaaS，現(xiàn)在在阿里上面已經(jīng)正式的發(fā)布了。他首先是源自于我們支付寶的一個移動端的組件，目的是為了打造快速迭代的架構(gòu)和動態(tài)化的能力。它是一整套的方案，包括了移動端的開發(fā)SDK，然后移動端的構(gòu)建工具和后端的一整套的服務(wù)和工具作為一個整體體系的產(chǎn)品。我們主要要做的事情是使用移動開發(fā)平臺mPaaS來打造一個性能更優(yōu)的APP。今天我們在這邊直播分享的內(nèi)容是，支付寶使用mPaaS的過程中的一些動態(tài)化的實踐。

　　彈性動態(tài)的端上架構(gòu)解析

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

　　Part1：利用 Hybrid 架構(gòu)應(yīng)對海量業(yè)務(wù)需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　Part2：監(jiān)控+發(fā)布平臺，滿足業(yè)務(wù)穩(wěn)定運行、快速迭代

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

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

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

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

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

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

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

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

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

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

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

　　Part3：更優(yōu)異的 Hybrid 方案，HTML5 與小程序差異化解析

　　我們這邊需要去講一下最近非?；鸬男〕绦虻姆桨?，小程序是在H5發(fā)解決方案之上更加升級的一個架構(gòu)。

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

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

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

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

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

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

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

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

　　后端的mPaaS的話是有一些計量計費的管控，然后多租戶的管控，這一塊是我們這邊自己的一些能力。然后整體的話我們mPaaS現(xiàn)在是基于阿里云去做的。目前，mPaaS已經(jīng)上架到了阿里云對外輸出了，歡迎大家試用。

      以上就是長沙APP開發(fā)公司智企云為我們整理學習的學習圍繞支付寶在移動端如何實現(xiàn)輕耦合、彈性動態(tài)的開發(fā)模式！的相關(guān)介紹，智企云一直保持著學習目前APP開發(fā)的最新技術(shù)的關(guān)注，這樣才能利用技術(shù)開發(fā)出最好的產(chǎn)品來服務(wù)到客戶，降低相應(yīng)的成本，后續(xù)我們將持續(xù)為大家?guī)黻P(guān)于APP開發(fā)方面最前沿流行的相關(guān)技術(shù)的報道，敬請關(guān)注！