1. MTFlexbox

MTFlexbox是美團(tuán)內(nèi)部應(yīng)用的非常成熟的一種跨平臺(tái)動(dòng)態(tài)化解決方案，它遵循了CSS3中提出的Flexbox規(guī)范來(lái)抹平多平臺(tái)的差異。MTFlexbox適用于重展示、輕交互的業(yè)務(wù)場(chǎng)景，與現(xiàn)有HTML、React Native、Weex等跨平臺(tái)方案相比，MTFlexbox具備著性能高、渲染速度快、兼容性高、原生功能支持度高等優(yōu)勢(shì)。但其缺點(diǎn)在于不支持復(fù)雜的交互邏輯，不適合復(fù)雜交互的業(yè)務(wù)場(chǎng)景。目前，MTFlexbox已經(jīng)廣泛應(yīng)用在美團(tuán)首頁(yè)、搜索、外賣(mài)等重要業(yè)務(wù)場(chǎng)景。本文主要介紹在MTFlexbox中使用Litho優(yōu)化性能的實(shí)踐經(jīng)驗(yàn)。

1.1 MTFlexbox的原理

MTFlexbox首先定義一份跨平臺(tái)統(tǒng)一的DSL布局描述文件，前端通過(guò)“所見(jiàn)即所得”的編輯器編輯產(chǎn)生布局，客戶(hù)端下載布局文件后，根據(jù)布局中的描述綁定JSON數(shù)據(jù)，并最終完成視圖的渲染。MTFlexbox框架圖如下圖所示：

圖中分為五層，分別是：

• 業(yè)務(wù)應(yīng)用層：業(yè)務(wù)使用MTFlexbox的編輯器定義符合Flexbox規(guī)范的DSL文件（XML模版）。
• 模版下載：負(fù)責(zé)XML模版下載相關(guān)的工作，包括模版緩存、預(yù)加載和異常監(jiān)控等。
• 模版解析：負(fù)責(zé)模版解析相關(guān)的工作，包括標(biāo)簽節(jié)點(diǎn)的預(yù)處理、數(shù)據(jù)綁定、標(biāo)簽節(jié)點(diǎn)的緩存復(fù)用和數(shù)據(jù)異常監(jiān)控等。
• 視圖渲染：負(fù)責(zé)視圖渲染相關(guān)的工作，包括把標(biāo)簽結(jié)點(diǎn)按照Flexbox規(guī)范解析成Native視圖，并完成視圖屬性的設(shè)置、點(diǎn)擊曝光事件的處理、視圖渲染、異常監(jiān)控等。
• 自定義標(biāo)簽擴(kuò)展：提供支持業(yè)務(wù)擴(kuò)展自定義標(biāo)簽的能力。

鑒于本篇博客主要涉及渲染相關(guān)的內(nèi)容，下面將著重介紹MTFlexbox從模版解析到渲染的過(guò)程。如下圖所示，MTFlexbox首先會(huì)把XML模版解析成Java中的標(biāo)簽樹(shù)，然后和JSON數(shù)據(jù)綁定結(jié)合成一顆具有完整數(shù)據(jù)信息的節(jié)點(diǎn)樹(shù)。至此，模版解析工作就完成了。解析完成的節(jié)點(diǎn)樹(shù)會(huì)交給視圖引擎進(jìn)行Native視圖樹(shù)的創(chuàng)建和渲染。

2. MTFlexbox在美團(tuán)動(dòng)態(tài)化實(shí)踐中面臨的挑戰(zhàn)

隨著MTFlexbox在美團(tuán)內(nèi)部被廣泛使用，我們遇到了兩個(gè)問(wèn)題：

• 復(fù)雜視圖因?qū)蛹?jí)過(guò)深，導(dǎo)致滑動(dòng)卡頓問(wèn)題。
• 生成視圖耗時(shí)過(guò)長(zhǎng)，導(dǎo)致滑動(dòng)卡頓問(wèn)題。

2.1 問(wèn)題一：視圖層級(jí)過(guò)深

2.1.1 原因分析

MTFlexbox使用的是Flexbox布局，Flexbox布局可以理解成Android LinearLayout布局的一種擴(kuò)展。Flexbox在布局過(guò)程中使用到大量的布局嵌套，如果布局酷炫復(fù)雜，無(wú)疑會(huì)出現(xiàn)布局層級(jí)過(guò)深、視圖樹(shù)遍歷耗時(shí)、繪制耗時(shí)等問(wèn)題，最終引發(fā)滑動(dòng)卡頓。下圖是美團(tuán)正在使用的一個(gè)模版的視圖層級(jí)情況（布局最深處有8層）：

2.1.2 影響

布局層級(jí)過(guò)深在布局的計(jì)算和渲染過(guò)程中會(huì)導(dǎo)致過(guò)多的遞歸調(diào)用，影響視圖的繪制效率，引發(fā)頁(yè)面滑動(dòng)FPS下降問(wèn)題，這會(huì)直接影響到用戶(hù)體驗(yàn)。

2.2 問(wèn)題二：生成視圖耗時(shí)過(guò)長(zhǎng)

2.2.1 原因分析

視圖生成耗時(shí)原因如下圖所示：RecyclerView在使用MTFlexbox布局條目時(shí)，需要對(duì)條目模版進(jìn)行下載并解析生成節(jié)點(diǎn)樹(shù)，這樣會(huì)導(dǎo)致生成視圖的過(guò)程耗時(shí)過(guò)長(zhǎng)。為了提高視圖生成速度，我們?cè)黾恿藦?fù)用機(jī)制，但是滑動(dòng)過(guò)程中，如果遇到新的布局樣式仍然需要重新下載和解析。另外，MTFlexbox綁定的數(shù)據(jù)是未經(jīng)解析的JSON字符串，所以也要比正常情況下的數(shù)據(jù)綁定更耗時(shí)一些。 正是上面兩個(gè)原因，導(dǎo)致了MTFlexbox生成視圖耗時(shí)過(guò)長(zhǎng)的問(wèn)題，這也會(huì)導(dǎo)致滑動(dòng)時(shí)FPS出現(xiàn)突然下降的現(xiàn)象，產(chǎn)生卡頓感。

2.2.2 影響

由于視圖的創(chuàng)建會(huì)阻塞主線程，創(chuàng)建視圖耗時(shí)過(guò)長(zhǎng)會(huì)導(dǎo)致RecyclerView列表滑動(dòng)時(shí)卡頓感明顯，也嚴(yán)重影響到了用戶(hù)體驗(yàn)。

3. Litho

3.1 Litho原理

Litho是一套聲明式UI框架，或者說(shuō)是一個(gè)渲染引擎，它主要優(yōu)化復(fù)雜RecyclerView列表的滑動(dòng)性能問(wèn)題。Litho實(shí)現(xiàn)了視圖的細(xì)粒度復(fù)用、異步計(jì)算布局和扁平化視圖，可以顯著提升滑動(dòng)性能，減少RecyclerView滑動(dòng)時(shí)的內(nèi)存占用。詳細(xì)介紹可以參考美團(tuán)技術(shù)團(tuán)隊(duì)之前發(fā)布的另一篇博客：Litho的使用及原理剖析。

3.2 Litho的優(yōu)勢(shì)

通過(guò)對(duì)Litho原理的了解，我們可以看到Litho主要針對(duì)RecyclerView復(fù)雜滑動(dòng)列表做了以下幾點(diǎn)優(yōu)化：

• 視圖的細(xì)粒度復(fù)用，可以減少一定程度的內(nèi)存占用。
• 異步計(jì)算布局，把測(cè)量和布局放到異步線程進(jìn)行。
• 扁平化視圖，把復(fù)雜的布局拍成極致的扁平效果，優(yōu)化復(fù)雜列表滑動(dòng)時(shí)由布局計(jì)算導(dǎo)致的卡頓問(wèn)題。

扁平化視圖剛好可以?xún)?yōu)化MTFlexbox遇到的視圖層級(jí)過(guò)深的問(wèn)題。異步計(jì)算布局雖然不能直接解決MTFlexbox生成視圖耗時(shí)過(guò)長(zhǎng)問(wèn)題，但是給問(wèn)題的解決提供了新的思路——異步提前完成視圖創(chuàng)建。而且使用Litho還能帶來(lái)一定程度的內(nèi)存優(yōu)化。所以如何將Litho應(yīng)用到MTFlexbox中，進(jìn)而來(lái)解決MTFlexbox現(xiàn)存的問(wèn)題，是我們解下來(lái)要討論的重點(diǎn)。

4. Litho + MTFlexbox是怎么解決上述兩個(gè)問(wèn)題的？

4.1 解決問(wèn)題一：視圖層級(jí)過(guò)深問(wèn)題

Litho實(shí)現(xiàn)了布局的扁平化，所以最直接的方式就是使用Litho來(lái)替換MTFlexbox現(xiàn)有的視圖引擎。視圖引擎最主要的作用，是把XML文件解析出來(lái)的節(jié)點(diǎn)樹(shù)變成Litho可以展示的視圖，所以視圖引擎替換的主要工作是把節(jié)點(diǎn)樹(shù)轉(zhuǎn)換成Litho能展示的視圖。如下圖所示。由于Litho使用的是組件化思想，需要先把節(jié)點(diǎn)轉(zhuǎn)化成組件，再把組件樹(shù)設(shè)置給LithoView，而LithoView是Litho用于兼容原生View的容器，它負(fù)責(zé)把Litho和系統(tǒng)視圖引擎橋接起來(lái)。

不過(guò)視圖引擎的替換并不是一帆風(fēng)順的，我們?cè)谔鎿Q過(guò)程中也遇到了4個(gè)比較大的挑戰(zhàn)。

難點(diǎn)一：復(fù)用視圖無(wú)法更新數(shù)據(jù)問(wèn)題

問(wèn)題描述：完成了節(jié)點(diǎn)樹(shù)到組件樹(shù)的轉(zhuǎn)化以后，我們發(fā)現(xiàn)了一個(gè)嚴(yán)重的問(wèn)題——復(fù)用的視圖無(wú)法應(yīng)用新的數(shù)據(jù)。

問(wèn)題分析：當(dāng)數(shù)據(jù)發(fā)生變化后，MTFlexbox的節(jié)點(diǎn)樹(shù)會(huì)對(duì)比新舊數(shù)據(jù)的變更，確定哪些結(jié)點(diǎn)需要更新并通知到具體的視圖節(jié)點(diǎn)，然后更新顯示內(nèi)容（例如：新數(shù)據(jù)相比舊數(shù)據(jù)改變了Text，那么只有Text對(duì)應(yīng)的節(jié)點(diǎn)會(huì)通知對(duì)應(yīng)的視圖去更新內(nèi)容）。Litho組件的Prop屬性是不允許更改的，而Litho組件中絕大多數(shù)屬性都是Prop屬性。

解決方案

方案一：使用State屬性全局替換所有組件的Prop屬性。這種方式的優(yōu)點(diǎn)在于替換方式相對(duì)簡(jiǎn)單直接，缺點(diǎn)是侵入性強(qiáng)，替換工作量巨大且不符合Litho的思想（盡可能少的去改變組件的狀態(tài)）。這種方案不是最優(yōu)解，我們要降低侵入，簡(jiǎn)單快捷地實(shí)現(xiàn)數(shù)據(jù)更新，于是就產(chǎn)生了方案二，具體如下圖所示。

方案二：封裝一套Updater組件，用于創(chuàng)建真正展示的組件。Updater組通過(guò)State屬性監(jiān)聽(tīng)對(duì)應(yīng)節(jié)點(diǎn)的數(shù)據(jù)變更，當(dāng)節(jié)點(diǎn)數(shù)據(jù)變化時(shí)，可以觸發(fā)對(duì)應(yīng)節(jié)點(diǎn)的更新。

但在后來(lái)的實(shí)踐過(guò)程中，我們發(fā)現(xiàn)Litho整個(gè)組件樹(shù)中只要有一個(gè)組件有狀態(tài)更新，便會(huì)重新計(jì)算整個(gè)布局，而每次數(shù)據(jù)更新少說(shuō)也會(huì)有幾十個(gè)節(jié)點(diǎn)發(fā)生變化。頻繁的重復(fù)計(jì)算反而導(dǎo)致性能變得很差。在經(jīng)過(guò)了多種嘗試以后，我們找到了最優(yōu)的解決方案：

如上圖所示，狀態(tài)更新控制器負(fù)責(zé)整個(gè)視圖所有節(jié)點(diǎn)的更新操作。在所有數(shù)據(jù)都更新完成以后，統(tǒng)一交由狀態(tài)更新控制器觸發(fā)一遍組件更新。

難點(diǎn)二：Litho不支持層疊布局問(wèn)題

MTFlexbox并沒(méi)有完全嚴(yán)格的使用Flexbox布局規(guī)范，為了簡(jiǎn)單實(shí)現(xiàn)層疊效果，MTFlexbox自定義了一種新布局規(guī)范——Layer布局。Layer布局具有以下兩個(gè)特點(diǎn)：

• 特點(diǎn)一：Layer的子視圖在z軸上依次層疊展示。
• 特點(diǎn)二：Layer的子視圖默認(rèn)且只能充滿(mǎn)父布局。

原因分析：?由于Litho嚴(yán)格遵守Flexbox布局規(guī)范，所以沒(méi)有現(xiàn)成的Layer組件。

解決方案：?自己實(shí)現(xiàn)Layer組件，滿(mǎn)足第一個(gè)特點(diǎn)很容易，Flexbox本身就支持層疊展示，只需要把子視圖設(shè)為絕對(duì)布局就可以了。但是讓子視圖默認(rèn)充滿(mǎn)父布局就沒(méi)有那么簡(jiǎn)單了，Flexbox布局中沒(méi)有任何一個(gè)屬性可以達(dá)到這個(gè)效果。在經(jīng)過(guò)了若干次組合多個(gè)屬性的嘗試以后，還是沒(méi)能找到解決方案。既然Layer并不是Flexbox布局的規(guī)范，那么我們局限在Flexbox的束縛下，怕是很難找到完美的解決方案。那么，能不能在Litho中繞過(guò)Flexbox的約束，自己實(shí)現(xiàn)Layer效果呢？想在Litho中突破Flexbox布局的束縛，就需要了解Litho是如何使用Flexbox的。

如上圖，Litho的Flexbox布局是由Yoga負(fù)責(zé)布局計(jì)算的。每一個(gè)Litho組件都會(huì)對(duì)應(yīng)一個(gè)Yoga節(jié)點(diǎn)。但Yoga的布局計(jì)算過(guò)程是由根節(jié)點(diǎn)去統(tǒng)一觸發(fā)的，子節(jié)點(diǎn)沒(méi)有辦法知道自己對(duì)應(yīng)的Yoga節(jié)點(diǎn)是何時(shí)開(kāi)始計(jì)算，及何時(shí)計(jì)算結(jié)束。這樣以來(lái)，我們就沒(méi)有時(shí)機(jī)去感知到Layer組件的布局是否計(jì)算完成，也就沒(méi)有辦法在Layer組件計(jì)算完成后去控制Layer子節(jié)點(diǎn)的計(jì)算。為了解決這個(gè)問(wèn)題，我們做了兩件事：

• 添加布局計(jì)算完成的回調(diào)，在布局計(jì)算完成后由根節(jié)點(diǎn)逐層通知子節(jié)點(diǎn)計(jì)算完成的消息。
• 拆分Yoga節(jié)點(diǎn)樹(shù)，由Layer自己來(lái)控制子節(jié)點(diǎn)的計(jì)算。

如上圖所示，把Layer組件偽造成葉子節(jié)點(diǎn)，不把Layer組件的子節(jié)點(diǎn)設(shè)置給Yoga，這樣一個(gè)Yoga中的布局樹(shù)就被Layer組件切割開(kāi)了。當(dāng)根節(jié)點(diǎn)計(jì)算完成以后，通知到Layer組件，Layer組件再依次去設(shè)置子節(jié)點(diǎn)的寬高和位置屬性，并觸發(fā)子節(jié)點(diǎn)去完成各自子節(jié)點(diǎn)的布局計(jì)算。這樣就完美地實(shí)現(xiàn)了Layer的布局效果。

難點(diǎn)三：Litho圖片組件不支持使用網(wǎng)絡(luò)圖片問(wèn)題

原因分析：?Litho的組件是一個(gè)屬性的集合，Litho期望我們?cè)诮M件創(chuàng)建時(shí)便確定了所有屬性的值，所以Litho不支持網(wǎng)絡(luò)圖的展示。如果要支持從網(wǎng)絡(luò)下載圖片，就意味著圖片組件用來(lái)展示的內(nèi)容會(huì)發(fā)生變化。所以Litho自帶的圖片組件并不支持使用網(wǎng)絡(luò)圖片。

解決方案

方案一：用State屬性解決網(wǎng)絡(luò)圖片下載帶來(lái)的展示內(nèi)容變化問(wèn)題。我們?cè)趯?shí)踐中發(fā)現(xiàn)，State屬性的更新會(huì)導(dǎo)致整個(gè)布局重新計(jì)算，其實(shí)替換圖片資源不會(huì)導(dǎo)致圖片組件的大小位置發(fā)生變化，根本不需要重新計(jì)算布局。為了減少使用State屬性導(dǎo)致布局計(jì)算頻繁的問(wèn)題，就摒棄了這種方案。

方案二：Litho官方額外提供的異步下載圖片組件FrescoImage中使用的是圖片代理方式。FrescoImage使用DraweeDrawable來(lái)繪制視圖，而DraweeDrawable實(shí)際上并不具備圖片渲染的能力，只是在內(nèi)部保存了一個(gè)真正的Drawable來(lái)負(fù)責(zé)渲染。所以，DraweeDrawable本質(zhì)上是對(duì)真正要展示的圖片做了一層代理，當(dāng)從網(wǎng)絡(luò)上下載下來(lái)真正要展示的圖片后，只需要通過(guò)替換代理圖片就可以完成視圖的更新。美團(tuán)下載圖片使用的是Glide，只需要按照這個(gè)思路實(shí)現(xiàn)自己的GlideDrawable就好了。

難點(diǎn)四：自定義標(biāo)簽擴(kuò)展的接口不兼容問(wèn)題

MTFlexbox支持自定義標(biāo)簽的擴(kuò)展，所以我們?cè)谕瓿苫疽晥D標(biāo)簽的Litho實(shí)現(xiàn)以后，還需要支持自定義Tag的擴(kuò)展，才算完成視圖引擎的替換工作。

原因分析：?MTFlexbox在設(shè)計(jì)自定義標(biāo)簽接口時(shí)，只提供了允許使用View完成視圖擴(kuò)展的接口，但是Litho實(shí)現(xiàn)的視圖引擎是使用組件作為視圖單元和MTFlexbox對(duì)接的，所以接口不能兼容。

解決方案

方案一：重新提供使用Litho組件完成視圖擴(kuò)展的接口。其缺點(diǎn)是，需要MTFlexbox的使用方重新實(shí)現(xiàn)已經(jīng)支持了的自定義標(biāo)簽，工作量較大，所以這種方案被拋棄了。

方案二：Litho中使用業(yè)務(wù)方已經(jīng)擴(kuò)展好的View。其優(yōu)點(diǎn)是使用方對(duì)視圖引擎的替換無(wú)感知。那么，怎樣才能在Litho中使用業(yè)務(wù)方已經(jīng)擴(kuò)展好的View呢？可以先看下面這張圖。

我們可以簡(jiǎn)單的理解成Litho對(duì)Android的View做了一個(gè)功能拆分，把屬性和布局計(jì)算的能力放在了組件里面，每一種組件對(duì)應(yīng)一個(gè)繪制單元來(lái)專(zhuān)門(mén)負(fù)責(zé)繪制。那么對(duì)于使用方擴(kuò)展的標(biāo)簽，我們可以定義一個(gè)通用組件來(lái)統(tǒng)一承接。在掛載繪制單元時(shí)，再去調(diào)用使用方擴(kuò)展的視圖去繪制。

優(yōu)化效果

至此，視圖引擎的替換就完成了，整個(gè)視圖引擎的替換做到了使用方無(wú)感知。完美解決了MTFlexbox視圖層級(jí)深的問(wèn)題，順帶還優(yōu)化了部分性能。下面是布局層級(jí)優(yōu)化效果的對(duì)比，可以看到相同樣式下，使用Litho引擎實(shí)現(xiàn)的視圖比使用MTFlexbox原生引擎的視圖層級(jí)要淺很多。

除此之外，還有我們的內(nèi)存優(yōu)化成果。下圖是美團(tuán)首頁(yè)使用MTFlexbox時(shí)，內(nèi)存占用隨滑動(dòng)頁(yè)數(shù)（一頁(yè)為20條數(shù)據(jù)）增加而變化的趨勢(shì)圖。可以看到，使用Litho引擎實(shí)現(xiàn)的MTFlexbox比使用原生引擎的MTFlexbox在內(nèi)存占用上能有30M以上的優(yōu)化。

4.2 解決問(wèn)題二：生成視圖耗時(shí)過(guò)長(zhǎng)

上文提到導(dǎo)致生成視圖耗時(shí)過(guò)長(zhǎng)的有兩個(gè)原因：

(1) MTFlexbox對(duì)布局模版的下載和解析耗時(shí)。 (2) MTFlexbox綁定時(shí)解析數(shù)據(jù)的耗時(shí)。

上文“自定義標(biāo)簽擴(kuò)展的接口不兼容問(wèn)題”中介紹過(guò)Litho的組件能夠獨(dú)立完成布局計(jì)算。另外，Litho組件是輕量級(jí)的，所以我們直接把Litho組件作為RecyclerView適配器的數(shù)據(jù)源。這樣就需要在數(shù)據(jù)解析時(shí)提前完成組件的創(chuàng)建，而組件的創(chuàng)建需要用到MTFlexbox的整個(gè)解析過(guò)程，也就是說(shuō)，我們把MTFlexbox導(dǎo)致視圖生成耗時(shí)過(guò)長(zhǎng)的過(guò)程提前在數(shù)據(jù)層異步完成了。這樣就不需要等到視圖要展示時(shí)再去解析，從而規(guī)避了視圖生成耗時(shí)過(guò)長(zhǎng)的問(wèn)題。具體的原理，可以參見(jiàn)Litho的使用及原理剖析一文中的3.2節(jié)“異步布局”。

如上圖所示，在異步線程中提前完成MTFlexbox布局到Litho組件的轉(zhuǎn)換。當(dāng)視圖真正要展示時(shí)，只需要把組件設(shè)置給LithoView就可以了。

優(yōu)化效果

使用Litho引擎實(shí)現(xiàn)的滑動(dòng)列表，在連續(xù)滑動(dòng)過(guò)程中不會(huì)出現(xiàn)FPS波動(dòng)問(wèn)題，而使用MTFlexbox原生引擎實(shí)現(xiàn)的滑動(dòng)列表則波動(dòng)明顯。（數(shù)據(jù)采集自魅藍(lán)2手機(jī)，中低端手機(jī)優(yōu)化效果明顯）

5. 總結(jié)

經(jīng)過(guò)一段時(shí)間的實(shí)踐，Litho + MTFlexbox給美團(tuán)App在性能指標(biāo)上帶來(lái)了較大的提升。但是還有很多問(wèn)題待完善，我們后續(xù)還會(huì)針對(duì)以下幾點(diǎn)進(jìn)一步提升效果：

• 利用Litho組件屬性不可變的特點(diǎn)，將提前異步布局進(jìn)一步擴(kuò)展為提前渲染出位圖，在繪制時(shí)直接展示位圖，可以進(jìn)一步提升繪制效率。
• 優(yōu)化RecyclerView相關(guān)的API，降低侵入性。
• 解決有點(diǎn)擊事件、埋點(diǎn)事件等屬性的視圖需要降級(jí)成View才能使功能生效的問(wèn)題，進(jìn)一步優(yōu)化視圖層級(jí)。

6.參考資料

Litho官網(wǎng) Flexbox規(guī)范

7. 作者簡(jiǎn)介

少寬、騰飛、葉梓，美團(tuán)終端業(yè)務(wù)研發(fā)團(tuán)隊(duì)開(kāi)發(fā)工程師。

8. 招聘信息

美團(tuán)終端業(yè)務(wù)研發(fā)團(tuán)隊(duì)的職責(zé)是保障平臺(tái)業(yè)務(wù)高效、穩(wěn)定迭代的同時(shí)，持續(xù)優(yōu)化用戶(hù)體驗(yàn)和研發(fā)效率。團(tuán)隊(duì)負(fù)責(zé)的業(yè)務(wù)主要包括美團(tuán)首頁(yè)、美團(tuán)搜索等千萬(wàn)級(jí)DAU高頻業(yè)務(wù)以及分享、賬號(hào)、音/視頻等基礎(chǔ)業(yè)務(wù)，支撐和對(duì)接外賣(mài)、酒店等30多個(gè)業(yè)務(wù)方。

團(tuán)隊(duì)通過(guò)動(dòng)態(tài)化能力建設(shè)，加快業(yè)務(wù)上線速度，幫助產(chǎn)品團(tuán)隊(duì)快速驗(yàn)證業(yè)務(wù)選型，做出業(yè)務(wù)決策；通過(guò)架構(gòu)/服務(wù)標(biāo)準(zhǔn)化體系建設(shè)，提升前后端以及平臺(tái)與業(yè)務(wù)線的溝通、合作效率；業(yè)務(wù)監(jiān)控和體驗(yàn)優(yōu)化，有效保障核心業(yè)務(wù)服務(wù)成功率的同時(shí)，提升用戶(hù)使用美團(tuán)App過(guò)程中的穩(wěn)定性和流暢性。團(tuán)隊(duì)開(kāi)發(fā)技術(shù)棧包括Android、iOS、ReactNative、Flexbox等。

美團(tuán)終端業(yè)務(wù)研發(fā)團(tuán)隊(duì)現(xiàn)誠(chéng)聘Android、iOS工程師，歡迎有興趣的同學(xué)投簡(jiǎn)歷至：tech@meituan.com（注明：美團(tuán)終端業(yè)務(wù)研發(fā)團(tuán)隊(duì)）。

總結(jié)

以上是生活随笔為你收集整理的Litho在美团动态化方案MTFlexbox中的实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。