AiFlutter體系化建設(shè)和實(shí)踐

淘系技術(shù)部隸屬于阿里巴巴新零售技術(shù)事業(yè)群術(shù)、天貓技術(shù)、阿里農(nóng)村技術(shù)、閑魚(yú)、躺平等團(tuán)隊(duì)和業(yè)務(wù)，是一支是是致力于成為全球最懂商業(yè)的技術(shù)創(chuàng)新團(tuán)隊(duì)，打造消費(fèi)者和商家一體依托淘系豐富的業(yè)務(wù)形態(tài)和海量的用戶，我們持續(xù)品和商業(yè)創(chuàng)新，不斷探索和衍生顛覆型互聯(lián)網(wǎng)新技術(shù)，以更加智能、阿里集團(tuán)內(nèi)如何進(jìn)行Flutter體AliFlutter客戶端研發(fā)體系概覽閑魚(yú)研發(fā)框架應(yīng)用和探索AliFlutter圖片解決方案與優(yōu)化UCFlutter技術(shù)實(shí)踐分享64基于Flutter的Canvas探索與應(yīng)用82淘寶特價(jià)版開(kāi)發(fā)體系的探索91ICBUFlutter探索之路106Flutter在餓了么的應(yīng)用與沉淀2019年無(wú)疑是Flutter技術(shù)如火如荼發(fā)展的一年。每一個(gè)移動(dòng)開(kāi)發(fā)者都在為Flutter帶來(lái)的“快速開(kāi)發(fā)、富有表現(xiàn)力和靈活的UI、原生性能”的特色和理念而癡狂，從超級(jí)App到獨(dú)立應(yīng)用，從純Fl為什么是Flutter？阿里巴巴集團(tuán)內(nèi)也有越來(lái)越多的業(yè)務(wù)和團(tuán)隊(duì)開(kāi)始嘗試Flutter技術(shù)棧，從閑魚(yú)的一支獨(dú)秀引領(lǐng)潮流，到如今淘寶特價(jià)版、盒馬、優(yōu)酷、飛豬等BU業(yè)務(wù)相繼入局，F(xiàn)lutter的業(yè)務(wù)應(yīng)用在集團(tuán)內(nèi)也已經(jīng)逐漸形成趨勢(shì)。那么，是什么原因讓集團(tuán)內(nèi)越來(lái)越多的開(kāi)發(fā)者選擇擁抱Flutter技術(shù)棧？Flutter的哪些優(yōu)勢(shì)吸引了集團(tuán)Native開(kāi)發(fā)極高的開(kāi)發(fā)與交付效率，良好的開(kāi)發(fā)體驗(yàn)優(yōu)秀的跨多端多平臺(tái)能力極強(qiáng)的UI表現(xiàn)力先說(shuō)一下開(kāi)發(fā)效率。從集團(tuán)電商業(yè)務(wù)屬性出發(fā)，業(yè)務(wù)響應(yīng)效率及其背后的研發(fā)效率從來(lái)都是最為重要的指標(biāo)。在保證體驗(yàn)的前提下，盡可能的提高研發(fā)效率，就意味著更高的生產(chǎn)力。傳統(tǒng)的Native業(yè)務(wù)研發(fā)iOS/Android雙端需要分別投入，研發(fā)成本高，端差異性大且依賴端側(cè)發(fā)版，這也是為什么集團(tuán)電商業(yè)務(wù)的活動(dòng)類技術(shù)棧一直較為依賴前端體系，從H5到Weex到小程序，很大程度上就是在追求研發(fā)和交付效率以及靈活性。如今Flutter很好的解決了跨端一致性問(wèn)題，一套代碼無(wú)差異 電商業(yè)務(wù)發(fā)展到當(dāng)前階段，已經(jīng)不再僅僅局限于移動(dòng)端場(chǎng)景，越來(lái)越多的業(yè)務(wù)需求對(duì)跨端跨平臺(tái)性提出了更高的要求。釘釘/千牛桌面端應(yīng)用場(chǎng)景，甚至天貓精靈、線下門店等業(yè)務(wù)場(chǎng)景，從長(zhǎng)遠(yuǎn)看都需要一個(gè)比Web性能一致性更好適配成本更低的多端方案。目前跨多端技術(shù)方案主要依賴于瀏覽器和前端體系，但瀏覽器本身的沙盒屬性、與系統(tǒng)較低的結(jié)合度、以及在低端設(shè)備上較差的性能都降低了研發(fā)效率和用戶體驗(yàn)，提高了業(yè)務(wù)的交付門檻?？梢哉f(shuō)目前集團(tuán)內(nèi)的跨多端多平臺(tái)方案是實(shí)質(zhì)缺失的。Flutter從設(shè)計(jì)上就天然支持多平臺(tái)開(kāi)發(fā)，它的底層基于Skia跨平臺(tái)圖形引擎，向上構(gòu)建出了一整套平臺(tái)無(wú)關(guān)的渲染體系和事件處理體系，并緊貼Native研發(fā)模式自定義了基于widgets的聲明+響應(yīng)式編程范式，對(duì)系統(tǒng)能力依賴度低，并具Android，官方宣布支持的平臺(tái)有Mac、Windows和Web，Linux也在開(kāi)發(fā)中，還是未來(lái)Google的下一代操作系統(tǒng)Fuschia的官方應(yīng)用研發(fā)框架?？梢哉f(shuō)Flutter已經(jīng)具備了成為下一代跨多端多平臺(tái)研發(fā)模式的一切條件，圍繞Flutter建立集團(tuán)的最后講一下UI表現(xiàn)力。電商業(yè)務(wù)重體驗(yàn)，重交互，尤其對(duì)于流量精細(xì)化運(yùn)營(yíng)場(chǎng)景，富交互的游戲化表現(xiàn)方式已經(jīng)成為流量促活的重要手段。在UI表現(xiàn)力方面，前端體系一直具備著優(yōu)勢(shì)，通過(guò)CSS3強(qiáng)大的動(dòng)畫(huà)能力，開(kāi)發(fā)者可以非常容易的實(shí)現(xiàn)復(fù)雜的動(dòng)畫(huà)效果和交互體驗(yàn)，而基于NativeUI，需要借助各種動(dòng)畫(huà)特效三方庫(kù)，雙端開(kāi)發(fā)體驗(yàn)不一致，實(shí)現(xiàn)復(fù)雜且交付效率低。Flutter很好的解決了這個(gè)問(wèn)題，從補(bǔ)間（Tween）動(dòng)畫(huà)、基于物理屬性的動(dòng)畫(huà)，到相對(duì)復(fù)雜的頁(yè)面間Hero動(dòng)畫(huà)、parallax交錯(cuò)動(dòng)畫(huà)等特效，F(xiàn)lutter都可以跨平臺(tái)低成本的高效實(shí)現(xiàn)。這里貼一個(gè)去年年底Flutter體系化建設(shè)現(xiàn)狀目前集團(tuán)內(nèi)有多個(gè)業(yè)務(wù)BU均已開(kāi)始嘗試應(yīng)用Flutter技術(shù)棧，涵蓋了從電商詳情業(yè)務(wù)、導(dǎo)購(gòu)頻道，到Feeds流、游戲化交互以及國(guó)際化等多個(gè)業(yè)務(wù)場(chǎng)景。目前Flutter技術(shù)在集團(tuán)應(yīng)用的痛點(diǎn)在于，研發(fā)基礎(chǔ)設(shè)施的中臺(tái)基建不夠完善，研發(fā)支撐能力與數(shù)據(jù)運(yùn)維能力未實(shí)現(xiàn)標(biāo)準(zhǔn)化，集團(tuán)Flutter開(kāi)發(fā)者生態(tài)還未完全拉通，暫時(shí)未方面從行業(yè)趨勢(shì)上看，F(xiàn)lutter技術(shù)已經(jīng)成為越來(lái)越多行業(yè)伙伴重點(diǎn)投入的技術(shù)建設(shè)方向。字節(jié)跳動(dòng)、美團(tuán)等公司均建設(shè)了自己的Flutter工程化體系，并服務(wù)了各自的力服務(wù)小程序的場(chǎng)景下做了有益探索。行業(yè)伙伴們?cè)贔lutter技術(shù)上的投入力度和決心，一方面讓我們對(duì)Flutter技術(shù)的應(yīng)用前景和社區(qū)更有信心，另一方面也讓我們感基礎(chǔ)能力，并服務(wù)了淘寶特價(jià)版業(yè)務(wù)，在引擎、圖片庫(kù)、內(nèi)存優(yōu)化和加載性能等關(guān)鍵向上支持小程序Canvas組件及小游戲引擎，服務(wù)2D/2.5D游戲化業(yè)務(wù)，并在業(yè)務(wù)場(chǎng)景中落地。在這個(gè)過(guò)程中，我們也沉淀了解決內(nèi)存問(wèn)題和圖片問(wèn)題等方案，以及Flutter技術(shù)與Web技術(shù)的對(duì)比與思考，取得了一定的技術(shù)及業(yè)務(wù)價(jià)值。通過(guò)這些 從業(yè)務(wù)應(yīng)用上看：Flutter目前帶來(lái)的最大價(jià)值是研發(fā)效率的提升。在基建和native擴(kuò)展能力完備的前提下，開(kāi)發(fā)基于Flutter的純分別開(kāi)發(fā)的效率提高了接近2倍，單位時(shí)間內(nèi)的需求響應(yīng)能力也相應(yīng)提高了接近2從適應(yīng)場(chǎng)景看：Flutter目前比較適合承載富圖文內(nèi)容，如詳情、Feeds流、用戶主頁(yè)等常規(guī)業(yè)務(wù)開(kāi)發(fā)，以及2D/2.5D游戲場(chǎng)景以及富動(dòng)技術(shù)?？梢酝瑫r(shí)滿足以前需要iOS、Android以及前端技術(shù)棧分別負(fù)責(zé)的業(yè)務(wù)場(chǎng)景，甚至可以通過(guò)端云一體化的開(kāi)發(fā)模式使用Dart負(fù)責(zé)一部分服務(wù)端業(yè)務(wù)邏輯開(kāi)發(fā)，可以幫助業(yè)務(wù)團(tuán)隊(duì)拓展業(yè)務(wù)邊界的同時(shí)，實(shí)現(xiàn)前后端研發(fā)能力閉環(huán)。Flutter目前的限制在于，動(dòng)態(tài)性能力及前期的投入成本。前期投入成本主要指技術(shù)學(xué)習(xí)與團(tuán)隊(duì)研發(fā)模式升級(jí)的成本，涉及到技術(shù)路線選擇，是我們和每個(gè)業(yè)務(wù)團(tuán)隊(duì)需要一起思考和判斷技術(shù)實(shí)現(xiàn)基于模板的組件級(jí)動(dòng)態(tài)化能力，但基于性能、審核及對(duì)原生Flutter體系的侵入性等多種因素，目前還不能去直接實(shí)現(xiàn)UI+邏輯動(dòng)態(tài)化能力。FlutterWeb方案雖然不存在審核限制，但受限于瀏覽器DOMAPI與widgets體系的差異性，目前仍舊存在較嚴(yán)重的性能瓶頸和渲染差異性，僅可作為降級(jí)的備用方案，暫時(shí)無(wú)法作為動(dòng)態(tài)化的主要實(shí)現(xiàn)方案。未來(lái)在動(dòng)態(tài)化方向的探索也將是個(gè)長(zhǎng)期的博弈過(guò)程。如果AliFlutter-經(jīng)濟(jì)體移動(dòng)小組Flutter共建項(xiàng)目在這樣的背景下，經(jīng)濟(jì)體移動(dòng)技術(shù)小組今年也將端側(cè)架構(gòu)治理的重點(diǎn)方向放在了Flutter容器、中間件與API標(biāo)準(zhǔn)，建設(shè)Flutter研發(fā)支撐與聯(lián)合各BU構(gòu)建經(jīng)濟(jì)體Flutter技在經(jīng)濟(jì)體層面構(gòu)建Flutter的對(duì)外影響力，聯(lián)合各BU一致對(duì)外，打造阿里在為經(jīng)濟(jì)體的Flutter技術(shù)體系“建基礎(chǔ)、育社區(qū)、扛大旗”，我們責(zé)無(wú)旁貸。未來(lái)AliFlutter的整體架構(gòu)如下所示：AliFlutter建設(shè)的第一步，就是要構(gòu)建集團(tuán)的Flutter基礎(chǔ)設(shè)施、提供公共容器與組件、研發(fā)支撐服務(wù)與標(biāo)準(zhǔn)化研發(fā)流程，為集團(tuán)術(shù)特性的結(jié)合點(diǎn)，并在過(guò)程中打磨技術(shù)，形成針對(duì)業(yè)務(wù)特點(diǎn)的解決方案與技術(shù)沉淀，應(yīng)用的幾個(gè)核心關(guān)鍵問(wèn)題：跨端與交互能力、業(yè)務(wù)研發(fā)效率與業(yè)務(wù)交付效率，通過(guò)技術(shù)賦能業(yè)務(wù)，讓Flutter真正成為集團(tuán)移動(dòng)業(yè)務(wù)的核心研發(fā)模式。接下來(lái)，就詳細(xì)講了Flutter的構(gòu)建打包自動(dòng)化，定義了標(biāo)準(zhǔn)的引擎定制工作流與業(yè)務(wù)研發(fā)工作流。目前基礎(chǔ)設(shè)施已經(jīng)具備支撐集團(tuán)Flutter業(yè)務(wù)研發(fā)的能力， Artifacts倉(cāng)庫(kù)產(chǎn)物服務(wù)器主要是為了配合引擎定制，加速通過(guò)Flutter產(chǎn)物的后端服務(wù)，便于統(tǒng)一Flutter開(kāi)發(fā)者的工作環(huán)境。開(kāi)發(fā)者可通過(guò)設(shè)置FLUT-TER_STORAGE_BASE_URL來(lái)將Flutter工具鏈獲取artifacts的地址指向該服務(wù)，同時(shí)通過(guò)namespace便可實(shí)現(xiàn)定制化的獲取artifacts的能力以及內(nèi)網(wǎng)加速服務(wù)。Namespace設(shè)計(jì)為區(qū)分不同BU的引擎產(chǎn)物，同時(shí)提供了公共namespace來(lái)存儲(chǔ)公共產(chǎn)物，確保定制性和公共能力的按需配置；若后端存儲(chǔ)上不存在需要獲取的產(chǎn)物地址，則會(huì)觸發(fā)從Flutter官方鏡像做一次獲取并緩存在服務(wù)端。各BU可按需定制引擎，并按規(guī)定的路徑格式上傳至自己namespace中，即可實(shí)現(xiàn)從namespace中獲取定制版本的引擎中間產(chǎn)物。到易用性、安全性等需求，為了管理集團(tuán)內(nèi)的公共二方組件，我們也搭建了內(nèi)網(wǎng)環(huán)境方pubpackage。用戶可通過(guò)設(shè)置PUB_HOSTED_URL指向內(nèi)部地址，來(lái)實(shí)現(xiàn)通容器、中間件與API對(duì)于業(yè)務(wù)的接入而言，現(xiàn)階段核心要解決的問(wèn)題就是提供一個(gè)統(tǒng)一的Flutter運(yùn)行時(shí)容器，以及一系列集團(tuán)標(biāo)準(zhǔn)化移動(dòng)中間件的Flutter封裝與API能力，并提合棧的基礎(chǔ)，并配合集團(tuán)標(biāo)準(zhǔn)路由與導(dǎo)航中間件提供了統(tǒng)一的混合棧路由導(dǎo)航能力，同時(shí)，小程序體系建設(shè)過(guò)程中形成的一系列標(biāo)準(zhǔn)API，也很大程度上實(shí)現(xiàn)了一個(gè)完整的小程序運(yùn)行環(huán)境的底層能力抽象，對(duì)于Flutter體系標(biāo)準(zhǔn)化的訪問(wèn)系統(tǒng)能力，我們聯(lián)合淘寶中間件團(tuán)隊(duì)與小程序團(tuán)隊(duì)，對(duì)基礎(chǔ)中間件和小程序API實(shí)現(xiàn)做了標(biāo)準(zhǔn)化Flutter構(gòu)建定特殊性，產(chǎn)物構(gòu)建配置復(fù)雜耗時(shí)長(zhǎng)易出錯(cuò)，給Flutter業(yè)務(wù)的構(gòu)建和發(fā)版帶來(lái)了很大阻礙。因此我們也聯(lián)合研發(fā)支撐部的同學(xué)，以插件的形式實(shí)現(xiàn)了Flutter腳本化的在夯實(shí)Flutter集團(tuán)共建基礎(chǔ)之后，第二步，我們AliFlutter在業(yè)務(wù)應(yīng)用方面也做了大量工作。一方面通過(guò)原生Flutter的工程化能力持續(xù)服務(wù)淘系與集團(tuán)業(yè)務(wù)；另一方面通過(guò)FlutterCanvas項(xiàng)目服務(wù)了小程序場(chǎng)景及游戲化場(chǎng)景下的互動(dòng)業(yè)務(wù)。目前淘寶特價(jià)版已完成詳情業(yè)務(wù)的Flutter改造并上線，采用Flutter使業(yè)務(wù)在需求節(jié)奏不變的情況下人力投入減少一半，對(duì)緩解業(yè)務(wù)研發(fā)壓力起到了明顯的作用； 目前盒馬、ICBU、優(yōu)酷也基于AliFlutter進(jìn)行了容器接入升級(jí)與業(yè)馬依托閑魚(yú)的Flutter游戲引擎實(shí)現(xiàn)了盒馬小鎮(zhèn)業(yè)務(wù)，ICBU在主鏈路相關(guān)頁(yè)面使用FlutterCanvas在小程序場(chǎng)景中Canvas作為承載互動(dòng)游戲的主要能力發(fā)揮了重要作用。然而受限于小程序架構(gòu)下appcontext和pagecontext的隔離設(shè)計(jì)，存在從appworker到pagerenderer的通信瓶頸，無(wú)法充分發(fā)揮出webcanvas的性能，如果有一個(gè)native版的canvas實(shí)現(xiàn)將可直接在native層對(duì)接appworker，降低通信成本，充分發(fā)揮Canvas的性能。Flutter底層基于Skia，其性能和移動(dòng)端復(fù)雜異構(gòu)機(jī)型的適配性均得到過(guò)長(zhǎng)期的檢驗(yàn)，且Flutter基于瀏覽器的設(shè)計(jì)實(shí)現(xiàn)了一條平臺(tái)無(wú)關(guān)的渲染管線，并對(duì)瀏覽器實(shí)現(xiàn)做了極大的簡(jiǎn)化，提供了很好的可靠性和性能。那么如果能夠?qū)⑦@條渲染管線直接用于向業(yè)務(wù)容器提供Canvas能力，通過(guò)binding方式直接向小程序和小游戲容器提供與WebCanvas一致的標(biāo)準(zhǔn)API，一方面可以復(fù)用Flutter的底層能力，為非目前FlutterCanvas已落地手機(jī)淘寶，并在小程序運(yùn)動(dòng)銀行業(yè)務(wù)進(jìn)行了灰度試點(diǎn)，初步具備了承載小程序Canvas業(yè)務(wù)的能力；其性能在Android低端機(jī)上的表現(xiàn)有優(yōu)勢(shì)，可以作為WebCanvas方案的有益補(bǔ)充。未來(lái)FlutterCanvas一方面將借助Flutter渲染管線的跨平臺(tái)與高性能特點(diǎn)，扎根業(yè)務(wù)之后，接下來(lái)的第三步，我們要緊貼Flutter體系在阿里集團(tuán)未來(lái)的建設(shè)目標(biāo)，持續(xù)回答好Flutter面向未來(lái)建設(shè)路徑中的幾個(gè)關(guān)鍵問(wèn)題。那么首先，F(xiàn)lutter體系在阿里集團(tuán)的建設(shè)目標(biāo)應(yīng)該是什么？個(gè)人以為：Flutter應(yīng)成為阿里集團(tuán)未來(lái)跨多端多平臺(tái)的核心業(yè)務(wù)研發(fā)模式之一。那么，我們目前離這個(gè)目標(biāo)還有多大差距？在我看來(lái)，如果要想讓Flutter成為業(yè)務(wù)的核心研發(fā)模式，那么必須解決好跨端從跨端能力看：Flutter雖然已具備了很好平臺(tái)能力時(shí)，仍然需要通過(guò)各端擴(kuò)展實(shí)現(xiàn)，還未形成小程序體系這樣的標(biāo)準(zhǔn)化的容器和API封裝能力。那么如何更好的解決Flutter的容器化問(wèn)題，讓業(yè)務(wù)從交互能力看：Flutter如何利用好自身交從業(yè)務(wù)研發(fā)效率看：雖然Flutter的HotReload/HotUI機(jī)制已經(jīng)讓開(kāi)發(fā)Native頁(yè)面的效率追上了前端，但在工程解耦方面仍然有很大提升空間，目前還無(wú)法高效的支持多業(yè)務(wù)團(tuán)隊(duì)并行開(kāi)發(fā)；另一方面如何與現(xiàn)今流行的Serverless能力結(jié)合，實(shí)現(xiàn)端云一體研發(fā)模式，使業(yè)務(wù)實(shí)現(xiàn)研發(fā)閉環(huán)，也需率低，無(wú)法很好的承載電商系靈活性和實(shí)效性的需求；那么如何解決Flutter 解決好這幾個(gè)問(wèn)題，才能真正讓Flutter成為集團(tuán)移動(dòng)業(yè)務(wù)的核心研發(fā)模式，為提升跨端能力：Flutter容器化從工程角度看，雖然Flutter通過(guò)Skia跨平臺(tái)圖形渲染和自建事件體系基本實(shí)現(xiàn)了對(duì)宿主平臺(tái)的最小依賴，但對(duì)于平臺(tái)側(cè)能力，目前Flutter還未也沒(méi)有必要從應(yīng)用框架角度做到一個(gè)統(tǒng)一的抽象，這就需要我們根據(jù)業(yè)務(wù)的訴求和特點(diǎn)進(jìn)行有選擇的封裝。小程序API就做了一個(gè)非常好的示范，目前阿里小程序體系提供的API達(dá)到了200+，很好的對(duì)移動(dòng)端的UI、多媒體、文件緩存、網(wǎng)絡(luò)、設(shè)備能及業(yè)務(wù)相關(guān)能力進(jìn)行了封裝，讓業(yè)務(wù)開(kāi)發(fā)者在小程序側(cè)針對(duì)API進(jìn)行系統(tǒng)能力調(diào)用，一套標(biāo)準(zhǔn)化的API能力，以規(guī)范并抽象移動(dòng)端的端基礎(chǔ)能力，使業(yè)務(wù)盡量少甚至不關(guān)從移動(dòng)端架構(gòu)角度看，各個(gè)時(shí)期的跨平臺(tái)方案都對(duì)API能力有著共同的訴求，從H5到Weex，再到后面的小程序，以及Flutter等容器環(huán)境，進(jìn)行了多輪的API重復(fù)建設(shè)，造成了缺少API接口的標(biāo)準(zhǔn)化定義，以及缺少實(shí)現(xiàn)層統(tǒng)一管控的現(xiàn)狀。如果能夠在API的native實(shí)現(xiàn)上做到接口統(tǒng)一，再通過(guò)各個(gè)容器分別提供接口供業(yè)務(wù)使用，可以更好的做到實(shí)現(xiàn)收口，并在統(tǒng)一實(shí)現(xiàn)層跨容器實(shí)現(xiàn)對(duì)系統(tǒng)資源的統(tǒng)一調(diào)前文提到過(guò)，F(xiàn)lutter目前最大的價(jià)值在于研發(fā)效率的提升，這是吸引業(yè)務(wù)團(tuán)隊(duì)?wèi)?yīng)用Flutter技術(shù)的起點(diǎn)；但僅僅依靠研發(fā)提效還遠(yuǎn)遠(yuǎn)不夠，當(dāng)通過(guò)各種工程化手段解決好當(dāng)前研發(fā)痛點(diǎn)，提升研發(fā)效率之后，如何說(shuō)服業(yè)務(wù)繼續(xù)使用Flutter體系進(jìn)行業(yè)務(wù)開(kāi)發(fā)？Flutter帶來(lái)的長(zhǎng)遠(yuǎn)價(jià)值在哪里？個(gè)人認(rèn)為，這個(gè)落腳點(diǎn)應(yīng)該在通過(guò)游戲交互能力的泛化，打破UI與游戲引擎的邊界，用游戲化的方式創(chuàng)造更有表現(xiàn)力的交互體驗(yàn)，創(chuàng)造新的業(yè)務(wù)玩法和價(jià)值。大家知道傳統(tǒng)的UI和游戲引擎是相互獨(dú)立的兩個(gè)體系，在H5應(yīng)用中，往往是通過(guò)DOM或者上層應(yīng)用框架做Ucanvas上的H5游戲引擎實(shí)現(xiàn)游戲能力。如果在游戲應(yīng)用中有UI的需求，解決方立游戲引擎亦是如此。Flutter從技術(shù)原理上看更像是一個(gè)建立在Skia圖形庫(kù)上的游戲引擎，它通過(guò)細(xì)粒度的widgets設(shè)計(jì)向上構(gòu)建UI系統(tǒng)；同樣得益于這樣的細(xì)粒度設(shè)計(jì)，我們也完全可以直接通過(guò)widgets能力組合出一個(gè)完整的游戲引擎，提供Game，Scene及Sprite動(dòng)效等widgets并擴(kuò)展對(duì)應(yīng)的elements和render于打破了原來(lái)H5中DOMUI和Canvas游戲的邊界，讓兩個(gè)體系在widgets概念下完美融合起來(lái)，通過(guò)游戲引擎的能力賦能UI實(shí)現(xiàn)更多以前UI體系難以低成本實(shí)現(xiàn)探索將會(huì)進(jìn)一步釋放Flutter的技術(shù)潛力，帶來(lái)更多的業(yè)務(wù)可玩性與創(chuàng)造性，解放產(chǎn)前端體系的研發(fā)效率很大程度上來(lái)自于基于URI的統(tǒng)一路由體系帶來(lái)的頁(yè)面間解耦性，與頁(yè)面內(nèi)基于WebAPI的標(biāo)準(zhǔn)化帶來(lái)的內(nèi)聚性。然而目前的Flutter研發(fā)模式，仍需要多個(gè)業(yè)務(wù)團(tuán)隊(duì)工作在同一個(gè)工程下，互相之間存在源碼依賴，未來(lái)如果跨業(yè)務(wù)團(tuán)隊(duì)大規(guī)模應(yīng)用Flutter技術(shù)，必將拖慢業(yè)務(wù)的研發(fā)效率。從工程解耦角度看，目前AliFlutter容器通過(guò)混合棧與標(biāo)準(zhǔn)路由能力基本實(shí)現(xiàn)了頁(yè)面研發(fā)的解耦，未來(lái)的容器化建設(shè)通過(guò)提供小程序?qū)Φ鹊腁PI能力封裝，業(yè)務(wù)對(duì)平臺(tái)無(wú)感知，能夠讓我們有機(jī)會(huì)解耦業(yè)務(wù)研發(fā)，實(shí)現(xiàn)與小程序開(kāi)發(fā)接近的研發(fā)體驗(yàn)和效率。理想的方案是：覽工程并調(diào)試API與系統(tǒng)調(diào)用，完成研發(fā)期工作；也可生成預(yù)覽二維碼，使用預(yù)裝有 AliFlutterSDK環(huán)境的宿主應(yīng)用掃碼預(yù)覽；研發(fā)與構(gòu)建鏈路分離，云端主動(dòng)拉取業(yè)務(wù)倉(cāng)庫(kù)代碼參與整包構(gòu)建。以此達(dá)到類似小程序研發(fā)方式的前端研發(fā)體驗(yàn)，同時(shí)實(shí)現(xiàn)業(yè)如今Serverless概念越來(lái)越多的受到業(yè)務(wù)研發(fā)的重視和應(yīng)用，集團(tuán)在新一代的端云一體化研發(fā)模式上的探索這一年多來(lái)也做的如火如荼。結(jié)合輕量級(jí)容器環(huán)境、多語(yǔ)言支持能力與統(tǒng)一的API服務(wù)端編程，端側(cè)同學(xué)可以很容易的使用客戶端語(yǔ)言如Java、JS、Swift甚至Dart來(lái)開(kāi)發(fā)服務(wù)端業(yè)務(wù)能力，實(shí)現(xiàn)服務(wù)編排、服務(wù)端FaaS業(yè)務(wù)邏輯與API自動(dòng)生成，達(dá)到前后端工程體系歸一，業(yè)務(wù)研發(fā)閉環(huán)的效果。目前閑魚(yú)在DartFaaS云端一體化的探索走在了前面，通過(guò)集團(tuán)的容器規(guī)范實(shí)現(xiàn)了Dartfunction容器，并聯(lián)合服務(wù)端為部分業(yè)務(wù)需要的領(lǐng)域服務(wù)抽象出來(lái)BaaS層（存儲(chǔ)、消息隊(duì)列等并封裝了面向前端的BFF（BackendforFrontend）能力層，使移動(dòng)端開(kāi)發(fā)者可以很容易的使用Dart封裝FaaS業(yè)務(wù)邏輯，同時(shí)進(jìn)行移動(dòng)端和服務(wù)端FaaS開(kāi)發(fā)，大大提高了業(yè)務(wù)研發(fā)效率。通過(guò)將原有的端側(cè)請(qǐng)求接口、組裝數(shù)據(jù)并轉(zhuǎn)換為ViewModel的邏輯都后移到了服務(wù)端，經(jīng)過(guò)字段映射與頁(yè)面編排，移動(dòng)端可直接獲取ViewModel并刷新頁(yè)面，通過(guò)BinderAction雙向交互狀態(tài)數(shù)據(jù)，有效屏蔽了通信細(xì)節(jié)，提高了開(kāi)發(fā)效率。云端一體化除了帶來(lái)了研發(fā)與協(xié)同效率的提升，同時(shí)也重塑了生產(chǎn)關(guān)系，使端側(cè)業(yè)務(wù)從只關(guān)注端側(cè)體驗(yàn)和邏輯的開(kāi)發(fā)角色，變成能夠向業(yè)務(wù)整體結(jié)果負(fù)責(zé)；同時(shí)也讓服務(wù)端更專注于領(lǐng)域服務(wù)的沉淀。Flutter良好的跨端特性，能夠屏蔽掉端差異化，配合Flutter容器化改造，更近一步的簡(jiǎn)化了業(yè)務(wù)的全鏈路研發(fā)模式。未來(lái)如何在FaaS模式下，沉淀出一套可以服務(wù)集團(tuán)業(yè)務(wù)研發(fā)的通用端側(cè)和服務(wù)端通信調(diào)度框架，讓集團(tuán)Flutter開(kāi)發(fā)者和業(yè)務(wù)都能共享到Serverless技提升交付效率：Flutter動(dòng)態(tài)化實(shí)現(xiàn)動(dòng)態(tài)化是交付效率提升的重要方式。對(duì)于電商強(qiáng)運(yùn)營(yíng)強(qiáng)時(shí)效性特性來(lái)說(shuō)，動(dòng)態(tài)化幾乎是一個(gè)必備的訴求，但從技術(shù)上看也是一個(gè)非常敏感的需求，是一個(gè)在系統(tǒng)廠商平臺(tái)管控下長(zhǎng)期博弈的過(guò)程。在我看來(lái)，動(dòng)態(tài)化技術(shù)需要解決的核心問(wèn)題，是在保證業(yè)務(wù)發(fā)布確定性的前提下，尋求技術(shù)性能、業(yè)務(wù)迭代效率與靈活性三者之間合理與WebonFlutter。Flutter模板化方案動(dòng)態(tài)模板化方案是集團(tuán)前被廣泛應(yīng)用于電商系的一些核心業(yè)務(wù)場(chǎng)景。同時(shí)該方案提供了配套的組件平臺(tái)，支持在線模板編輯、預(yù)覽、測(cè)試及發(fā)布整套流程，結(jié)合發(fā)布平臺(tái)形成了一整套完善的業(yè)務(wù)開(kāi)發(fā)生態(tài)閉環(huán)。在Flutter體系下，目前閑魚(yú)團(tuán)隊(duì)依據(jù)標(biāo)準(zhǔn)模板協(xié)議在Flutter側(cè)實(shí)現(xiàn)了一套Dart版SDK，通過(guò)模板下發(fā)實(shí)現(xiàn)了Flutter端的輕量級(jí)動(dòng)態(tài)化組件編排能力；并通過(guò)一年多的迭代逐步解決了渲染性能與渲染一致性問(wèn)題，較好的賦能了Flutter業(yè)務(wù)的組件動(dòng)態(tài)化能力。那么，未來(lái)Flutter與動(dòng)態(tài)模板化方案有沒(méi)有更好的結(jié)合點(diǎn)？答案是肯定的。從DSL角度看，目前模板的寫法基本上來(lái)自AndroidXML，對(duì)組件開(kāi)發(fā)者尤其是非Android開(kāi)發(fā)者不夠友好，具備一定的學(xué)習(xí)成本；而Flutter的結(jié)構(gòu)與屬性均可通過(guò)widgets表達(dá)，可以極為靈活且平臺(tái)中立的用聲明式代碼構(gòu)建UI并綁定數(shù)據(jù)，易于開(kāi)發(fā)者編寫組件并通過(guò)FluH5的DSL+JS，借助Flutter的渲染能力，實(shí)現(xiàn)貼前端技術(shù)棧的動(dòng)態(tài)化能力。目前基于Web渲染的小程序方案存在啟動(dòng)耗時(shí)高，渲染性能距原生UI有較大差距等性能問(wèn)題，這些問(wèn)題很大程度上都源自于瀏覽器引擎的設(shè)計(jì)歷史包袱（渲染管線復(fù)雜、CSSmulti-passlayout及l(fā)egacy實(shí)現(xiàn)等以及JS到Native通信效率低成就，原生支持了聲明式-響應(yīng)式編程范式，提高了移動(dòng)端的研發(fā)效率；另一方面， Flutter緊貼native開(kāi)發(fā)模式有限定義了UI結(jié)構(gòu)、布局與渲染的必要元素，在滿足nativeUI開(kāi)發(fā)模式的前提下簡(jiǎn)化了能力定義與布局算法（single-passlayout與repaintboundary等概念很大程度上簡(jiǎn)化了渲染管線的復(fù)雜度，直接為Flutter帶來(lái)了接近原生的性能體驗(yàn)。同時(shí)，F(xiàn)lutter的widgets設(shè)計(jì)巧妙，結(jié)構(gòu)布局屬性等基礎(chǔ)元素均使用widgets表達(dá)，且可通過(guò)基礎(chǔ)widgets的組合來(lái)構(gòu)成復(fù)雜組件，這種細(xì)粒度+組合能力設(shè)計(jì)讓Flutter有極強(qiáng)的表現(xiàn)力，的可能性。因此，通過(guò)widgets組合小程序DSL，支持小程序CSS有限集，實(shí)現(xiàn)渲染層替換瀏覽器引擎，并對(duì)接JS引擎支持JS執(zhí)行能力，是一個(gè)將Flutter應(yīng)用于小程序生態(tài)的合理探索方向。相比把開(kāi)發(fā)者慣壞了的瀏覽器，這種方案在CSS的能力支持上必然是受限的，無(wú)法滿足所有CSS3標(biāo)準(zhǔn)的實(shí)現(xiàn)，更多通過(guò)緊貼Flutterwidgets的現(xiàn)有能力以及必要的widgets擴(kuò)展，在不破壞single-passlayout的前提下組合出CSS能力。但從Flutter原生開(kāi)發(fā)的角度看，只要Flutter現(xiàn)有的原生能力能夠滿足業(yè)務(wù)需求，那么受限的CSS實(shí)現(xiàn)也一樣可以提供和Flutter對(duì)等的能力解決業(yè)務(wù)問(wèn)題。同時(shí)，通過(guò)受限的CSS可以換來(lái)與Flutter相當(dāng)?shù)母咝阅?，與基于我們?cè)?8年底通過(guò)一個(gè)內(nèi)部項(xiàng)目實(shí)現(xiàn)了這個(gè)思路的原型，通過(guò)使用C++重寫Flutter的widgets、rendering、painting及事低層能力，并在widget上用C++實(shí)現(xiàn)了CSSOM+DSL->Widgets的響應(yīng)式框架，直接從C++層提供render實(shí)現(xiàn)，將傳統(tǒng)由JS承擔(dān)的模板展開(kāi)、tree-diff計(jì)算與渲染工作交給C++層，通過(guò)Flutter提供的Widgetstree到RenderObjects從實(shí)現(xiàn)的簡(jiǎn)單的demo看，相對(duì)小程序的web渲染性能有了大幅的提升。這種方案的問(wèn)題在于和Google代碼庫(kù)分裂后的對(duì)接”這篇文章對(duì)集團(tuán)內(nèi)在這個(gè)方向上嘗試的幾種思路做了較為全面的對(duì)比，未來(lái)我Flutter體系化建設(shè)目前在淘系剛剛起步，仍然有大量工作需要去做，我們?cè)诨A(chǔ)設(shè)施、工程化以及通過(guò)Flutter定義和收斂業(yè)務(wù)域研發(fā)模式上做的許多建設(shè)性的事情，正朝著把Flutter打造為統(tǒng)一移動(dòng)應(yīng)用基礎(chǔ)研發(fā)框架，助力業(yè)務(wù)回歸移動(dòng)端研發(fā)模式這個(gè)大目標(biāo)一點(diǎn)點(diǎn)邁進(jìn)。在移動(dòng)技術(shù)小組啟效升級(jí)，拿到了很好的業(yè)務(wù)成績(jī)；另一方面沉淀Flutter的技術(shù)與業(yè)務(wù)解決方案，并也涌現(xiàn)出一眾Flutter技術(shù)專家。接下來(lái)AliFlutter的重點(diǎn)任務(wù)，就是要和閑魚(yú)、財(cái)富等先驅(qū)應(yīng)用者以及盒馬、釘釘、飛豬、優(yōu)酷、餓了么、CBU等Flutter的實(shí)踐者一起，在集團(tuán)層面把Flutter的場(chǎng)子建起來(lái)，把集團(tuán)Flutter生態(tài)拉起來(lái)，讓技術(shù)和真正成為集團(tuán)業(yè)務(wù)的核心研發(fā)模式，并讓每個(gè)參與者都能從中受益。我們一直堅(jiān)信Flutter技術(shù)的先進(jìn)性和應(yīng)用前景，未來(lái)我們將繼續(xù)立足淘系服務(wù)集團(tuán)業(yè)務(wù)，和集團(tuán) AliFlutter客戶端研發(fā)體系概覽摘要：Flutter是開(kāi)源的UI工具包，其能夠幫助開(kāi)發(fā)者通過(guò)一套代碼庫(kù)高效構(gòu)建多平臺(tái)精美應(yīng)用，支持移動(dòng)、Web、桌面和嵌入式平臺(tái)。Flutter組件采用現(xiàn)代響應(yīng)內(nèi)容根據(jù)演講視頻以及PPT整理而成。王康（花名：正物淘寶終端技術(shù)部無(wú)線技術(shù)專家，F(xiàn)lutterMember(kang-wang1988)，AspectD作者。負(fù)責(zé)了Flutter在閑魚(yú)中的混合開(kāi)發(fā)體系建設(shè)與業(yè)務(wù)落地，做了一系列相關(guān)技術(shù)方案。在Flutter原理與應(yīng)用、多端一體化編程方面有豐富一、Flutter原理引擎的方式來(lái)寫APP，使得用戶可以具有很強(qiáng)的靈活性，能夠在像素級(jí)別進(jìn)高效：Flutter類似于安卓小系統(tǒng)，使得其能夠使用一套代碼運(yùn)行在各種各樣的平臺(tái)之上。此外，在Debug模式下還支持熱重載，使其能夠達(dá)到高效的研發(fā)高性能：在Release模式下，F(xiàn)lutter是預(yù)先編譯成機(jī)器碼，執(zhí)行期具有高以上四個(gè)特點(diǎn)的背后就是Flutter的原理。首先，F(xiàn)lutter架構(gòu)在OS之上，最底下是與平臺(tái)相關(guān)的Embedder層，其主要負(fù)責(zé)的工作是Surface、Thread以及EventLoop。在Embedder層之上是Engine，主要包括三部分，DartRuntime； 負(fù)責(zé)將UI繪制到Surface上的Skia，負(fù)責(zé)文本繪制的Text。在Engine之上就是大家所熟知的Dart的Frame阿里巴巴為什么選擇Flutter在阿里巴巴的電商場(chǎng)景下，往往會(huì)有一些非常重要的考量，比如用戶體驗(yàn)的要求，對(duì)于研發(fā)效率的要求，以及如何消除多端之間的差異。在阿里經(jīng)濟(jì)體里面，應(yīng)用面場(chǎng)景、天貓精靈等IoT場(chǎng)景以及各種線下大屏的場(chǎng)景。當(dāng)前，流量增長(zhǎng)紅利不斷減少，需要更多創(chuàng)新玩法為消費(fèi)者提供更好的用戶體驗(yàn)，這就產(chǎn)生了富交互游戲化的需求。Flutter具有的高性能，高研發(fā)效率、跨端一致性，多端多平臺(tái)支持，以及豐富二、Flutter業(yè)內(nèi)現(xiàn)狀Flutter在業(yè)內(nèi)的實(shí)踐現(xiàn)狀主要圍繞著體系化、深度、框架以及更多探索這些維很多東西還不成熟。使用Flutter解決業(yè)務(wù)上線問(wèn)題，需要考慮研發(fā)體系的構(gòu)建。應(yīng)用上線之后，需要監(jiān)控各種指標(biāo)。在深度方面，往往會(huì)關(guān)注引擎大小、包大小、內(nèi)存優(yōu)化以及啟動(dòng)時(shí)間等。除了上述兩部分之外，業(yè)內(nèi)也有很多框架相關(guān)的工作，比如混合?？蚣?、狀態(tài)管理、動(dòng)態(tài)化UI、AOP框架以及生態(tài)插件等。此外還有原生Flutter 三、AliFlutter建設(shè)與深度實(shí)踐AliFlutter業(yè)務(wù)實(shí)踐下圖選取了阿里經(jīng)濟(jì)體中一些應(yīng)用了Flutter的典型場(chǎng)景。比如寶貝詳情是一個(gè)業(yè)務(wù)邏輯非常復(fù)雜的頁(yè)面，屬于圖文互排的頁(yè)面，并且具有大量圖片，有時(shí)還包括一個(gè)視頻播放器，在這個(gè)場(chǎng)景下就全部應(yīng)用了Flutt戲業(yè)務(wù)的開(kāi)發(fā)，比如下圖所示的是盒馬使用Flutter構(gòu)建的一個(gè)游戲頁(yè)面。此外，在之所以選擇Flutter，有幾個(gè)典型原因。首先，HotReoload和跨端一致性使得研發(fā)非常高效；其次，可用于游戲化的豐富UI表達(dá)力、動(dòng)畫(huà)、圖文混排性能等訴求AliFlutter業(yè)務(wù)研發(fā)模型個(gè)問(wèn)題，邏輯和UI。其本身沒(méi)有各種Native能力，需要接入網(wǎng)關(guān)等，使其更加接近于業(yè)務(wù)開(kāi)發(fā)容容器，而不僅僅是UI開(kāi)發(fā)框架。再上面就是應(yīng)用開(kāi)發(fā)框架，比如狀態(tài)管理框架、游戲化框架、動(dòng)態(tài)化UI以及組件庫(kù)，在此之上就可以構(gòu)建一些業(yè)務(wù)了。除此之外還會(huì)涉及到一些研發(fā)協(xié)同方面的工作，比如打包AliFlutter引擎研發(fā)模型在AliFlutter之下，存在很多引擎修改的場(chǎng)景。舉例而言，在iOS13以下可能存在一些后臺(tái)GPU渲染Crash的問(wèn)題，在Android上存在特別機(jī)型Flutter啟動(dòng)閃網(wǎng)絡(luò)庫(kù)等在阿里內(nèi)部都有比較好的實(shí)踐。無(wú)論是Bug修復(fù)還是Native能力提升，其 上圖展示的就是在阿里內(nèi)部對(duì)于Flutter引擎進(jìn)行定制所做工作的邏輯，首先通AliFlutter基礎(chǔ)設(shè)施建設(shè)前面所提到的是自定義Flutter引擎的開(kāi)發(fā)流程，而想要將開(kāi)發(fā)完成的東西提供給其他人使用，就需要如圖所示的自定義引擎服務(wù)了。對(duì)于Flutter開(kāi)發(fā)者而言，只需設(shè)置一個(gè)環(huán)境變量去服務(wù)上查詢是否有對(duì)應(yīng)的產(chǎn)物即可，如果有的話，就做一些定制并返回給開(kāi)發(fā)者；如果沒(méi)有則去官方上游拉取。當(dāng)然了，對(duì)于Flutter的基礎(chǔ)設(shè)施而言，需要有一些多團(tuán)隊(duì)的支持，比如Namespace等機(jī)制。最早的時(shí)候，阿里巴巴通過(guò)Git方式管理自定義引擎，但是Git對(duì)于二進(jìn)制很不友好，所以就使用了高效除此之外，AliFlutter還實(shí)現(xiàn)了私有Pub服務(wù)。最初的想法是將不同人開(kāi)發(fā)的庫(kù)等工作歸類組織起來(lái)，建設(shè)更好的內(nèi)部生態(tài)，實(shí)現(xiàn)更好的復(fù)用。Pub本身就是Flutter所提供的開(kāi)源框架，但是其深度綁定了谷歌云服務(wù)，所以在做這部分的時(shí)候需要將對(duì)于谷歌云的依賴變成對(duì)于阿里內(nèi)部的依賴。主要工作分為兩部分，一部分是對(duì)于包的簡(jiǎn)單管理和存儲(chǔ)，這部分可以通過(guò)阿里云存儲(chǔ)OSS實(shí)現(xiàn)；還有一部分是監(jiān)控包的下載量以及健康程度等，這部分還部署了Meta數(shù)據(jù)庫(kù)服務(wù)，在將包上傳的時(shí)于打包平臺(tái)。Flutter工程可以通過(guò)一些腳本構(gòu)建出一個(gè)Pod起來(lái)變成一個(gè)APP。 AliFlutter深度實(shí)踐比如對(duì)于圖片庫(kù)的優(yōu)化，對(duì)于Flutter而言，本身的圖片庫(kù)存在一些問(wèn)題，比如內(nèi)存占用高，不釋放問(wèn)題、CPU占用問(wèn)題。為了盡可能遵循Flutter原生的圖片庫(kù)邏輯，做了圖片庫(kù)的優(yōu)化。主要工作包括對(duì)于Flutter框架的整體修改，能夠較好地實(shí)現(xiàn)一致性，與官方體系無(wú)縫融合，對(duì)接內(nèi)部圖片庫(kù)，其在性能以及易用性上面也具有較好我們?cè)贔lutter引擎大小優(yōu)化方面也做了不少工作，簡(jiǎn)單介紹對(duì)于庫(kù)的裁剪。如下所示的兩張火焰圖，其較好地表達(dá)了Flutter引擎所依賴的各個(gè)庫(kù)裁剪前后的比例 除了前面所提到的類似于音頻圖片釋放等內(nèi)容之外，阿里在實(shí)踐的過(guò)程中發(fā)現(xiàn)Flutter在大圖片內(nèi)存GC方面存在一些問(wèn)題，比如在用戶退出的時(shí)候內(nèi)存無(wú)法得到很好釋放。對(duì)于社區(qū)中使用Flutter的同學(xué)而言，面對(duì)這樣的問(wèn)題建議大模型下看下點(diǎn)擊了GC按鈕是否能夠?qū)?nèi)存降低下來(lái)?；诖诉壿嬑覀兲峁┝艘籉lutter包含了Skia，可提供Canvas能力。之前的邏輯是通過(guò)Dart調(diào)用En-gine，再調(diào)到Skia，而我們通過(guò)實(shí)踐中對(duì)其部分API的暴露，將Skia的Canvas能力加以透出。在JS部分有一些2D和3D的API，可以將這些暴露成為CanvasAPI，整體而言，相比于Web的Pipeline表現(xiàn)非常不錯(cuò)，這一功能目前已經(jīng)在部分Flutter的AOP框架的核心基于dill變換，dill本身是從Dart代碼到最終代碼之間的中間語(yǔ)言表達(dá)。其原理簡(jiǎn)要來(lái)說(shuō)是當(dāng)我們寫了一個(gè)hello_fultter的時(shí)候，再寫一個(gè)AOP包，AOP的包會(huì)包裹hello_fultter包，使得在AOP包的產(chǎn)物(dill)里面hello_flutter和AOP的邏輯都存在，即其包括兩部分內(nèi)容，hello_flutter本身代碼的dill表達(dá)，以及AOP框架中寫的注解的dill表達(dá)，將這兩者都包含在app.dill里面，基于此我們可以通過(guò)dilltransform方式來(lái)做變換。這里比較復(fù)雜，需要考慮AST抽象語(yǔ)法樹(shù)的各種邏輯。需要將注解提取出來(lái)并基于這些注解進(jìn)行操作，并最終寫入到dill里面去，這些操作處理完成之后，就變成了aop_aspectd.dill，替換掉 四、AliFlutter研發(fā)模式探索AliFlutter研發(fā)模式接下來(lái)分享阿里巴巴在Flutter研發(fā)模式上的一些探索。下圖中最重要的就是研發(fā)模式和跨平臺(tái)運(yùn)行時(shí)，目標(biāo)是提供一種多端多平臺(tái)的能力。在平臺(tái)底層是基礎(chǔ)庫(kù)、網(wǎng)絡(luò)庫(kù)的基礎(chǔ)能力，此外還需要在垂直能力上的擴(kuò)展，支持各種垂直的基礎(chǔ)能力?；A(chǔ)設(shè)施之上是Flutter的跨平臺(tái)運(yùn)行時(shí)，運(yùn)行時(shí)基于FlutterEngine，提供了具有豐富表達(dá)力的圖形接口、跨平臺(tái)、能力拓展、性能以及穩(wěn)定性等。在此之上，F(xiàn)lutterFramework提供了可以復(fù)用的基礎(chǔ)能力，比如核心布局渲染、彈性擴(kuò)展能力、組件能力以及定制性等。除此之外，也有一些研發(fā)支撐上面的工作，比如編譯打包、調(diào)AliFlutter研發(fā)模式展望跨端能力：我們考慮對(duì)于上層的各種平臺(tái)提供標(biāo)準(zhǔn)基礎(chǔ)能力并API化，從而更好在多端多平臺(tái)進(jìn)行部署。此外，還希望通過(guò)Flutter的容器化，使得研發(fā)和交互能力：我們考慮利用Flutter豐富的表達(dá)能力在游戲化方向進(jìn)行更好的擴(kuò)展，以游戲引擎的方式來(lái)開(kāi)發(fā)APP?；诜夯慕换ツ芰σ约案嗟目赏嫘匝邪l(fā)效率：我們考慮實(shí)現(xiàn)工程解耦和云端一體化，目標(biāo)是業(yè)務(wù)方只需關(guān)注所寫的包，通過(guò)很簡(jiǎn)潔的方式集成進(jìn)來(lái)并看到效果，從而提供類似于前端的開(kāi)發(fā)體交付效率：這部分主要包含兩部分，一部分是動(dòng)態(tài)化UI，另外一部分是WebOnFlutter，期望通過(guò)提供更加靈活的動(dòng)態(tài)性，以及前端技術(shù)棧下的動(dòng)態(tài)化 性能、開(kāi)放的特點(diǎn)，以及阿里巴巴為什么選擇Flutter。其次，為大家分享了Flutter的業(yè)內(nèi)現(xiàn)狀，有大量投入的主流廠商，以及體系化、深度、框架和更多的探索。再次，為大家介紹了AliFlutter的建設(shè)與實(shí)踐，包括了業(yè)務(wù)、研發(fā)模型、引擎研發(fā)等方閑魚(yú)研發(fā)框架應(yīng)用和探索摘要：Flutter是開(kāi)源的UI工具包，其能夠幫助開(kāi)發(fā)者通過(guò)一套代碼庫(kù)高效構(gòu)建多平臺(tái)精美應(yīng)用，支持移動(dòng)、Web、桌面和嵌入式平臺(tái)。在AliFlutter系列第二場(chǎng)直播中，阿里巴巴閑魚(yú)無(wú)線技術(shù)專家梁治峰為大家分享了閑魚(yú)在Flutter中研發(fā)框架應(yīng)用和探索，從分別從三個(gè)方向介紹Flutter一體化研發(fā)模式、Flutter動(dòng)態(tài)化能力、本文內(nèi)容根據(jù)演講視頻以及PPT整理而成。 一、閑魚(yú)Flutter研發(fā)框架使用現(xiàn)狀閑魚(yú)是一個(gè)側(cè)重于電商業(yè)務(wù)的平臺(tái)，因此隨著業(yè)務(wù)的不斷增長(zhǎng)，系統(tǒng)的邏輯復(fù)雜度也在不斷提升。因?yàn)閷儆陔娚虡I(yè)務(wù)，所以對(duì)于流量和運(yùn)營(yíng)的數(shù)據(jù)具有較高的需要，因此在閑魚(yú)的體系中也需要具備動(dòng)態(tài)性的能力，并且還需要通過(guò)增加特效的能力來(lái)增二、Flutter研發(fā)框架下一代模式下圖中左側(cè)是傳統(tǒng)的客戶端-服務(wù)器架構(gòu)。在這樣的CS架構(gòu)下，對(duì)于客戶端開(kāi)發(fā)者而言，往往都會(huì)經(jīng)歷相似的痛點(diǎn)。當(dāng)產(chǎn)品的需求過(guò)來(lái)，可能客戶端的開(kāi)發(fā)同學(xué)并不能自己完成，而需要牽扯到服務(wù)端的開(kāi)發(fā)，可能需要對(duì)于協(xié)議進(jìn)行補(bǔ)充或者添加更多的接口能力。而對(duì)于后端開(kāi)發(fā)同學(xué)而言，面對(duì)一個(gè)需求也可能需要領(lǐng)域服務(wù)的支持。這樣一來(lái)，一個(gè)貌似很簡(jiǎn)單的需求，卻需要從客戶端到后端再到領(lǐng)域服務(wù)的相互協(xié)調(diào)，進(jìn)而會(huì)影響需求的排期問(wèn)題。而如果客戶端也可以寫服務(wù)端的代碼，這樣的問(wèn)在目前閑魚(yú)所給予的FaaS框架下的一些場(chǎng)景中也存在上述痛點(diǎn)。如下圖所示的是傳統(tǒng)基于FaaS的模式，可以看出使用FaaS能夠?qū)⑦壿嫼蚒I徹底進(jìn)行分離，但是在端上的邏輯部分，無(wú)外乎兩種，一種是數(shù)據(jù)的拉去和推送，另外一種是數(shù)據(jù)的主賬號(hào)。在后端也會(huì)有類似的邏輯，只不過(guò)此時(shí)不是客戶端找服務(wù)端要數(shù)據(jù)，而是服務(wù)端找各個(gè)領(lǐng)域?qū)右枰臄?shù)據(jù)，然后進(jìn)行數(shù)據(jù)的加工，再將數(shù)據(jù)以面向客戶端協(xié)議的部分進(jìn)行主賬號(hào)推送。而上述兩個(gè)部分存在著一定的邏輯割裂，并且也存在一定的重復(fù)工作，因?yàn)閿?shù)據(jù)轉(zhuǎn)化被執(zhí)行了兩次。那么，是否能夠?qū)⑸鲜鰞煞N邏輯合二為一，并且讓端上的同學(xué)進(jìn)行開(kāi)發(fā)，同時(shí)將邏輯后端化呢？結(jié)合如今Serverless的能力， 基于上述的背景，閑魚(yú)在今年實(shí)現(xiàn)了一體化的研發(fā)解決方案。在云側(cè)兼容了集團(tuán)通用的Gaia容器化能力，用Dart語(yǔ)言實(shí)現(xiàn)了容器化的部分。之所以使用Dart語(yǔ)言來(lái)完成，屏蔽兩者之間的差異。在端側(cè)研發(fā)了Nexus一體化插件，將現(xiàn)在面向Action的部分可以實(shí)現(xiàn)端側(cè)與云側(cè)的一體化。這樣的好處在于在端側(cè)叫Action，在云側(cè)也叫Action，而在端上進(jìn)行開(kāi)發(fā)的時(shí)候并沒(méi)有感知云側(cè)Action的存在，這就是Nexus的核心作用。此外，現(xiàn)在面向于通信協(xié)議其實(shí)就是面向于API接口的一部分，這里簡(jiǎn)單介紹一下一體化框架的具體落地場(chǎng)景。對(duì)于下圖所示的閑魚(yú)下單的頁(yè)面而言，在原有模式下可能需要5個(gè)請(qǐng)求接口，這部分請(qǐng)求接口可能部分在端上，部分在云上，并且通過(guò)一條信息流進(jìn)行合并。這種情況下如果需要修改某種狀態(tài)就會(huì)非常復(fù)雜。在改造完成之后就將原來(lái)的5個(gè)請(qǐng)求接口全部實(shí)現(xiàn)Action協(xié)議化，這樣的好處在于云端的模型統(tǒng)一了，無(wú)論是對(duì)于云還是客戶端都在寫同樣的邏輯，只不過(guò)這樣的邏輯部署到了云上。其次，還屏蔽掉了協(xié)議的具體部分，只留下了協(xié)議名稱。第三點(diǎn)好處在于實(shí)現(xiàn)了邏輯的歸一，所有的邏輯都實(shí)現(xiàn)了云端化，大家在書(shū)寫這樣的邏輯時(shí)不會(huì)存在割裂，最終書(shū)寫的邏輯都是面向云模型的狀態(tài)。第四個(gè)優(yōu)點(diǎn)是冗余代碼將會(huì)大大減少。而最大的好處在于形成了很好的業(yè)務(wù)的閉環(huán)，讓客戶端開(kāi)發(fā)也可以應(yīng)用三、Flutter研發(fā)框架下動(dòng)態(tài)能力閑魚(yú)本質(zhì)上主要是一個(gè)電商業(yè)務(wù)平臺(tái)，其在于流量側(cè)具有強(qiáng)運(yùn)營(yíng)時(shí)效的特性，很多的運(yùn)營(yíng)活動(dòng)或者決策需要得到及時(shí)的響應(yīng)，如果在這種情況下不具有動(dòng)態(tài)性就會(huì)陷入被動(dòng)。完整的動(dòng)態(tài)性包括了邏輯動(dòng)態(tài)性和UI動(dòng)態(tài)性，但是在流量側(cè)部分更加注重 動(dòng)態(tài)模板在阿里巴巴整個(gè)集團(tuán)內(nèi)部都是一套比較成熟的解決方案。首先，通過(guò)DX平臺(tái)編輯模板，編輯成二進(jìn)制文件并生成模板下載鏈接，之后模板下載解壓，進(jìn)行表達(dá)式或者事件的注冊(cè)，并對(duì)于數(shù)據(jù)進(jìn)行綁定解析，使得組件得到渲染。借助于集團(tuán)動(dòng)態(tài)模板的成熟方案，所需要解決的就是在Flutter側(cè)如何滿足DSL的UI表達(dá)，核心問(wèn)題-Layout合實(shí)現(xiàn)的。根據(jù)Flutter的源碼可以看出，在其布局表達(dá)里面，樣式、布局、內(nèi)容三個(gè)要素表達(dá)是徹底分離的。相反而言，在安卓的DSL的架構(gòu)里面，樣式和布局是結(jié)雖然描述部分可以很容易地做映射，但是核心困難在于布局部分，主要是關(guān)于大小的而以上兩種都是感性描述的約束性布局。除此之外，還提供了30多個(gè)布局的容器部分。這是因?yàn)榛谏厦娴母行悦枋龅募s束布局情況下，F(xiàn)lutter可能會(huì)存在大量的冗余代碼，在約束布局情況下就會(huì)顯得特別復(fù)雜。另外一部分在于性能部分，感性描述觀安卓的布局部分，相對(duì)比較少，大約為4、5個(gè)，所以這里的問(wèn)題就是如何將安卓的布局部分使用Flutter的布局來(lái)表達(dá)或者描述。如果想要使用特性來(lái)做映射是很困如果在端側(cè)已經(jīng)完成對(duì)于動(dòng)態(tài)模板樹(shù)形結(jié)構(gòu)的解析之后，就能夠很容易地將樹(shù)形結(jié)構(gòu)的節(jié)點(diǎn)實(shí)現(xiàn)如下圖所示的一拆三結(jié)構(gòu)。第一層是裝飾層結(jié)構(gòu)，中間層可以基于自低向上和自頂向下的計(jì)算規(guī)則重新計(jì)算出大小，最后一部分則是將內(nèi)容想要表達(dá)的葉子界面進(jìn)行Backup。為了實(shí)現(xiàn)安卓這樣的布局結(jié)構(gòu)阿里巴巴引入了安卓的SpecMin_width的最大估算來(lái)預(yù)估大小部分，再?gòu)淖缘紫蛏蟻?lái)計(jì)算出實(shí)際的Size。動(dòng)態(tài) 整套方案經(jīng)過(guò)閑魚(yú)一整年的打磨之后，已經(jīng)有大量的業(yè)務(wù)上線和應(yīng)用了。無(wú)論是動(dòng)態(tài)性部分往往會(huì)和性能存在一定的博弈。在閑魚(yú)的實(shí)踐中得到的實(shí)際結(jié)果表明，使用動(dòng)態(tài)模板的DSL來(lái)表達(dá)的性能還可以接受，線上的實(shí)際效果大約在55幀雖然目前的方案和Flutter原生僅存在5幀的差距，但是如果能夠進(jìn)一步優(yōu)化，還是有可能達(dá)到原生的性能要求的。下圖中分別展現(xiàn)了使用Flutter原生和DX寫的卡片布局，可以直觀地發(fā)現(xiàn)在Flutter原生使用了大量的高階型特性表達(dá)，在DX中則基本都是常見(jiàn)的容器布局，并且樹(shù)形結(jié)構(gòu)的深度層次遠(yuǎn)遠(yuǎn)大于Flutter原生。DX中使得長(zhǎng)度變大的部分在于裝飾性的布局部分，因此可以嘗試地探索在DSL的表達(dá)部分將Padding在容器層進(jìn)一步縮短結(jié)構(gòu)，可能會(huì)提高FPS，也就是將現(xiàn)在的簡(jiǎn)單 四、Flutter研發(fā)框架下互動(dòng)能力在電商領(lǐng)域的業(yè)務(wù)里面，很多業(yè)務(wù)想要通過(guò)游戲化的方式創(chuàng)造更有表現(xiàn)力的交互體驗(yàn)，創(chuàng)造新的業(yè)務(wù)玩法和價(jià)值。傳統(tǒng)的UI表達(dá)方式，越往后就會(huì)越受限，因此需UI的豐富控件能力。在傳統(tǒng)APP的框架下，所能夠做的無(wú)外乎嫁接游戲引擎，而這樣的游戲引擎和原來(lái)的APP是格格不入，也是不相通的，其能夠帶來(lái)的最大效果就是開(kāi)辟一個(gè)獨(dú)立的頁(yè)面來(lái)承載游戲，但這樣的方式似乎不是所想要達(dá)到的設(shè)計(jì)理念。在Flutter側(cè)，今年推出了Flame這個(gè)游戲框架，其解決了單邊引用的過(guò)程。F使得在Flutter框架里面可以將游戲的控件進(jìn)行合攏，但是無(wú)法實(shí)現(xiàn)在游戲里面合攏UI界面，因此提供了單邊能力。Flame雖然沒(méi)有完全解決雙邊打通的訴求，但是還核心問(wèn)題-融合目前而言，所需要解決的核心問(wèn)題就是將UI和游戲引擎融合。Flame的表現(xiàn)形式其實(shí)就是將完整的游戲封裝在起來(lái)，能夠很好地將游戲插入到UI中。假如將Flame游戲引擎的表達(dá)也用類似于RenderObject樹(shù)形結(jié)構(gòu)的表達(dá)，就會(huì)形成兩棵Flutter體系下的樹(shù)結(jié)構(gòu)，能夠很好地進(jìn)行融合比對(duì)。閑魚(yú)在這樣的思路下進(jìn)行了新的探索和嘗試，重新設(shè)計(jì)了一套互動(dòng)游戲引擎，彌補(bǔ)了Fl Candy整體設(shè)計(jì)Candy是符合ECS標(biāo)準(zhǔn)的，與Flutter高度融合的原生開(kāi)發(fā)高性能互動(dòng)開(kāi)發(fā)框架。Candy在架構(gòu)設(shè)計(jì)上完全按照ECS的標(biāo)準(zhǔn)；在接口設(shè)計(jì)上對(duì)齊了阿里巴巴集團(tuán)的互動(dòng)EVA，使得集團(tuán)內(nèi)部在使用時(shí)不會(huì)對(duì)于接口感到陌生；在應(yīng)用能力上，Candy完全融入了Flutter的繪制體系；在擴(kuò)展能力上，Candy能力的補(bǔ)充，能夠滿足UED主流能力，使得不同公司或者行業(yè)開(kāi)發(fā)者能夠更好地使能夠非常簡(jiǎn)單地將游戲以Widget形式插入到Flutter頁(yè)面中，而這對(duì)于使用者而言不會(huì)產(chǎn)生任何感知。此外，對(duì)于傳統(tǒng)應(yīng)用的開(kāi)發(fā)者，也能夠很輕松地將具有動(dòng)畫(huà)能效果-骨骼目前，閑魚(yú)的內(nèi)部方案能夠很好地實(shí)現(xiàn)龍骨的動(dòng)畫(huà)。正是因?yàn)樵谧酉到y(tǒng)中保留了這樣的能力，所以如果未來(lái)有其他方案也可以按照ECS標(biāo)準(zhǔn)進(jìn)行主流格式的實(shí)現(xiàn)。 效果-調(diào)試值得一提的是因?yàn)橐婧蚒I不分家，使得在調(diào)試工具的使用過(guò)程中能夠更好地基于Render層的設(shè)計(jì)使得我們享受到了Flutter引擎?zhèn)葘?duì)于Canvas的優(yōu)化，也享受到了在FlutterFramework上局部刷新能力，因此無(wú)論是實(shí)現(xiàn)粒子還是實(shí)現(xiàn)開(kāi)源框架具有足夠的能力能夠讓大家在其布局側(cè)進(jìn)行進(jìn)一步深挖。此外，還和大家分開(kāi)發(fā)框架。而單點(diǎn)技術(shù)難以形成全面的合力，因此在后面與大家分享了將現(xiàn)有能力組合的情況產(chǎn)生不同的體系。假設(shè)將FaaS遠(yuǎn)端的動(dòng)態(tài)能力結(jié)合Nexus一體化能力、DX基于UI的表達(dá)能力，似乎就可以通過(guò)SSR寫完整的UI部分。同理，F(xiàn)aaS結(jié)合Candy也能夠?qū)崿F(xiàn)互動(dòng)編排的能力，將互動(dòng)能力在FaaS端進(jìn)行表達(dá)。 AliFlutter圖片解決方案與優(yōu)化摘要：Flutter與Native混合開(kāi)發(fā)將是接下來(lái)很長(zhǎng)時(shí)間的主流開(kāi)發(fā)方式。一套穩(wěn)定、高效、與官方體系無(wú)縫融合的外接圖片緩存方案是必不可少的。在AliFlutter系列第三場(chǎng)直播中，由阿里巴巴新零售淘系技術(shù)部無(wú)線開(kāi)發(fā)專家王乾元為大家介紹AliFlutter提供的適合混合應(yīng)用的外王乾元，花名神漠，13年加入阿里，先后負(fù)責(zé)過(guò)天貓、支付寶、手機(jī)淘寶App的iOS架構(gòu)工作。目前在AliFlutter團(tuán)隊(duì)負(fù)責(zé)基礎(chǔ)組件、iOS架構(gòu)，以及引擎、工具以下內(nèi)容根據(jù)演講視頻以及PPT整理而成。一、Flutter如何顯示、加載圖片1.線程PlatformThread：IOS與安卓平臺(tái)層應(yīng)用的主線程。進(jìn)行FlutterEngineEngine。IOThread：進(jìn)行圖片上傳。圖片在IOThread進(jìn)行異步上傳生成GPUGPUThread：負(fù)責(zé)Flutter最終的GPU調(diào)用。WorkerThread：Flutter中的fml會(huì)創(chuàng)建若干個(gè)并發(fā)工作線程。可進(jìn)行圖片傳，在引擎啟動(dòng)時(shí)創(chuàng)建的ShellIOManager會(huì)創(chuàng)建OpenGLContext。同時(shí)GPUThread創(chuàng)建GPUContext。IOContext與GPUContext將存放在ShareGroup中共享紋理。Flutter中紋理對(duì)象是C++的對(duì)象，在Flutter底層不會(huì)對(duì)紋理對(duì)象進(jìn) 2.圖片加載、顯示流程圖片加載用到Flutter的ImageWidget，一般是使用其“.network”接口加載網(wǎng)絡(luò)圖片。ImageWidget進(jìn)行顯示繪制時(shí)需要ImageState。ImageState有兩個(gè)功能，一是驅(qū)動(dòng)Provider下載圖片，二是調(diào)用State管理底層Renderobject。pleter作為L(zhǎng)istener。StreamCompleter可以添加多個(gè)ImageStream作為L(zhǎng)is-創(chuàng)建底層C++解碼器的C++對(duì)象。解碼器對(duì)象獲取圖片流后在底層進(jìn)行異步解碼，并生成紋理。ImageState接收到事件后獲取紋理對(duì)象繪制圖片。上層獲取圖片紋理后會(huì)調(diào)用ImageState的SetState方法將紋理對(duì)象傳給底層Renderobject，排版底層紋理對(duì)象會(huì)被上層Dart對(duì)象引用，具體為以下幾個(gè)對(duì)象。StreamCom-pleter負(fù)責(zé)驅(qū)動(dòng)底層解碼器獲取紋理對(duì)象。因此StreamCompleter會(huì)持有底層GPU紋理，并通過(guò)Listeners通知所有ImageState。因此ImageState也會(huì)持有紋理對(duì)象。ImageState將圖片傳給底層Renderobject，因此Renderobject也會(huì)持有紋理對(duì)象。當(dāng)上層ImageWidget被銷毀，ImageCache清空時(shí)，觸發(fā)底層紋Flutter加載顯示圖片的流程包括了圖片的組件、下載、解碼、上傳、繪制等工二、AliFlutter圖片解決方案優(yōu)化1.問(wèn)題首先，利用Flutter制作淘寶商品詳情頁(yè)面，圖片多，內(nèi)存、CPU等占用非常高，性能要求高。Flutter圖片管理能力較弱，缺乏本地緩存能力，圖片的重復(fù)下載第二，電商APP需要與Native圖片庫(kù)對(duì)接，共享緩存、CDN能力以及監(jiān)控小程序、Canvas等多種場(chǎng)景。 2.AliFlutter圖片解決方案總體架構(gòu)下圖紅色標(biāo)簽為AliFlutter方案的重點(diǎn)。在Dart層實(shí)現(xiàn)了新的Provider，在C++層實(shí)現(xiàn)了新的解碼器對(duì)象，并基于Flutter規(guī)范提供了不同平臺(tái)的ObjC、安卓的Java接口。高性能：優(yōu)化CPU、內(nèi)存占用，增強(qiáng)List回收能持更多圖片格式。將平臺(tái)層解碼后的bitmap返回給解碼器對(duì)象，通過(guò)位圖數(shù)據(jù)進(jìn)行一次完整圖片加載過(guò)程時(shí)序圖：首先從ImageWidget拿到圖片請(qǐng)求URL，調(diào)用到底層解碼器對(duì)象的getNextFrame方法會(huì)將請(qǐng)求異步上傳給對(duì)接的Native圖片庫(kù)。由Native圖片庫(kù)做請(qǐng)求，獲取平臺(tái)層的圖片對(duì)象或Buffer，將圖片對(duì)象返回給解碼器對(duì)象。解碼器對(duì)象在WorkerThread中進(jìn)Thread進(jìn)行圖片的GPU紋理上傳。上傳完成后在UIThread將圖片返回給Dart。 圖片取消：AliFlutter方案相比Flutter原生方案新增了Cancel能力。Widget通過(guò)State將自己添加到Completer的Listeners中。因此Widget銷毀時(shí)會(huì)將自己從Listeners中移除。當(dāng)Completer的Listeners全部清空時(shí)，表示這次圖片請(qǐng)求已經(jīng)不再需要了，調(diào)用底層解碼器對(duì)象的cancel片庫(kù)返回，可以取消下載；如果已經(jīng)返回，還有解碼或上傳GPU過(guò)程，都可以及時(shí)取消操作。Cancel能力可以避免許多無(wú)用的CPU和內(nèi)存的消耗，尤其是電商App3.性能優(yōu)化AliFlutter進(jìn)行了以下層面的優(yōu)化，除圖片取消外，還包括延遲加載、解碼并發(fā)控制、GIF逐幀上傳紋理、增強(qiáng)List回收能力等。Java接口，因此AliFlutter遵循Flutter規(guī)范提供了OC接口與Java接口。IOS平臺(tái)OC接口只需要實(shí)現(xiàn)一個(gè)回調(diào)。OC回調(diào)在對(duì)接圖片庫(kù)時(shí)接收的是URL以及一些參數(shù)，獲取圖片后向底層返回UIImage即可。使用時(shí)可以直接調(diào)用Dart的Image.externalAdapter方法加載一張圖片。在此可以指定placeholder-Provider，可以是AssetImage或其他網(wǎng)絡(luò)圖片，以此可在主圖加載失敗時(shí)加載一張4.增強(qiáng)List回收能力屬性，該屬性默認(rèn)將Cell中所有內(nèi)容繪制到一個(gè)紋理中，下次瀏覽時(shí)若Cell中內(nèi)容 如下圖所示，優(yōu)化前內(nèi)存容易暴增到600+MB甚至1G，幾乎100%會(huì)出現(xiàn)FlutterList特點(diǎn)：FlutterList回收以Cell為單位。下圖所示紅色框部分為屏幕大小。默認(rèn)情況下Flutter默認(rèn)對(duì)所有Cell添加RepaintBoundary。當(dāng)列表滾動(dòng)時(shí)，若Cell1繪制過(guò)，下次繪制時(shí)直接將及紋理上屏即可，無(wú)需繪制內(nèi)部圖文元素。而Cell2會(huì)占用大量?jī)?nèi)存，首先其圖文多，同時(shí)RepaintB因此增強(qiáng)List回收能力首先需要解除對(duì)部分Cell的優(yōu)化流程：假設(shè)一個(gè)ImageWidget在一個(gè)Cell中，正常情況下當(dāng)Cell出現(xiàn)，ImageWidget的寬、高已知情況下，其排版信息是有效的。SetState完成后觸發(fā)底層RenderObject排版與繪制。在繪制圖片過(guò)程中添加一段邏輯判斷圖片是否在屏。若圖片不在屏，不作任何處理。若圖片在屏幕中，進(jìn)行圖片請(qǐng)求獲取真實(shí)圖片后重復(fù)調(diào)用SetState，重新進(jìn)行圖片排版和繪制，并判斷是否在屏。若圖片隨著若ImageWidget的寬、高未知，F(xiàn)lutter只能在獲取圖片后根據(jù)其真實(shí)尺寸進(jìn)行排版。原本底層解碼器對(duì)象持有g(shù)etNextFrame接口，該接口導(dǎo)致GPU紋理的生成。在優(yōu)化后可以不依賴圖片紋理上傳完成再進(jìn)行排版。在流程中添加了RequestSize接口，ImageWidget的寬、高未知時(shí)調(diào)用該接口可以預(yù)先通知底層C++解碼器獲取圖片尺寸。得到圖片尺寸后再?gòu)腟etState開(kāi)始流程，避免了無(wú)效的紋理上傳。 關(guān)鍵代碼：判斷圖片是否在屏是通過(guò)Dart層的ImageRenderObject。其paint方法中進(jìn)行圖片是否在屏的判斷，根據(jù)其是否在屏向上層ImageState發(fā)送回實(shí)現(xiàn)指定Cell不添加RepaintBoundary是通過(guò)建立虛類NoRepaintBound-aryHint。若List檢測(cè)到上層某個(gè)Cell繼承自NoRepaintBoundaryHint，則不給該Cell添加RepaintBoundary。因此可以在每次屏幕滾動(dòng)時(shí)重新進(jìn)行繪制，了解圖片圖片解碼時(shí)通過(guò)ImageCodec接口實(shí)現(xiàn)只獲取圖片尺寸，不上傳紋理。圖片尺總結(jié)起來(lái)，大Cell優(yōu)化就是避免圖片紋理上傳，圖片真正在屏?xí)r，再獲取其紋優(yōu)化效果：經(jīng)過(guò)以上優(yōu)化，List回收能力的增強(qiáng)取得了較好效果。當(dāng)商品詳情頁(yè)面有幾十張大圖在同一列表的同一個(gè)Cell中出現(xiàn)，可以做到僅加載在屏圖片，若圖 5.后續(xù)改進(jìn)功能改進(jìn)：第一，圖片在屏、離屏判斷優(yōu)化。第二，支持圖片庫(kù)返回圖片原始文Flutter圖片解決方案誕生以來(lái)，開(kāi)發(fā)者也進(jìn)行了許多嘗試，創(chuàng)建圖片庫(kù)方案。如下圖所示，開(kāi)發(fā)者可以考慮圖片解決方案是否為純Flutter應(yīng)用，網(wǎng)絡(luò)圖片場(chǎng)景多不多，圖片有無(wú)必要緩存等方面。根據(jù)自己的應(yīng)用場(chǎng)景選擇最適合自己的圖片解 UCFlutter技術(shù)實(shí)踐分享化落地Flutter核心要解決的三類問(wèn)題分別是工程構(gòu)建體系的搭建，性能優(yōu)化和動(dòng)態(tài)性支持。本次分享將由阿里巴巴UC事業(yè)部無(wú)線開(kāi)發(fā)專家劉森森為大家詳細(xì)介紹UC年加入U(xiǎn)C，長(zhǎng)期在UC信息流團(tuán)隊(duì)負(fù)責(zé)信息流業(yè)務(wù)的技術(shù)工作，近一年投入到創(chuàng)新一、Flutter在UC落地的情況1.業(yè)務(wù)落地情況Flutter具備高性能、高效率兩個(gè)特性。UC作為創(chuàng)新事業(yè)群的一部分，以創(chuàng)新為重要使命，希望Flutter可以直接加速UC的創(chuàng)新。目前UC國(guó)內(nèi)有50%的研發(fā)同學(xué)已經(jīng)使用Flutter。從前需要兩端開(kāi)發(fā)的需求現(xiàn)在一端人力就可以支撐，并且前端2.夸克&UC具體業(yè)務(wù)形態(tài)以feed流為主，內(nèi)容以音視頻、圖片、 3.創(chuàng)新產(chǎn)品90%頁(yè)面使用Flutter開(kāi)發(fā)。未來(lái)發(fā)展的方向即UI將盡可能使用Flutter進(jìn)行4.總覽UC落地Flutter有多種場(chǎng)景，目前的階段是將Flutter規(guī)?；涞氐絼?chuàng)新業(yè)務(wù)可快速集成到現(xiàn)有APP。2.工程架構(gòu)集成到現(xiàn)有APP：AddFluttertoExistingAPPs。目前UC使用的是FlutterBoot解決方案。FlutterBoot提供了兩個(gè)核心優(yōu)勢(shì)。一，產(chǎn)物集成和源碼集成可配置。UC中有部分同學(xué)是沒(méi)有用到Flutter的，在開(kāi)發(fā)中應(yīng)該避免由于Flutter打包帶二，F(xiàn)lutterBoot提供Native和Flutter開(kāi)發(fā)兩種視角。Native開(kāi)發(fā)視 Native工程中執(zhí)行Native的構(gòu)建腳本、命令。官方方案只能使用Native開(kāi)發(fā)，無(wú)集成到FlutterAPP：全新APP。推薦使用Flutter官方解決方案，更高效、工程架構(gòu)：Flutter業(yè)務(wù)以Package依賴的工程結(jié)構(gòu)組織。UC是多團(tuán)隊(duì)、多業(yè)務(wù)的開(kāi)發(fā)模式，期望業(yè)務(wù)之間解耦。目前Flutter不支持產(chǎn)物分離，都打包在一起，git管理更加高效直觀。目前UCpub中沉淀了許多業(yè)務(wù)組件和技術(shù)組件。UCpub3.業(yè)務(wù)架構(gòu)業(yè)務(wù)架構(gòu)核心思路是抽象幾個(gè)核心模塊，構(gòu)建架構(gòu)模板，使業(yè)務(wù)開(kāi)發(fā)同學(xué)有一致決方案。UC是FlutterBoost的等。即使UC使用了FlutterBoost，UC希望Flutter頁(yè)面之間的相互跳轉(zhuǎn)是使用原每個(gè)Package使用FlutterRedux，主要是因?yàn)镕lutterRedux能夠解決復(fù)雜場(chǎng)景的狀態(tài)管理。另外許多前端同學(xué)擁有Redux開(kāi)發(fā)經(jīng)驗(yàn)，可以帶領(lǐng)客戶端同UC通過(guò)上述業(yè)務(wù)架構(gòu)約束，使研發(fā)認(rèn)知一致聚焦，4.分層架構(gòu)UC在業(yè)務(wù)層下面構(gòu)建了容器。容器最底層包含端基礎(chǔ)設(shè)施，有阿里巴巴集團(tuán)和UC沉淀多年的移動(dòng)組件。這些組件將被包裝為Flutter基礎(chǔ)組件提供給業(yè)務(wù)。Flutter基礎(chǔ)組件、Flutter容器、端基礎(chǔ)設(shè)施可以打造一致的API層提供給業(yè)務(wù)層去 好處是開(kāi)發(fā)新APP時(shí)，一致的API層均可以復(fù)用。根據(jù)分層架構(gòu)可以做進(jìn)一步思考，一致的API層能否更方便地進(jìn)行業(yè)務(wù)遷移？例如UC正經(jīng)部是在UC里做的，是能否將其方便地孵化為一個(gè)創(chuàng)新APP。UC正經(jīng)部的功能是使用Package依賴，能否方便地將其提取出來(lái)放到其他APP中。這UC通過(guò)以上三種架構(gòu)模板解決Flutter落地到業(yè)務(wù)的效率問(wèn)題。后續(xù)會(huì)隨著社2.業(yè)務(wù)高可用UC的高可用組件在閑魚(yú)高可用基礎(chǔ)上進(jìn)行了升級(jí)，增加了一些指標(biāo)，并支持原itrace：二是將收集到的數(shù)據(jù)上傳到了實(shí)時(shí)監(jiān)控平itrace主要有以下優(yōu)勢(shì)。一，分鐘級(jí)別的實(shí)時(shí)性。二，提供多維度的分析方式。 高可用——頁(yè)面性能：頁(yè)面打開(kāi)流程如下。首先監(jiān)聽(tīng)路由跳轉(zhuǎn)，在路一個(gè)起始點(diǎn)，然后監(jiān)聽(tīng)每一幀的回調(diào)。第一幀回調(diào)視為首幀，打一個(gè)點(diǎn)，繼續(xù)檢測(cè)，直到圖片、文字、視頻等RenderObject出現(xiàn)，打一個(gè)內(nèi)容首幀。內(nèi)容首幀貼近用戶視角。繼續(xù)檢測(cè)直到組件覆蓋度大于60%，打頁(yè)面性能在itrace上的展示形態(tài)如下。將內(nèi)容首幀、可交互時(shí)間全部展示出來(lái)。下方是其實(shí)時(shí)曲線?？梢赃x擇分鐘級(jí)別、小時(shí)級(jí)別、天級(jí)別。每一個(gè)業(yè)務(wù)下可能有多頁(yè)面幀率使用handleBeginFrame和handleDrawFrame計(jì)算每一幀的耗時(shí)。目前頁(yè)面性能僅支持UIThread的監(jiān)控。handleFrame方案是實(shí)時(shí)的，可在發(fā)高可用——維度分析：可以根據(jù)網(wǎng)絡(luò)類型、運(yùn)營(yíng)商、平臺(tái)、客戶端、頁(yè)面版本、高可用——異常收集：此處指Dart異常收集，不包括引擎的異常收集，引擎異 使用Dart提供的runZoned進(jìn)行異常收3.引擎啟動(dòng)優(yōu)化問(wèn)題：通過(guò)高可用監(jiān)控發(fā)現(xiàn)頁(yè)面打開(kāi)的最大問(wèn)題是耗時(shí)，根本原因是引擎初始化一，F(xiàn)lutter初始化時(shí)函數(shù)耗時(shí)長(zhǎng)。例如iOS，在主線程執(zhí)行創(chuàng)建GLContext占用了30%的時(shí)間。在子線程創(chuàng)建RootIsolate占用40%時(shí)間。頁(yè)面渲染之前的一般優(yōu)化策略：一是裁剪，裁剪對(duì)引擎的侵入性較大。二是異步化，最大程度利用CPU。若異步化做得詳細(xì)，入侵性也較大，因此最合理方案是針對(duì)一兩個(gè)較為耗時(shí)的問(wèn)題進(jìn)行優(yōu)化。三是將一些耗時(shí)流程延后或提前。例如在Flutter創(chuàng)建引擎之前UC優(yōu)化方案：一，在子線程預(yù)創(chuàng)建GLContext，引擎初始化時(shí)將復(fù)用GLContext。二，在子線程預(yù)熱RootIsolate。預(yù)熱之后為了不占用內(nèi)存將其關(guān)閉。三，添加變量控制dlopen做一次即可，這個(gè)改動(dòng)后續(xù)會(huì)進(jìn)行更加優(yōu)雅的調(diào)優(yōu)，目標(biāo)是回混合式開(kāi)發(fā)，例如UC和手淘。預(yù)熱的耗時(shí)性能提升了62%，異步方案在部分機(jī)型4.視頻外接紋理外接紋理原理：通過(guò)三個(gè)步驟完成外接紋理流程。第一，F(xiàn)lutter通知Native 目前iOS和安卓的外接紋理流程存在差異。安卓使用到SurfaceTexture，iOS使用到FlutterTexture，需要Native回寫CVPixelBuffer，F(xiàn)lutter內(nèi)部會(huì)將CVPixelBuffer綁定到Texture，當(dāng)CVPixelBuffer數(shù)據(jù)發(fā)生變化，Texture會(huì)向問(wèn)題：大部分解碼出的視頻格式是YUV，但Flutter內(nèi)部CVPixelBuffer需要優(yōu)化：優(yōu)先考慮在iOS端不修改引擎，通過(guò)高速紋理在GPU上把YUV轉(zhuǎn)換為反，通過(guò)BindingAPI也可以將Texture綁定到CVPixelBuffer上。那么向Texture繪制YUV數(shù)據(jù)時(shí)設(shè)置BGRA的轉(zhuǎn)換，這樣兩個(gè)Texture就通過(guò)CVPixelBuffer實(shí)問(wèn)題：Flutter在外接紋理時(shí)使用默認(rèn)的NEAREST算法，會(huì)將紋理附近的幾個(gè)5.圖片組件優(yōu)化-外接紋理方案 收益：圖片組件場(chǎng)景可以享受Native組件庫(kù)成熟的優(yōu)化手段，例如LRU回收，多級(jí)緩存