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