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

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

　　我們?cè)谶@邊，首先要介紹的一個(gè)點(diǎn)是彈性動(dòng)態(tài)端的能力。首先我們?cè)谥Ц秾氈忻媾R的一些問(wèn)題是有海量的業(yè)務(wù)，然后傳統(tǒng)方面上的一些Hybrid方案，這是一個(gè)老生常談的話題了。然后第二個(gè)是高可用和及時(shí)快速發(fā)布的監(jiān)控運(yùn)維體系，這里面包含了像局部條件、灰度的能力，然后快速回滾的能力和快速迭代的一些能力。然后第三點(diǎn)就是開放出來(lái)我們的Hybrid的一些解決方案。

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

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

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

　　我們沒有辦法去下發(fā)新的Native一些能力，包括甚至去寫一個(gè)營(yíng)銷組件，這樣的方式也是做不到的。由此我們?cè)僬乙苿?dòng)端早期的時(shí)候，為了引用重大問(wèn)題，我們第一想到的就是Html5的方案。他的話是基于WebView的這么一個(gè)技術(shù)棧，然后把前端的頁(yè)面寫進(jìn)來(lái)。同時(shí)為了和Native這邊進(jìn)行交互，我們介入了當(dāng)時(shí)講了非常多的一個(gè)叫JsBridge的一些組件，IOS的JsBridge和安卓的JsBridge規(guī)律。基于兩套的JsBridge的方案，我們可以跟Native之間的能力進(jìn)行打通，打通之后我們能獲得一些簡(jiǎn)單的交互上的簡(jiǎn)單的交互和復(fù)雜的運(yùn)營(yíng)的能力。

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

　　然后React-Native是使用React的DSL然后去渲染出Native的組建的這么方案。對(duì)于我們來(lái)說(shuō)，首先是需要對(duì)于Native來(lái)說(shuō)是需要學(xué)習(xí)前端開發(fā)的一些語(yǔ)言，但是他因?yàn)槟苁褂们岸碎_發(fā)的語(yǔ)言，繞過(guò)WebView同時(shí)又提供了一些動(dòng)態(tài)化的能力，所以它的實(shí)際體驗(yàn)起來(lái)是像是與Native一樣流暢。但是在這個(gè)問(wèn)題上，又因?yàn)樗麨榱思嫒輧啥说奶匦裕詫?dǎo)致了他在處理的過(guò)程中有發(fā)生了非常多的問(wèn)題，那么我們?cè)谶@種問(wèn)題的解決方案上投入非常多的精力，但是解決起來(lái)同時(shí)也不是非常的順手。但是他的動(dòng)態(tài)性卻是我們非常看重的一個(gè)東西，因?yàn)槭紫人谒那岸说暮湍Ｐ途?jiǎn)成了一個(gè)就flex這么一種模型。然后拋棄了原先的一些layout的一些系統(tǒng)的layout的管理工具。所以在這種階段上，RN是我們延伸出了非常多方案，淘寶這邊也有像Weex這樣的一個(gè)方案，然后最近Google發(fā)布了Flutter這個(gè)方案，其實(shí)算是徹底顛覆了原先的Native的開發(fā)模式。其實(shí)它對(duì)于我們來(lái)說(shuō)，全從頭到腳都是新的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　然后講一下我們的監(jiān)控和發(fā)布平臺(tái)，因?yàn)檫@塊是圍繞著我們H5容器的生態(tài)，需要去做到的一個(gè)非常大的后端能力。首先第一點(diǎn)，我們需要有快速發(fā)布的能力，因?yàn)槲覀冎阑谠腍5頁(yè)面，其實(shí)它是本身就具有實(shí)時(shí)發(fā)布的，實(shí)時(shí)發(fā)布的概念就是你自己如果擁有一臺(tái)服務(wù)器，那么你去發(fā)布你的前端頁(yè)面的時(shí)候，它是實(shí)時(shí)更新的。如果使用離線包的話，他的確是喪失一些快速發(fā)布的能力，但是我們?cè)谶@里需要把快速發(fā)布的能力給他補(bǔ)償回來(lái)。

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

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

　　因?yàn)榈谝粫?huì)影響用戶的體驗(yàn)，因?yàn)閷?shí)時(shí)上報(bào)的話，我們可能一直開著一個(gè)進(jìn)程，或者說(shuō)還有一條線程去上報(bào)。第二，對(duì)于用戶的流量也會(huì)有非常大的影響。那么同時(shí)我們還需要考慮用戶在使用我們APP過(guò)程中的一個(gè)的情況，比如說(shuō)做一些定制化的開關(guān)，或者說(shuō)需要做一些特殊的一些采樣。比如說(shuō)如果這個(gè)時(shí)候一個(gè)用戶跟我們?nèi)?bào)他使用APP的過(guò)程中產(chǎn)生的Crash，那么我們并不需要收集全網(wǎng)Crash情況，因?yàn)橛脩羲约旱氖褂脠?chǎng)景可能會(huì)比較特別，所以說(shuō)我們需要有對(duì)于特定的用戶有一個(gè)固定抓取的能力。

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

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

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

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

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

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

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

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

　　我們這邊需要去講一下最近非常火的小程序的方案，小程序是在H5發(fā)解決方案之上更加升級(jí)的一個(gè)架構(gòu)。

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

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

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

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

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

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

　　在這種情況下，我們把我們整個(gè)小程序能力做了一個(gè)封裝，通過(guò)mPaaS的一個(gè)方式去去分發(fā)給各個(gè)用戶。那么用戶去集成了我們mPaaS的容器之后，也能基于這一套生態(tài)去開發(fā)出自己想要的小程序，然后在自己的APP上進(jìn)行運(yùn)行。我們希望我們正常開放的生態(tài)環(huán)境，希望能讓用戶因?yàn)樾〕绦蚨芤妗Ｈ缓笠材軗碛凶约旱囊粋€(gè)動(dòng)態(tài)化能力。我們希望能提升用戶的粘性，然后連接海量的服務(wù)，然后服務(wù)的話，希望能快速的觸達(dá)到多端。

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

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

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