[[321430]]

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

為什么是 Flutter

集團內(nèi)已有越來越多的業(yè)務(wù)和團隊開始嘗試 Flutter 技術(shù)棧，從閑魚的一支獨秀引領(lǐng)潮流，到如今淘寶特價版、盒馬、優(yōu)酷、飛豬等 BU 業(yè)務(wù)相繼入局，F(xiàn)lutter 的業(yè)務(wù)應(yīng)用在集團內(nèi)也已經(jīng)逐漸形成趨勢。那么，是什么原因讓集團內(nèi)越來越多的開發(fā)者選擇擁抱 Flutter 技術(shù)棧?Flutter 的哪些優(yōu)勢吸引了集團 Native 開發(fā)者們通過 Flutter 開發(fā)并交付業(yè)務(wù)?

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

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

開發(fā)效率

從集團電商業(yè)務(wù)屬性出發(fā)，業(yè)務(wù)響應(yīng)效率及其背后的研發(fā)效率從來都是最為重要的指標(biāo)。在保證體驗的前提下，盡可能的提高研發(fā)效率，就意味著更高的生產(chǎn)力。傳統(tǒng)的 Native 業(yè)務(wù)研發(fā) iOS/Android 雙端需要分別投入，研發(fā)成本高，端差異性大且依賴端側(cè)發(fā)版，這也是為什么集團電商業(yè)務(wù)的活動類技術(shù)棧一直較為依賴前端體系，從 H5 到 Weex 到小程序，很大程度上就是在追求研發(fā)和交付效率以及靈活性。

如今Flutter很好的解決了跨端一致性問題，一套代碼無差異的同時跑在 iOS 與 Android 兩端;開發(fā)體驗基本接近前端，支持on device的Hot Reload，去年年底Flutter又推出了在 Android Studio 中通過插件實現(xiàn)實時預(yù)覽并支持交互的 Hot UI 能力，以及 Layout Explorer 可視化布局，讓 Flutter 的開發(fā)效率和前端效率基本持平。

跨多端多平臺

電商業(yè)務(wù)發(fā)展到當(dāng)前階段，已經(jīng)不再僅僅局限于移動端場景，越來越多的業(yè)務(wù)需求對跨端跨平臺性提出了更高的要求。釘釘/千牛桌面端應(yīng)用場景，甚至天貓精靈、線下門店等業(yè)務(wù)場景，從長遠看都需要一個比 Web 性能一致性更好適配成本更低的多端方案。目前跨多端技術(shù)方案主要依賴于瀏覽器和前端體系，但瀏覽器本身的沙盒屬性、與系統(tǒng)較低的結(jié)合度、以及在低端設(shè)備上較差的性能都降低了研發(fā)效率和用戶體驗，提高了業(yè)務(wù)的交付門檻。可以說目前集團內(nèi)的跨多端多平臺方案是實質(zhì)缺失的。

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

UI 表現(xiàn)力

電商業(yè)務(wù)重體驗，重交互，尤其對于流量精細化運營場景，富交互的游戲化表現(xiàn)方式已經(jīng)成為流量促活的重要手段。在 UI 表現(xiàn)力方面，前端體系一直具備著優(yōu)勢，通過 CSS3 強大的動畫能力，開發(fā)者可以非常容易的實現(xiàn)復(fù)雜的動畫效果和交互體驗，而基于 Native UI，需要借助各種動畫特效三方庫，雙端開發(fā)體驗不一致，實現(xiàn)復(fù)雜且交付效率低。Flutter 很好的解決了這個問題，從補間(Tween)動畫、基于物理屬性的動畫，到相對復(fù)雜的頁面間 Hero 動畫、parallax 交錯動畫等特效，F(xiàn)lutter 都可以跨平臺低成本的高效實現(xiàn)。這里貼一個去年年底 Flutter Interact 大會上 GSkinner 公布的基于 Flutter 實現(xiàn)的交互 Demo 讓大家直觀感受一下：

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

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

目前集團內(nèi)有多個業(yè)務(wù) BU 均已開始嘗試應(yīng)用 Flutter 技術(shù)棧，涵蓋了從電商詳情業(yè)務(wù)、導(dǎo)購頻道，到 Feeds 流、游戲化交互以及國際化等多個業(yè)務(wù)場景。目前 Flutter 技術(shù)在集團應(yīng)用的痛點在于，研發(fā)基礎(chǔ)設(shè)施的中臺基建不夠完善，研發(fā)支撐能力與數(shù)據(jù)運維能力未實現(xiàn)標(biāo)準化，集團 Flutter 開發(fā)者生態(tài)還未完全拉通，暫時未能形成合力。這些問題將是我們后面在集團層面建設(shè) Flutter 技術(shù)體系的重點。

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

手淘的嘗試和思考

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

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

從業(yè)務(wù)應(yīng)用上看，F(xiàn)lutter 目前帶來的最大價值是研發(fā)效率的提升。在基建和 native 擴展能力完備的前提下，開發(fā)基于 Flutter 的純 Dart 業(yè)務(wù)的人效比之前各端分別開發(fā)的效率提高了接近 2 倍，單位時間內(nèi)的需求響應(yīng)能力也相應(yīng)提高了接近 2 倍，目前已在閑魚和特價版業(yè)務(wù)開發(fā)中得到了很好的工程化驗證。從適應(yīng)場景看，F(xiàn)lutter 目前比較適合承載富圖文內(nèi)容，如詳情、Feeds 流、用戶主頁等常規(guī)業(yè)務(wù)開發(fā)，以及 2D/2.5D 游戲場景以及富動效業(yè)務(wù)。Flutter 通過單端技術(shù)棧可以同時滿足以前需要 iOS、Android 以及前端技術(shù)棧分別負責(zé)的業(yè)務(wù)場景，甚至可以通過端云一體化的開發(fā)模式使用 Dart 負責(zé)一部分服務(wù)端業(yè)務(wù)邏輯開發(fā)，可以幫助業(yè)務(wù)團隊拓展業(yè)務(wù)邊界的同時，實現(xiàn)前后端研發(fā)能力閉環(huán)。

Flutter 目前的限制在于，動態(tài)性能力及前期的投入成本。前期投入成本主要指技術(shù)學(xué)習(xí)與團隊研發(fā)模式升級的成本，涉及到技術(shù)路線選擇，是我們和每個業(yè)務(wù)團隊需要一起思考和判斷的，這里不展開談;動態(tài)性能力是 Flutter 的相對短板，目前能夠通過 Flutter 模板化技術(shù)實現(xiàn)基于模板的組件級動態(tài)化能力，但基于性能、審核及對原生 Flutter 體系的侵入性等多種因素，目前還不能去直接實現(xiàn) UI + 邏輯動態(tài)化能力。Flutter Web 方案雖然不存在審核限制，但受限于瀏覽器 DOM API 與 widgets 體系的差異性，目前仍舊存在較嚴重的性能瓶頸和渲染差異性，僅可作為降級的備用方案，暫時無法作為動態(tài)化的主要實現(xiàn)方案。未來在動態(tài)化方向的探索也將是個長期的博弈過程。如果后面我們可以解決好 Flutter 動態(tài)化的問題，那么 Flutter 完全有機會成為集團業(yè)務(wù)的核心研發(fā)模式之一。

綜上我們認為，入局 Flutter 的時機已成熟，合力共建 Flutter 集團移動生態(tài)，這件事情大有可為。

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

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

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

為經(jīng)濟體的 Flutter 技術(shù)體系“建基礎(chǔ)、育社區(qū)、扛大旗”，我們責(zé)無旁貸。

未來 AliFlutter 的整體架構(gòu)如下所示：

AliFlutter 建設(shè)的第一步，就是要構(gòu)建集團的 Flutter 基礎(chǔ)設(shè)施、提供公共容器與組件、研發(fā)支撐服務(wù)與標(biāo)準化研發(fā)流程，為集團的 Flutter 業(yè)務(wù)提供一個基礎(chǔ)的 Flutter 公共研發(fā)服務(wù)能力，搭建好技術(shù)共建共享的基礎(chǔ)和平臺。

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

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

接下來，就詳細講一講每個階段 AliFlutter 所做的工作和面向未來的思考。

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

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

Artifacts 倉庫

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

pub 倉庫

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

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

容器、中間件與 API

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

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

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

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

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

由于 Flutter 研發(fā)體系較新，且構(gòu)建 Pipeline 相較傳統(tǒng)的移動構(gòu)建流程又存在一定特殊性，產(chǎn)物構(gòu)建配置復(fù)雜耗時長易出錯，給 Flutter 業(yè)務(wù)的構(gòu)建和發(fā)版帶來了很大阻礙。因此我們也聯(lián)合研發(fā)支撐部的同學(xué)，以插件的形式實現(xiàn)了 Flutter 腳本化的構(gòu)建流程，支持雙端自動整包打包和 Flutter Module 打包。

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

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

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

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

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

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

Flutter Canvas

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

在小程序場景中 Canvas 作為承載互動游戲的主要能力發(fā)揮了重要作用。然而受限于小程序架構(gòu)下 app context 和 page context 的隔離設(shè)計，存在從 app worker 到 page renderer 的通信瓶頸，無法充分發(fā)揮出 web canvas 的性能，如果有一個 native 版的 canvas 實現(xiàn)將可直接在 native 層對接 app worker，降低通信成本，充分發(fā)揮 Canvas 的性能。

Flutter 底層基于 Skia，其性能和移動端復(fù)雜異構(gòu)機型的適配性均得到過長期的檢驗，且 Flutter 基于瀏覽器的設(shè)計實現(xiàn)了一條平臺無關(guān)的渲染管線，并對瀏覽器實現(xiàn)做了極大的簡化，提供了很好的可靠性和性能。那么如果能夠?qū)⑦@條渲染管線直接用于向業(yè)務(wù)容器提供 Canvas 能力，通過 binding 方式直接向小程序和小游戲容器提供與 Web Canvas 一致的標(biāo)準 API，一方面可以復(fù)用 Flutter 的底層能力，為非 Dart 環(huán)境提供渲染支持，另一方面可以借助 Flutter 簡化高效的渲染管線實現(xiàn)提供更好的渲染性能。

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

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

未來建設(shè)

扎根業(yè)務(wù)之后，接下來的第三步，我們要緊貼 Flutter 體系在阿里集團未來的建設(shè)目標(biāo)，持續(xù)回答好 Flutter 面向未來建設(shè)路徑中的幾個關(guān)鍵問題。那么首先，F(xiàn)lutter 體系在阿里集團的建設(shè)目標(biāo)應(yīng)該是什么?個人以為：Flutter 應(yīng)成為阿里集團未來跨多端多平臺的核心業(yè)務(wù)研發(fā)模式之一。

那么，我們目前離這個目標(biāo)還有多大差距?在我看來，如果要想讓 Flutter 成為業(yè)務(wù)的核心研發(fā)模式，那么必須解決好跨端能力、交互能力、業(yè)務(wù)研發(fā)效率以及業(yè)務(wù)交付效率四個核心問題。

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

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

提升跨端能力：Flutter 容器化

從工程角度看，雖然 Flutter 通過 Skia 跨平臺圖形渲染和自建事件體系基本實現(xiàn)了對宿主平臺的最小依賴，但對于平臺側(cè)能力，目前 Flutter 還未也沒有必要從應(yīng)用框架角度做到一個統(tǒng)一的抽象，這就需要我們根據(jù)業(yè)務(wù)的訴求和特點進行有選擇的封裝。小程序 API 就做了一個非常好的示范，目前阿里小程序體系提供的 API 達到了 200+，很好的對移動端的 UI、多媒體、文件緩存、網(wǎng)絡(luò)、設(shè)備能力、數(shù)據(jù)安全以及業(yè)務(wù)相關(guān)能力進行了封裝，讓業(yè)務(wù)開發(fā)者在小程序側(cè)針對 API 進行系統(tǒng)能力調(diào)用，無需關(guān)心平臺實現(xiàn)。

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

從移動端架構(gòu)角度看，各個時期的跨平臺方案都對 API 能力有著共同的訴求，從 H5 到 Weex，再到后面的小程序，以及 Flutter 等容器環(huán)境，進行了多輪的 API 重復(fù)建設(shè)，造成了缺少 API 接口的標(biāo)準化定義，以及缺少實現(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)度、管控和度量。

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

前文提到過，F(xiàn)lutter 目前最大的價值在于研發(fā)效率的提升，這是吸引業(yè)務(wù)團隊?wèi)?yīng)用 Flutter 技術(shù)的起點;但僅僅依靠研發(fā)提效還遠遠不夠，當(dāng)通過各種工程化手段解決好當(dāng)前研發(fā)痛點，提升研發(fā)效率之后，如何說服業(yè)務(wù)繼續(xù)使用 Flutter 體系進行業(yè)務(wù)開發(fā)?Flutter 帶來的長遠價值在哪里?個人認為，這個落腳點應(yīng)該在通過游戲交互能力的泛化，打破 UI 與游戲引擎的邊界，用游戲化的方式創(chuàng)造更有表現(xiàn)力的交互體驗，創(chuàng)造新的業(yè)務(wù)玩法和價值。

大家知道傳統(tǒng)的 UI 和游戲引擎是相互獨立的兩個體系，在 H5 應(yīng)用中，往往是通過 DOM 或者上層應(yīng)用框架做 UI，通過建立在 canvas 上的 H5 游戲引擎實現(xiàn)游戲能力。如果在游戲應(yīng)用中有 UI 的需求，解決方案一般是自建一套簡單的 UI 體系與事件體系，通過自繪的方式在游戲中疊加 UI，獨立游戲引擎亦是如此。Flutter 從技術(shù)原理上看更像是一個建立在 Skia 圖形庫上的游戲引擎，它通過細粒度的 widgets 設(shè)計向上構(gòu)建 UI 系統(tǒng);同樣得益于這樣的細粒度設(shè)計，我們也完全可以直接通過 widgets 能力組合出一個完整的游戲引擎，提供 Game，Scene 及 Sprite 動效等 widgets 并擴展對應(yīng)的 elements 和 render objects，并與UI體系共用一套事件處理機制、分層與渲染合成機制。這樣做就相當(dāng)于打破了原來 H5 中 DOM UI 和 Canvas 游戲的邊界，讓兩個體系在 widgets 概念下完美融合起來，通過游戲引擎的能力賦能 UI 實現(xiàn)更多以前 UI 體系難以低成本實現(xiàn)的動效效果(比如一只小盒馬一口吃掉了一個訂單組件等等)。我們相信，這個方向的探索將會進一步釋放 Flutter 的技術(shù)潛力，帶來更多的業(yè)務(wù)可玩性與創(chuàng)造性，解放產(chǎn)品和設(shè)計的想象力，為業(yè)務(wù)創(chuàng)造更多價值。

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

• Flutter 工程解耦

前端體系的研發(fā)效率很大程度上來自于基于URI的統(tǒng)一路由體系帶來的頁面間解耦性，與頁面內(nèi)基于 Web API 的標(biāo)準化帶來的內(nèi)聚性。然而目前的 Flutter 研發(fā)模式，仍需要多個業(yè)務(wù)團隊工作在同一個工程下，互相之間存在源碼依賴，未來如果跨業(yè)務(wù)團隊大規(guī)模應(yīng)用 Flutter 技術(shù)，必將拖慢業(yè)務(wù)的研發(fā)效率。

從工程解耦角度看，目前 AliFlutter 容器通過混合棧與標(biāo)準路由能力基本實現(xiàn)了頁面研發(fā)的解耦，未來的容器化建設(shè)通過提供小程序?qū)Φ鹊?API 能力封裝，業(yè)務(wù)對平臺無感知，能夠讓我們有機會解耦業(yè)務(wù)研發(fā)，實現(xiàn)與小程序開發(fā)接近的研發(fā)體驗和效率。

理想的方案是，業(yè)務(wù)可以從業(yè)務(wù)維度創(chuàng)建一個獨立的 Dart 工程，只包含業(yè)務(wù)相關(guān)的頁面和邏輯代碼，通過 Flutter 的 Hot UI 開發(fā)頁面，通過 IDE 提供的基于 Flutter Web 的能力本地預(yù)覽工程并調(diào)試 API 與系統(tǒng)調(diào)用，完成研發(fā)期工作;也可生成預(yù)覽二維碼，使用預(yù)裝有 AliFlutter SDK 環(huán)境的宿主應(yīng)用掃碼預(yù)覽;研發(fā)與構(gòu)建鏈路分離，云端主動拉取業(yè)務(wù)倉庫代碼參與整包構(gòu)建。以此達到類似小程序研發(fā)方式的前端研發(fā)體驗，同時實現(xiàn)業(yè)務(wù)間的研發(fā)解耦和并行發(fā)布，提高業(yè)務(wù)的交付效率。

• 端云一體化

如今 Serverless 概念越來越多的受到業(yè)務(wù)研發(fā)的重視和應(yīng)用，集團在新一代的端云一體化研發(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 自動生成，達到前后端工程體系歸一，業(yè)務(wù)研發(fā)閉環(huán)的效果。

目前閑魚在 Dart FaaS 云端一體化的探索走在了前面，通過集團的容器規(guī)范實現(xiàn)了 Dart function 容器，并聯(lián)合服務(wù)端為部分業(yè)務(wù)需要的領(lǐng)域服務(wù)抽象出來 BaaS 層(存儲、消息隊列等)，并封裝了面向前端的 BFF(Backend for Frontend)能力層，使移動端開發(fā)者可以很容易的使用 Dart 封裝 FaaS 業(yè)務(wù)邏輯，同時進行移動端和服務(wù)端 FaaS 開發(fā)，大大提高了業(yè)務(wù)研發(fā)效率。通過將原有的端側(cè)請求接口、組裝數(shù)據(jù)并轉(zhuǎn)換為 ViewModel 的邏輯都后移到了服務(wù)端，經(jīng)過字段映射與頁面編排，移動端可直接獲取 ViewModel 并刷新頁面，通過 BinderAction 雙向交互狀態(tài)數(shù)據(jù)，有效屏蔽了通信細節(jié)，提高了開發(fā)效率。

云端一體化除了帶來了研發(fā)與協(xié)同效率的提升，同時也重塑了生產(chǎn)關(guān)系，使端側(cè)業(yè)務(wù)從只關(guān)注端側(cè)體驗和邏輯的開發(fā)角色，變成能夠向業(yè)務(wù)整體結(jié)果負責(zé);同時也讓服務(wù)端更專注于領(lǐng)域服務(wù)的沉淀。Flutter 良好的跨端特性，能夠屏蔽掉端差異化，配合 Flutter 容器化改造，更近一步的簡化了業(yè)務(wù)的全鏈路研發(fā)模式。未來如何在 FaaS 模式下，沉淀出一套可以服務(wù)集團業(yè)務(wù)研發(fā)的通用端側(cè)和服務(wù)端通信調(diào)度框架，讓集團 Flutter 開發(fā)者和業(yè)務(wù)都能共享到 Serverless 技術(shù)和云端一體化提效的紅利，是需要我們共同去探索和定義的新問題。

提升交付效率：Flutter 動態(tài)化

實現(xiàn)動態(tài)化是交付效率提升的重要方式。對于電商強運營強時效性特性來說，動態(tài)化幾乎是一個必備的訴求，但從技術(shù)上看也是一個非常敏感的需求，是一個在系統(tǒng)廠商平臺管控下長期博弈的過程。在我看來，動態(tài)化技術(shù)需要解決的核心問題，是在保證業(yè)務(wù)發(fā)布確定性的前提下，尋求技術(shù)性能、業(yè)務(wù)迭代效率與靈活性三者之間合理的平衡點。下面講講我們在 Flutter 動態(tài)化上的兩個思路與嘗試：Flutter 模板化方案與 Web on Flutter。

• Flutter 模板化方案

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

在 Flutter 體系下，目前閑魚團隊依據(jù)標(biāo)準模板協(xié)議在 Flutter 側(cè)實現(xiàn)了一套 Dart 版 SDK，通過模板下發(fā)實現(xiàn)了 Flutter 端的輕量級動態(tài)化組件編排能力;并通過一年多的迭代逐步解決了渲染性能與渲染一致性問題，較好的賦能了 Flutter 業(yè)務(wù)的組件動態(tài)化能力。

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

• Web on Flutter

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

目前基于 Web 渲染的小程序方案存在啟動耗時高，渲染性能距原生UI有較大差距等性能問題，這些問題很大程度上都源自于瀏覽器引擎的設(shè)計歷史包袱(渲染管線復(fù)雜、 CSS multi-pass layout 及 legacy 實現(xiàn)等)，以及 JS 到 Native 通信效率低(bridge)。Flutter 的設(shè)計思路源自瀏覽器，一方面直接吸收了前端框架近年來的演進成就，原生支持了聲明式-響應(yīng)式編程范式，提高了移動端的研發(fā)效率;另一方面， Flutter 緊貼 native 開發(fā)模式有限定義了 UI 結(jié)構(gòu)、布局與渲染的必要元素，在滿足 native UI 開發(fā)模式的前提下簡化了能力定義與布局算法(single-pass layout 與 repaint boundary 等概念)，很大程度上簡化了渲染管線的復(fù)雜度，直接為 Flutter 帶來了接近原生的性能體驗。同時，F(xiàn)lutter 的 widgets 設(shè)計巧妙，結(jié)構(gòu)_布局_屬性等基礎(chǔ)元素均使用 widgets 表達，且可通過基礎(chǔ) widgets 的組合來構(gòu)成復(fù)雜組件，這種細粒度 + 組合能力設(shè)計讓 Flutter 有極強的表現(xiàn)力，并具備向上對接各種研發(fā)模式的可能性。

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

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

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

總結(jié)與展望

Flutter 體系化建設(shè)目前在淘系剛剛起步，仍然有大量工作需要去做，我們在基礎(chǔ)設(shè)施、工程化以及通過 Flutter 定義和收斂業(yè)務(wù)域研發(fā)模式上做的許多建設(shè)性的事情，正朝著把 Flutter 打造為統(tǒng)一移動應(yīng)用基礎(chǔ)研發(fā)框架，助力業(yè)務(wù)回歸移動端研發(fā)模式這個大目標(biāo)一點點邁進。

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

接下來 AliFlutter 的重點任務(wù)，就是要和閑魚、財富等先驅(qū)應(yīng)用者以及盒馬、釘釘、飛豬、優(yōu)酷、餓了么、CBU 等 Flutter 的實踐者一起，在集團層面把 Flutter 的場子建起來，把集團 Flutter 生態(tài)拉起來，讓技術(shù)和經(jīng)驗?zāi)軌蚬餐恋砗头窒恚黄饋戆?Flutter 技術(shù)體系在阿里的應(yīng)用生態(tài)內(nèi)做大做強，真正成為集團業(yè)務(wù)的核心研發(fā)模式，并讓每個參與者都能從中受益。

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