[[321430]]

2019 年無(wú)疑是 Flutter 技術(shù)如火如荼發(fā)展的一年。每一個(gè)移動(dòng)開發(fā)者都在為 Flutter 帶來(lái)的“快速開發(fā)、富有表現(xiàn)力和靈活的 UI、原生性能”的特色和理念而癡狂，從超級(jí) App 到獨(dú)立應(yīng)用，從純 Flutter 到混合棧，開發(fā)者們?cè)诓煌膱?chǎng)景下樂此不疲的探索和應(yīng)用著 Flutter 技術(shù)，也在面臨著各種各樣不同的挑戰(zhàn)。

為什么是 Flutter

集團(tuán)內(nèi)已有越來(lái)越多的業(yè)務(wù)和團(tuán)隊(duì)開始嘗試 Flutter 技術(shù)棧，從閑魚的一支獨(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)越多的開發(fā)者選擇擁抱 Flutter 技術(shù)棧?Flutter 的哪些優(yōu)勢(shì)吸引了集團(tuán) Native 開發(fā)者們通過(guò) Flutter 開發(fā)并交付業(yè)務(wù)?

從技術(shù)上看，個(gè)人認(rèn)為 Flutter 最核心的 3 個(gè)特點(diǎn)最為吸引開發(fā)者：

• 極高的開發(fā)與交付效率，良好的開發(fā)體驗(yàn)
• 優(yōu)秀的跨多端多平臺(tái)能力
• 極強(qiáng)的 UI 表現(xiàn)力

開發(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ú)差異的同時(shí)跑在 iOS 與 Android 兩端;開發(fā)體驗(yàn)基本接近前端，支持on device的Hot Reload，去年年底Flutter又推出了在 Android Studio 中通過(guò)插件實(shí)現(xiàn)實(shí)時(shí)預(yù)覽并支持交互的 Hot UI 能力，以及 Layout Explorer 可視化布局，讓 Flutter 的開發(fā)效率和前端效率基本持平。

跨多端多平臺(tái)

電商業(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ù)的交付門檻。可以說(shuō)目前集團(tuán)內(nèi)的跨多端多平臺(tái)方案是實(shí)質(zhì)缺失的。

Flutter 從設(shè)計(jì)上就天然支持多平臺(tái)開發(fā)，它的底層基于 Skia 跨平臺(tái)圖形引擎，向上構(gòu)建出了一整套平臺(tái)無(wú)關(guān)的渲染體系和事件處理體系，并緊貼 Native 研發(fā)模式自定義了基于 widgets 的聲明 + 響應(yīng)式編程范式，對(duì)系統(tǒng)能力依賴度低，并具備出色的跨平臺(tái)還原度;支持多平臺(tái)也是 Flutter 的戰(zhàn)略目標(biāo)之一，目前除了 iOS 和 Android，官方宣布支持的平臺(tái)有 Mac、Windows 和 Web，Linux 也在開發(fā)中，它的技術(shù)特性也讓將 Flutter 移植到 Linux based IoT 平臺(tái)上成本很低，同時(shí) Flutter 還是未來(lái) Google 的下一代操作系統(tǒng)Fuschia的官方應(yīng)用研發(fā)框架?？梢哉f(shuō) Flutter 已經(jīng)具備了成為下一代跨多端多平臺(tái)研發(fā)模式的一切條件，圍繞 Flutter 建立集團(tuán)的多端多平臺(tái)研發(fā)體系是非常可行的選擇。

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)畫能力，開發(fā)者可以非常容易的實(shí)現(xiàn)復(fù)雜的動(dòng)畫效果和交互體驗(yàn)，而基于 Native UI，需要借助各種動(dòng)畫特效三方庫(kù)，雙端開發(fā)體驗(yàn)不一致，實(shí)現(xiàn)復(fù)雜且交付效率低。Flutter 很好的解決了這個(gè)問題，從補(bǔ)間(Tween)動(dòng)畫、基于物理屬性的動(dòng)畫，到相對(duì)復(fù)雜的頁(yè)面間 Hero 動(dòng)畫、parallax 交錯(cuò)動(dòng)畫等特效，F(xiàn)lutter 都可以跨平臺(tái)低成本的高效實(shí)現(xiàn)。這里貼一個(gè)去年年底 Flutter Interact 大會(huì)上 GSkinner 公布的基于 Flutter 實(shí)現(xiàn)的交互 Demo 讓大家直觀感受一下：

可以看到 Flutter 的強(qiáng)大 UI 表現(xiàn)力，可以幫助開發(fā)者快速高效低成本的開發(fā)出極為炫酷的 UI，非常適合電商領(lǐng)域重 UI 視覺交互的各類場(chǎng)景，幫助業(yè)務(wù)構(gòu)建出富有表現(xiàn)力的頁(yè)面。

Flutter 體系化建設(shè)現(xiàn)狀

目前集團(tuán)內(nèi)有多個(gè)業(yè)務(wù) BU 均已開始嘗試應(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 開發(fā)者生態(tài)還未完全拉通，暫時(shí)未能形成合力。這些問題將是我們后面在集團(tuán)層面建設(shè) Flutter 技術(shù)體系的重點(diǎn)。

另一方面從行業(yè)趨勢(shì)上看，F(xiàn)lutter 技術(shù)已經(jīng)成為越來(lái)越多行業(yè)伙伴重點(diǎn)投入的技術(shù)建設(shè)方向。字節(jié)跳動(dòng)、美團(tuán)等公司均建設(shè)了自己的 Flutter 工程化體系，并服務(wù)了各自的業(yè)務(wù)場(chǎng)景;騰訊也基于 Flutter 在多個(gè) App 上進(jìn)行了應(yīng)用嘗試，并在 Flutter 渲染能力服務(wù)小程序的場(chǎng)景下做了有益探索。行業(yè)伙伴們?cè)?Flutter 技術(shù)上的投入力度和決心，一方面讓我們對(duì) Flutter 技術(shù)的應(yīng)用前景和社區(qū)更有信心，另一方面也讓我們感到聯(lián)合集團(tuán)各方力量共建 Flutter 生態(tài)的必要性和緊迫性。

手淘的嘗試和思考

最后，簡(jiǎn)單講一下我們從 18 年到現(xiàn)在在 Flutter 上做的探索和思考。手淘從 18 年 10 月開始探索 Flutter 渲染引擎應(yīng)用在小程序場(chǎng)景;19 年下半年開始建設(shè) Flutter 基礎(chǔ)能力，并服務(wù)了淘寶特價(jià)版業(yè)務(wù)，在引擎、圖片庫(kù)、內(nèi)存優(yōu)化和加載性能等關(guān)鍵技術(shù)上做了沉淀;同時(shí)通過(guò)對(duì) Flutter 的引擎改造，封裝出 Flutter 2D Canvas 能力，向上支持小程序 Canvas 組件及小游戲引擎，服務(wù) 2D/2.5D 游戲化業(yè)務(wù)，并在業(yè)務(wù)場(chǎng)景中落地。在這個(gè)過(guò)程中，我們也沉淀了解決內(nèi)存問題和圖片問題等方案，以及 Flutter 技術(shù)與 Web 技術(shù)的對(duì)比與思考，取得了一定的技術(shù)及業(yè)務(wù)價(jià)值。

通過(guò)這些嘗試，加深了我們對(duì) Flutter 技術(shù)的掌控力和理解。在我們看來(lái)，F(xiàn)lutter 的橫空出世，完全可以被看作吹響了 Native 體系復(fù)興的號(hào)角。在保持 Native 性能優(yōu)勢(shì)的前提下，F(xiàn)lutter 帶來(lái)了優(yōu)秀的跨端一致性、貼近前端的研發(fā)效率，以及強(qiáng)大的 UI 表現(xiàn)力，為集團(tuán)業(yè)務(wù)使用 Native 技術(shù)棧帶來(lái)了新的可能。

從業(yè)務(wù)應(yīng)用上看，F(xiàn)lutter 目前帶來(lái)的最大價(jià)值是研發(fā)效率的提升。在基建和 native 擴(kuò)展能力完備的前提下，開發(fā)基于 Flutter 的純 Dart 業(yè)務(wù)的人效比之前各端分別開發(fā)的效率提高了接近 2 倍，單位時(shí)間內(nèi)的需求響應(yīng)能力也相應(yīng)提高了接近 2 倍，目前已在閑魚和特價(jià)版業(yè)務(wù)開發(fā)中得到了很好的工程化驗(yàn)證。從適應(yīng)場(chǎng)景看，F(xiàn)lutter 目前比較適合承載富圖文內(nèi)容，如詳情、Feeds 流、用戶主頁(yè)等常規(guī)業(yè)務(wù)開發(fā)，以及 2D/2.5D 游戲場(chǎng)景以及富動(dòng)效業(yè)務(wù)。Flutter 通過(guò)單端技術(shù)棧可以同時(shí)滿足以前需要 iOS、Android 以及前端技術(shù)棧分別負(fù)責(zé)的業(yè)務(wù)場(chǎng)景，甚至可以通過(guò)端云一體化的開發(fā)模式使用 Dart 負(fù)責(zé)一部分服務(wù)端業(yè)務(wù)邏輯開發(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ì)需要一起思考和判斷的，這里不展開談;動(dòng)態(tài)性能力是 Flutter 的相對(duì)短板，目前能夠通過(guò) Flutter 模板化技術(shù)實(shí)現(xiàn)基于模板的組件級(jí)動(dòng)態(tài)化能力，但基于性能、審核及對(duì)原生 Flutter 體系的侵入性等多種因素，目前還不能去直接實(shí)現(xiàn) UI + 邏輯動(dòng)態(tài)化能力。Flutter Web 方案雖然不存在審核限制，但受限于瀏覽器 DOM API 與 widgets 體系的差異性，目前仍舊存在較嚴(yán)重的性能瓶頸和渲染差異性，僅可作為降級(jí)的備用方案，暫時(shí)無(wú)法作為動(dòng)態(tài)化的主要實(shí)現(xiàn)方案。未來(lái)在動(dòng)態(tài)化方向的探索也將是個(gè)長(zhǎng)期的博弈過(guò)程。如果后面我們可以解決好 Flutter 動(dòng)態(tài)化的問題，那么 Flutter 完全有機(jī)會(huì)成為集團(tuán)業(yè)務(wù)的核心研發(fā)模式之一。

綜上我們認(rèn)為，入局 Flutter 的時(shí)機(jī)已成熟，合力共建 Flutter 集團(tuán)移動(dòng)生態(tài)，這件事情大有可為。

AliFlutter - 阿里集團(tuán)的 Flutter 體系化建設(shè)

在這樣的背景下，經(jīng)濟(jì)體移動(dòng)技術(shù)小組今年也將端側(cè)架構(gòu)治理的重點(diǎn)方向放在了 Flutter 上。移動(dòng)技術(shù)小組從戰(zhàn)略角度提出了 AliFlutter 項(xiàng)目，目標(biāo)非常明確：

• 從經(jīng)濟(jì)體層面拉通 Flutter 體系建設(shè)，打造 Flutter 的公共技術(shù)基礎(chǔ)設(shè)施，制定 Flutter 容器、中間件與 API 標(biāo)準(zhǔn)，建設(shè) Flutter 研發(fā)支撐與數(shù)據(jù)運(yùn)維能力，復(fù)用關(guān)鍵技術(shù);
• 聯(lián)合各BU構(gòu)建經(jīng)濟(jì)體 Flutter 技術(shù)社區(qū)，沉淀共享集團(tuán) Flutter 技術(shù)及業(yè)務(wù)組件、能力與解決方案，服務(wù)集團(tuán) Flutter 業(yè)務(wù)，共建集團(tuán) Flutter 技術(shù)生態(tài);
• 在經(jīng)濟(jì)體層面構(gòu)建 Flutter 的對(duì)外影響力，聯(lián)合各BU一致對(duì)外，打造阿里在行業(yè)內(nèi)的Flutter技術(shù)制高點(diǎn)。

為經(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)的 Flutter 業(yè)務(wù)提供一個(gè)基礎(chǔ)的 Flutter 公共研發(fā)服務(wù)能力，搭建好技術(shù)共建共享的基礎(chǔ)和平臺(tái)。

第二步，我們要服務(wù)好 Flutter 業(yè)務(wù)應(yīng)用，探索業(yè)務(wù)應(yīng)用模式與 Flutter 技術(shù)特性的結(jié)合點(diǎn)，并在過(guò)程中打磨技術(shù)，形成針對(duì)業(yè)務(wù)特點(diǎn)的解決方案與技術(shù)沉淀，真正盤活集團(tuán)內(nèi)的 Flutter 社區(qū)共建氛圍與生態(tài)。

第三步，面向未來(lái)，解決好 Flutter 應(yīng)用的幾個(gè)核心關(guān)鍵問題：跨端與交互能力、業(yè)務(wù)研發(fā)效率與業(yè)務(wù)交付效率，通過(guò)技術(shù)賦能業(yè)務(wù)，讓 Flutter 真正成為集團(tuán)移動(dòng)業(yè)務(wù)的核心研發(fā)模式。

接下來(lái)，就詳細(xì)講一講每個(gè)階段 AliFlutter 所做的工作和面向未來(lái)的思考。

基礎(chǔ)設(shè)施建設(shè)

從 19 年 10 月 AliFlutter 項(xiàng)目啟動(dòng)開始到現(xiàn)在，我們基本構(gòu)建起了一套 Flutter 的公共基礎(chǔ)設(shè)施，包括 Artifacts 與 pub 庫(kù)，F(xiàn)lutter 標(biāo)準(zhǔn)容器與 API 標(biāo)準(zhǔn)，并實(shí)現(xiàn)了 Flutter 的構(gòu)建打包自動(dòng)化，定義了標(biāo)準(zhǔn)的引擎定制工作流與業(yè)務(wù)研發(fā)工作流。目前基礎(chǔ)設(shè)施已經(jīng)具備支撐集團(tuán) Flutter 業(yè)務(wù)研發(fā)的能力，并支持各 BU 按需定制。

Artifacts 倉(cāng)庫(kù)

產(chǎn)物服務(wù)器主要是為了配合引擎定制，加速通過(guò) Flutter 命令獲取 Engine 中間產(chǎn)物的后端服務(wù)，便于統(tǒng)一 Flutter 開發(fā)者的工作環(huán)境。開發(fā)者可通過(guò)設(shè)置 FLUTTER_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)物。

pub 倉(cāng)庫(kù)

類似于 Node.js 世界的 npm，F(xiàn)lutter 使用 pub 來(lái)管理三方組件與依賴?？紤]到易用性、安全性等需求，為了管理集團(tuán)內(nèi)的公共二方組件，我們也搭建了內(nèi)網(wǎng)環(huán)境的 Flutter pub 庫(kù)。

該庫(kù)的目標(biāo)是成為集團(tuán)的 pub 發(fā)布平臺(tái)，管理集團(tuán)內(nèi)所有二、三方 pub package。用戶可通過(guò)設(shè)置 PUB_HOSTED_URL 指向內(nèi)部地址，來(lái)實(shí)現(xiàn)通過(guò) Flutter 工具鏈獲取配置以及發(fā)布二方 pub 的能力，用戶也可以通過(guò) Web portal 的方式訪問 pub 庫(kù)并查詢已發(fā)布的 pub 組件。

容器、中間件與 API

對(duì)于業(yè)務(wù)的接入而言，現(xiàn)階段核心要解決的問題就是提供一個(gè)統(tǒng)一的 Flutter 運(yùn)行時(shí)容器，以及一系列集團(tuán)標(biāo)準(zhǔn)化移動(dòng)中間件的 Flutter 封裝與 API 能力，并提供集團(tuán)標(biāo)準(zhǔn)的插件擴(kuò)展方式供業(yè)務(wù)方獨(dú)立開發(fā)業(yè)務(wù)功能。

鑒于集團(tuán)應(yīng)用基本上均以混合棧為主，我們將 FlutterBoost 作為 Flutter 容器混合棧的基礎(chǔ)，并配合集團(tuán)標(biāo)準(zhǔn)路由與導(dǎo)航中間件提供了統(tǒng)一的混合棧路由導(dǎo)航能力，業(yè)務(wù)通過(guò)標(biāo)準(zhǔn)路由注冊(cè)即可快速實(shí)現(xiàn) Flutter 頁(yè)面和 Native 頁(yè)面的混合導(dǎo)航能力。

容器通過(guò)對(duì)接高可用平臺(tái)，提供了初始化性能埋點(diǎn)與 Crash 數(shù)據(jù)上報(bào)等標(biāo)準(zhǔn)監(jiān)控能力，為 Flutter 業(yè)務(wù)的技術(shù)性能分析和問題排查提供了基礎(chǔ)。

集團(tuán)移動(dòng)端積累了一整套的標(biāo)準(zhǔn)中間件體系，包括網(wǎng)絡(luò)庫(kù)、圖片庫(kù)、push 消息、配置下發(fā)、數(shù)據(jù)采集與監(jiān)控等一系列基礎(chǔ)能力，在 Flutter 體系內(nèi)無(wú)縫使用移動(dòng)中間件能力對(duì)于業(yè)務(wù)是剛需;同時(shí)，小程序體系建設(shè)過(guò)程中形成的一系列標(biāo)準(zhǔn) API，也很大程度上實(shí)現(xiàn)了一個(gè)完整的小程序運(yùn)行環(huán)境的底層能力抽象，對(duì)于 Flutter 體系標(biāo)準(zhǔn)化的訪問系統(tǒng)能力，實(shí)現(xiàn)平臺(tái)無(wú)關(guān)的跨端能力是個(gè)非常好的補(bǔ)充。我們聯(lián)合淘寶中間件團(tuán)隊(duì)與小程序團(tuán)隊(duì)，對(duì)基礎(chǔ)中間件和小程序 API 實(shí)現(xiàn)做了 Flutter 側(cè)的封裝與標(biāo)準(zhǔn)化，未來(lái)也將對(duì) Flutter 中間件和 API 能力進(jìn)行系統(tǒng)支持。

標(biāo)準(zhǔn)化 Flutter 構(gòu)建

由于 Flutter 研發(fā)體系較新，且構(gòu)建 Pipeline 相較傳統(tǒng)的移動(dòng)構(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 腳本化的構(gòu)建流程，支持雙端自動(dòng)整包打包和 Flutter Module 打包。

目前 AliFlutter 的構(gòu)建流程默認(rèn)使用 AliFlutter 的 Flutter 倉(cāng)庫(kù)以及集團(tuán)內(nèi)部 pub 倉(cāng)庫(kù)，引擎產(chǎn)物也統(tǒng)一按配置從 artifacts 倉(cāng)庫(kù)獲取，較好的實(shí)現(xiàn)了支持 Flutter 業(yè)務(wù)的自動(dòng)化構(gòu)建需求。

業(yè)務(wù)應(yīng)用

在夯實(shí) Flutter 集團(tuán)共建基礎(chǔ)之后，第二步，我們 AliFlutter 在業(yè)務(wù)應(yīng)用方面也做了大量工作。一方面通過(guò)原生 Flutter 的工程化能力持續(xù)服務(wù)淘系與集團(tuán)業(yè)務(wù);另一方面通過(guò) Flutter Canvas 項(xiàng)目服務(wù)了小程序場(chǎng)景及游戲化場(chǎng)景下的互動(dòng)業(yè)務(wù)。

淘系與集團(tuán)業(yè)務(wù)支撐

目前淘寶特價(jià)版已完成詳情業(yè)務(wù)的 Flutter 改造并上線，采用 Flutter 使業(yè)務(wù)在需求節(jié)奏不變的情況下人力投入減少一半，對(duì)緩解業(yè)務(wù)研發(fā)壓力起到了明顯的作用;同時(shí)應(yīng)用的整體性能和穩(wěn)定性與 Native 基本持平。后續(xù)特價(jià)版將基于 Flutter 繼續(xù)拓展業(yè)務(wù)改造范圍，并沉淀基于 Flutter 的業(yè)務(wù)域解決方案。

目前盒馬、ICBU 、優(yōu)酷也基于 AliFlutter 進(jìn)行了容器接入升級(jí)與業(yè)務(wù)適配，盒馬依托閑魚的 Flutter 游戲引擎實(shí)現(xiàn)了盒馬小鎮(zhèn)業(yè)務(wù)，ICBU 在主鏈路相關(guān)頁(yè)面使用了 Flutter，優(yōu)酷則基于 Flutter 實(shí)現(xiàn)了會(huì)員訂單頁(yè)等場(chǎng)景。同時(shí)我們也在和釘釘及 Google 一起探索 Flutter 桌面端的解決方案。

Flutter Canvas

在電商活動(dòng)營(yíng)銷中互動(dòng)場(chǎng)景日益增多，對(duì)性能要求持續(xù)提升的前提下，如何提供一個(gè)高性能且穩(wěn)定的 Canvas 基礎(chǔ)能力服務(wù)好富交互的互動(dòng)場(chǎng)景就成為了一個(gè)重點(diǎn)的課題。

在小程序場(chǎng)景中 Canvas 作為承載互動(dòng)游戲的主要能力發(fā)揮了重要作用。然而受限于小程序架構(gòu)下 app context 和 page context 的隔離設(shè)計(jì)，存在從 app worker 到 page renderer 的通信瓶頸，無(wú)法充分發(fā)揮出 web canvas 的性能，如果有一個(gè) native 版的 canvas 實(shí)現(xiàn)將可直接在 native 層對(duì)接 app worker，降低通信成本，充分發(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 方式直接向小程序和小游戲容器提供與 Web Canvas 一致的標(biāo)準(zhǔn) API，一方面可以復(fù)用 Flutter 的底層能力，為非 Dart 環(huán)境提供渲染支持，另一方面可以借助 Flutter 簡(jiǎn)化高效的渲染管線實(shí)現(xiàn)提供更好的渲染性能。

目前 Flutter Canvas 已落地手機(jī)淘寶，并在小程序運(yùn)動(dòng)銀行業(yè)務(wù)進(jìn)行了灰度試點(diǎn)，初步具備了承載小程序 Canvas 業(yè)務(wù)的能力;其性能在 Android 低端機(jī)上的表現(xiàn)有優(yōu)勢(shì)，可以作為 Web Canvas 方案的有益補(bǔ)充。

未來(lái) Flutter Canvas 一方面將借助 Flutter 渲染管線的跨平臺(tái)與高性能特點(diǎn)，以及 Flutter 對(duì) Vulkan 和 Metal 的適配支持，在移動(dòng)端獲得更好的適配性以及性能;同時(shí)將繼續(xù)實(shí)現(xiàn) 3D API，支撐未來(lái)互動(dòng)類的業(yè)務(wù)應(yīng)用。

未來(lái)建設(shè)

扎根業(yè)務(wù)之后，接下來(lái)的第三步，我們要緊貼 Flutter 體系在阿里集團(tuán)未來(lái)的建設(shè)目標(biāo)，持續(xù)回答好 Flutter 面向未來(lái)建設(shè)路徑中的幾個(gè)關(guā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ā)模式，那么必須解決好跨端能力、交互能力、業(yè)務(wù)研發(fā)效率以及業(yè)務(wù)交付效率四個(gè)核心問題。

• 從跨端能力看，F(xiàn)lutter 雖然已具備了很好的跨多端能力與高還原度，但涉及到平臺(tái)能力時(shí)，仍然需要通過(guò)各端擴(kuò)展實(shí)現(xiàn)，還未形成小程序體系這樣的標(biāo)準(zhǔn)化的容器和 API 封裝能力。那么如何更好的解決 Flutter 的容器化問題，讓業(yè)務(wù)不感知平臺(tái)差異性?
• 從交互能力看，F(xiàn)lutter 如何利用好自身交互能力的優(yōu)勢(shì)，在提供媲美前端的富交互體驗(yàn)的同時(shí)，降低 Native 富交互特性開發(fā)的門檻，真正吸引 Native 開發(fā)者使用 Flutter 技術(shù)開發(fā)業(yè)務(wù)?
• 從業(yè)務(wù)研發(fā)效率看，雖然 Flutter 的 Hot Reload/Hot UI 機(jī)制已經(jīng)讓開發(fā) Native 頁(yè)面的效率追上了前端，但在工程解耦方面仍然有很大提升空間，目前還無(wú)法高效的支持多業(yè)務(wù)團(tuán)隊(duì)并行開發(fā);另一方面如何與現(xiàn)今流行的 Serverless 能力結(jié)合，實(shí)現(xiàn)端云一體研發(fā)模式，使業(yè)務(wù)實(shí)現(xiàn)研發(fā)閉環(huán)，也需要實(shí)踐的檢驗(yàn)。
• 從業(yè)務(wù)交付效率看，目前 Flutter 仍屬于 Native 方案，依賴端側(cè)發(fā)版，交付效率低，無(wú)法很好的承載電商系靈活性和實(shí)效性的需求;那么如何解決 Flutter 的動(dòng)態(tài)化，幫助業(yè)務(wù)實(shí)現(xiàn)快速迭代?

解決好這幾個(gè)問題，才能真正讓 Flutter 成為集團(tuán)移動(dòng)業(yè)務(wù)的核心研發(fā)模式，為集團(tuán)業(yè)務(wù)研發(fā)帶來(lái)一個(gè)飛躍性的提升。下面講講我們?cè)谶@幾個(gè)方向的思考和探索。

提升跨端能力：Flutter 容器化

從工程角度看，雖然 Flutter 通過(guò) Skia 跨平臺(tái)圖形渲染和自建事件體系基本實(shí)現(xiàn)了對(duì)宿主平臺(tái)的最小依賴，但對(duì)于平臺(tái)側(cè)能力，目前 Flutter 還未也沒有必要從應(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è)備能力、數(shù)據(jù)安全以及業(yè)務(wù)相關(guān)能力進(jìn)行了封裝，讓業(yè)務(wù)開發(fā)者在小程序側(cè)針對(duì) API 進(jìn)行系統(tǒng)能力調(diào)用，無(wú)需關(guān)心平臺(tái)實(shí)現(xiàn)。

因此 AliFlutter 容器接下來(lái)的規(guī)劃就是從工程體系的角度，提供一套標(biāo)準(zhǔn)化的 API 能力，以規(guī)范并抽象移動(dòng)端的端基礎(chǔ)能力，使業(yè)務(wù)盡量少甚至不關(guān)心平臺(tái)差異性，專注于業(yè)務(wù);同時(shí)借助標(biāo)準(zhǔn)化 API 的能力，實(shí)現(xiàn)跨多端多平臺(tái)部署。

從移動(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)度、管控和度量。

提升交互能力：UI + 游戲引擎

前文提到過(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ù)開發(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)用框架做 UI，通過(guò)建立在 canvas 上的 H5 游戲引擎實(shí)現(xiàn)游戲能力。如果在游戲應(yīng)用中有 UI 的需求，解決方案一般是自建一套簡(jiǎn)單的 UI 體系與事件體系，通過(guò)自繪的方式在游戲中疊加 UI，獨(dú)立游戲引擎亦是如此。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 objects，并與UI體系共用一套事件處理機(jī)制、分層與渲染合成機(jī)制。這樣做就相當(dāng)于打破了原來(lái) H5 中 DOM UI 和 Canvas 游戲的邊界，讓兩個(gè)體系在 widgets 概念下完美融合起來(lái)，通過(guò)游戲引擎的能力賦能 UI 實(shí)現(xiàn)更多以前 UI 體系難以低成本實(shí)現(xiàn)的動(dòng)效效果(比如一只小盒馬一口吃掉了一個(gè)訂單組件等等)。我們相信，這個(gè)方向的探索將會(huì)進(jìn)一步釋放 Flutter 的技術(shù)潛力，帶來(lái)更多的業(yè)務(wù)可玩性與創(chuàng)造性，解放產(chǎn)品和設(shè)計(jì)的想象力，為業(yè)務(wù)創(chuàng)造更多價(jià)值。

提升研發(fā)效率：工程解耦與端云一體化

• Flutter 工程解耦

前端體系的研發(fā)效率很大程度上來(lái)自于基于URI的統(tǒng)一路由體系帶來(lái)的頁(yè)面間解耦性，與頁(yè)面內(nèi)基于 Web API 的標(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ū)Φ鹊?API 能力封裝，業(yè)務(wù)對(duì)平臺(tái)無(wú)感知，能夠讓我們有機(jī)會(huì)解耦業(yè)務(wù)研發(fā)，實(shí)現(xiàn)與小程序開發(fā)接近的研發(fā)體驗(yàn)和效率。

理想的方案是，業(yè)務(wù)可以從業(yè)務(wù)維度創(chuàng)建一個(gè)獨(dú)立的 Dart 工程，只包含業(yè)務(wù)相關(guān)的頁(yè)面和邏輯代碼，通過(guò) Flutter 的 Hot UI 開發(fā)頁(yè)面，通過(guò) IDE 提供的基于 Flutter Web 的能力本地預(yù)覽工程并調(diào)試 API 與系統(tǒng)調(diào)用，完成研發(fā)期工作;也可生成預(yù)覽二維碼，使用預(yù)裝有 AliFlutter SDK 環(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è)務(wù)間的研發(fā)解耦和并行發(fā)布，提高業(yè)務(wù)的交付效率。

• 端云一體化

如今 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)開發(fā)服務(wù)端業(yè)務(wù)能力，實(shí)現(xiàn)服務(wù)編排、服務(wù)端 FaaS 業(yè)務(wù)邏輯與 API 自動(dòng)生成，達(dá)到前后端工程體系歸一，業(yè)務(wù)研發(fā)閉環(huán)的效果。

目前閑魚在 Dart FaaS 云端一體化的探索走在了前面，通過(guò)集團(tuán)的容器規(guī)范實(shí)現(xiàn)了 Dart function 容器，并聯(lián)合服務(wù)端為部分業(yè)務(wù)需要的領(lǐng)域服務(wù)抽象出來(lái) BaaS 層(存儲(chǔ)、消息隊(duì)列等)，并封裝了面向前端的 BFF(Backend for Frontend)能力層，使移動(dòng)端開發(fā)者可以很容易的使用 Dart 封裝 FaaS 業(yè)務(wù)邏輯，同時(shí)進(jìn)行移動(dòng)端和服務(wù)端 FaaS 開發(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é)，提高了開發(fā)效率。

云端一體化除了帶來(lái)了研發(fā)與協(xié)同效率的提升，同時(shí)也重塑了生產(chǎn)關(guān)系，使端側(cè)業(yè)務(wù)從只關(guān)注端側(cè)體驗(yàn)和邏輯的開發(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 開發(fā)者和業(yè)務(wù)都能共享到 Serverless 技術(shù)和云端一體化提效的紅利，是需要我們共同去探索和定義的新問題。

提升交付效率：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ù)需要解決的核心問題，是在保證業(yè)務(wù)發(fā)布確定性的前提下，尋求技術(shù)性能、業(yè)務(wù)迭代效率與靈活性三者之間合理的平衡點(diǎn)。下面講講我們?cè)? Flutter 動(dòng)態(tài)化上的兩個(gè)思路與嘗試：Flutter 模板化方案與 Web on Flutter。

• Flutter 模板化方案

動(dòng)態(tài)模板化方案是集團(tuán)內(nèi)較為成熟的一套基于 Native 技術(shù)的模板化方案，專注于UI模板渲染，沒有執(zhí)行邏輯和運(yùn)行時(shí)環(huán)境，目前被廣泛應(yīng)用于電商系的一些核心業(yè)務(wù)場(chǎng)景。同時(shí)該方案提供了配套的組件平臺(tái)，支持在線模板編輯、預(yù)覽、測(cè)試及發(fā)布整套流程，結(jié)合發(fā)布平臺(tái)形成了一整套完善的業(yè)務(wù)開發(fā)生態(tài)閉環(huán)。

在 Flutter 體系下，目前閑魚團(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ò)一年多的迭代逐步解決了渲染性能與渲染一致性問題，較好的賦能了 Flutter 業(yè)務(wù)的組件動(dòng)態(tài)化能力。

那么，未來(lái) Flutter 與動(dòng)態(tài)模板化方案有沒有更好的結(jié)合點(diǎn)?答案是肯定的。從 DSL 角度看，目前模板的寫法基本上來(lái)自 Android XML，對(duì)組件開發(fā)者尤其是非 Android 開發(fā)者不夠友好，具備一定的學(xué)習(xí)成本;而 Flutter 的結(jié)構(gòu)與屬性均可通過(guò) widgets 表達(dá)，可以極為靈活且平臺(tái)中立的用聲明式代碼構(gòu)建 UI 并綁定數(shù)據(jù)，易于開發(fā)者編寫組件并通過(guò) Flutter 框架獨(dú)立調(diào)試與測(cè)試;在移動(dòng)端運(yùn)行時(shí)，可以按需按場(chǎng)景翻譯成 native 組件或 Flutter 組件。未來(lái)我們也將持續(xù)在這個(gè)方向上做探索。

• Web on Flutter

相比貼近 Native 研發(fā)模式的模板組件化渲染方案，Web on Flutter 希望通過(guò)類 H5 的 DSL + JS，借助 Flutter 的渲染能力，實(shí)現(xiàn)貼前端技術(shù)棧的動(dòng)態(tài)化能力。

目前基于 Web 渲染的小程序方案存在啟動(dòng)耗時(shí)高，渲染性能距原生UI有較大差距等性能問題，這些問題很大程度上都源自于瀏覽器引擎的設(shè)計(jì)歷史包袱(渲染管線復(fù)雜、 CSS multi-pass layout 及 legacy 實(shí)現(xiàn)等)，以及 JS 到 Native 通信效率低(bridge)。Flutter 的設(shè)計(jì)思路源自瀏覽器，一方面直接吸收了前端框架近年來(lái)的演進(jìn)成就，原生支持了聲明式-響應(yīng)式編程范式，提高了移動(dòng)端的研發(fā)效率;另一方面， Flutter 緊貼 native 開發(fā)模式有限定義了 UI 結(jié)構(gòu)、布局與渲染的必要元素，在滿足 native UI 開發(fā)模式的前提下簡(jiǎn)化了能力定義與布局算法(single-pass layout 與 repaint boundary 等概念)，很大程度上簡(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)力，并具備向上對(duì)接各種研發(fā)模式的可能性。

因此，通過(guò) widgets 組合小程序 DSL，支持小程序 CSS 有限集，實(shí)現(xiàn)渲染層替換瀏覽器引擎，并對(duì)接 JS 引擎支持 JS 執(zhí)行能力，是一個(gè)將 Flutter 應(yīng)用于小程序生態(tài)的合理探索方向。相比把開發(fā)者慣壞了的瀏覽器，這種方案在 CSS 的能力支持上必然是受限的，無(wú)法滿足所有 CSS3 標(biāo)準(zhǔn)的實(shí)現(xiàn)，更多通過(guò)緊貼 Flutter widgets 的現(xiàn)有能力以及必要的 widgets 擴(kuò)展，在不破壞 single-pass layout 的前提下組合出 CSS 能力;但從 Flutter 原生開發(fā)的角度看，只要 Flutter 現(xiàn)有的原生能力能夠滿足業(yè)務(wù)需求，那么受限的 CSS 實(shí)現(xiàn)也一樣可以提供和 Flutter 對(duì)等的能力解決業(yè)務(wù)問題。同時(shí)，通過(guò)受限的 CSS 可以換來(lái)與 Flutter 相當(dāng)?shù)母咝阅?，與基于 Web 的實(shí)現(xiàn)相比，在性能上帶來(lái)了質(zhì)變。

我們?cè)?18 年底通過(guò)一個(gè)內(nèi)部項(xiàng)目實(shí)現(xiàn)了這個(gè)思路的原型，通過(guò)使用 C++ 重寫 Flutter 的 widgets、rendering、painting 及事件管理等 Dart framework 中的中低層能力，并在 widget 上用 C++ 實(shí)現(xiàn)了 CSSOM + DSL -> Widgets 的響應(yīng)式框架，直接從 C++ 層提供 render 實(shí)現(xiàn)，將傳統(tǒng)由 JS 承擔(dān)的模板展開、tree-diff 計(jì)算與渲染工作交給 C++ 層，通過(guò) Flutter 提供的 Widgets tree 到 RenderObjects tree 的 diff 能力實(shí)現(xiàn)，顯著提高了性能。從實(shí)現(xiàn)的簡(jiǎn)單的 demo 看，相對(duì)小程序的 web 渲染性能有了大幅的提升。

這種方案的問題在于和 Google 代碼庫(kù)分裂后的長(zhǎng)期維護(hù)性。打破重重阻礙，F(xiàn)lutter 和 Web 生態(tài)如何對(duì)接?這篇文章對(duì)集團(tuán)內(nèi)在這個(gè)方向上嘗試的幾種思路做了較為全面的對(duì)比，未來(lái)我們也將繼續(xù)在這個(gè)方向上做深入和持續(xù)的探索。

總結(jié)與展望

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ù)小組啟動(dòng) AliFlutter 項(xiàng)目之前，閑魚技術(shù)部已經(jīng)在 Flutter 技術(shù)建設(shè)上做了大量探索和投入，一方面通過(guò) Flutter 技術(shù)賦能業(yè)務(wù)提效升級(jí)，拿到了很好的業(yè)務(wù)成績(jī);另一方面沉淀 Flutter 的技術(shù)與業(yè)務(wù)解決方案，并通過(guò)開源反哺社區(qū)，在海內(nèi)外 Flutter 技術(shù)社區(qū)中建立了顯著的技術(shù)影響力與領(lǐng)導(dǎo)力，也涌現(xiàn)出一眾 Flutter 技術(shù)專家。

接下來(lái) AliFlutter 的重點(diǎn)任務(wù)，就是要和閑魚、財(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ù)和經(jīng)驗(yàn)?zāi)軌蚬餐恋砗头窒?，一起?lái)把 Flutter 技術(shù)體系在阿里的應(yīng)用生態(tài)內(nèi)做大做強(qiáng)，真正成為集團(tuán)業(yè)務(wù)的核心研發(fā)模式，并讓每個(gè)參與者都能從中受益。

我們一直堅(jiān)信 Flutter 技術(shù)的先進(jìn)性和應(yīng)用前景，未來(lái)我們將繼續(xù)立足淘系服務(wù)集團(tuán)業(yè)務(wù)，和集團(tuán)開發(fā)者攜手前行，在 Flutter 這個(gè)技術(shù)方向上堅(jiān)定的走下去。