阿里集團內如何進行Flutter體系化建設？

做者|董巖(思牧)

出品|阿里巴巴新零售淘系技術部

2019 年無疑是 Flutter 技術如火如荼發展的一年。每個移動開發者都在爲 Flutter 帶來的「快速開發、富有表現力和靈活的 UI、原生性能」的特點和理念而癡狂，從超級 App 到獨立應用，從純 Flutter 到混合棧，開發者們在不一樣的場景下樂此不疲的探索和應用着 Flutter 技術，也在面臨着各類各樣不一樣的挑戰。

爲何是 Flutter？

阿里巴巴集團內也有愈來愈多的業務和團隊開始嘗試 Flutter 技術棧，從閒魚的一支獨秀引領潮流，到現在淘寶特價版、盒馬、優酷、飛豬等BU業務相繼入局，Flutter的業務應用在集團內也已經逐漸造成趨勢。

那麼，是什麼緣由讓集團內愈來愈多的開發者選擇擁抱Flutter技術棧？Flutter的哪些優點吸引了集團Native開發者們經過Flutter開發並交付業務？

從技術上看，我的認爲Flutter最核心的3個特色最爲吸引開發者：

• 極高的開發與交付效率，良好的開發體驗
• 優秀的跨多端多平臺能力
• 極強的 UI 表現力

先說一下 開發效率。從集團電商業務屬性出發，業務響應效率及其背後的研發效率歷來都是最爲重要的指標。在保證體驗的前提下，儘量的提升研發效率，就意味着更高的生產力。 傳統的 Native 業務研發 iOS/Android 雙端須要分別投入，研發成本高，端差別性大且依賴端側發版，這也是爲何集團電商業務的活動類技術棧一直較爲依賴前端體系，從H5到Weex到小程序，很大程度上就是在追求研發和交付效率以及靈活性。

現在 Flutter 很好的解決了跨端一致性問題，一套代碼無差別的同時跑在 iOS 與 Android 兩端；開發體驗基本接近前端，支持 on device 的 Hot Reload ，去年年末 Flutter 又推出了在 Android Studio 中經過插件實現實時預覽並支持交互的 Hot UI 能力，以及 Layout Explorer 可視化佈局，讓Flutter的開發效率和前端效率基本持平。

電商業務發展到當前階段，已經再也不僅僅侷限於移動端場景，愈來愈多的業務需求對跨端跨平臺性提出了更高的要求。釘釘/千牛桌面端應用場景，甚至天貓精靈、線下門店等業務場景，從長遠看都須要一個比 Web 性能一致性更好適配成本更低的多端方案。

目前跨多端技術方案主要依賴於瀏覽器和前端體系，但瀏覽器自己的沙盒屬性、與系統較低的結合度、以及在低端設備上較差的性能都下降了研發效率和用戶體驗，提升了業務的交付門檻。

能夠說目前集團內的跨多端多平臺方案是實質缺失的。Flutter 從設計上就自然支持多平臺開發，它的底層基於 Skia 跨平臺圖形引擎，向上構建出了一整套平臺無關的渲染體系和事件處理體系，並緊貼 Native 研發模式自定義了基於 widgets 的聲明+響應式編程範式，對系統能力依賴度低，並具有出色的跨平臺還原度；支持多平臺也是 Flutter 的戰略目標之一。

目前除了 iOS 和 Android ，官方宣佈支持的平臺有 Mac、Windows 和 Web，Linux 也在開發中，它的技術特性也讓將 Flutter移植到 Linux based IoT 平臺上成本很低，同時 Flutter 仍是將來 Google 的下一代操做系統 Fuschia 的官方應用研發框架。 能夠說Flutter已經具有了成爲下一代跨多端多平臺研發模式的一切條件，圍繞Flutter創建集團的多端多平臺研發體系是很是可行的選擇。

最後講一下 UI 表現力。電商業務重體驗，重交互，尤爲對於流量精細化運營場景，富交互的遊戲化表現方式已經成爲流量促活的重要手段。 在 UI 表現力方面，前端體系一直具有着優點，經過 CSS3 強大的動畫能力，開發者能夠很是容易的實現複雜的動畫效果和交互體驗，而基於 Native UI ，須要藉助各類動畫特效三方庫，雙端開發體驗不一致，實現複雜且交付效率低
.Flutter很好的解決了這個問題，從補間（Tween）動畫、基於物理屬性的動畫，到相對複雜的頁面間Hero動畫、parallax交錯動畫等特效，Flutter均可以跨平臺低成本的高效實現。

這裏貼一個去年年末Flutter Interact大會上GSkinner公佈的基於Flutter實現的交互Demo讓你們直觀感覺一下：點擊此處

能夠看到 Flutter 的強大 UI 表現力，能夠幫助開發者快速高效低成本的開發出極爲炫酷的 UI ，很是適合電商領域重 UI 視覺交互的各種場景，幫助業務構建出富有表現力的頁面。

Flutter體系化建設現狀

目前集團內有多個業務 BU 均已開始嘗試應用 Flutter 技術棧，涵蓋了從電商詳情業務、導購頻道，到 Feeds 流、遊戲化交互以及國際化等多個業務場景。 目前 Flutter 技術在集團應用的痛點在於，研發基礎設施的中臺基建不夠完善，研發支撐能力與數據運維能力未實現標準化，集團 Flutter 開發者生態還未徹底拉通，暫時未能造成協力。這些問題將是咱們後面在集團層面建設 Flutter 技術體系的重點。

另外一方面從行業趨勢上看，Flutter 技術已經成爲愈來愈多行業夥伴重點投入的技術建設方向。字節跳動、美團等公司均建設了本身的 Flutter 工程化體系，並服務了各自的業務場景；騰訊也基於 Flutter 在多個 App 上進行了應用嘗試，並在 Flutter 渲染能力服務小程序的場景下作了有益探索。

行業夥伴們在 Flutter 技術上的投入力度和決心，一方面讓咱們對 Flutter 技術的應用前景和社區更有信心，另外一方面也讓咱們感到聯合集團各方力量共建 Flutter 生態的必要性和緊迫性。

▐ 手淘的嘗試和思考

最後，簡單講一下咱們從18年到如今在 Flutter 上作的探索和思考。

手淘從18年10月開始探索 Flutter 渲染引擎應用在小程序場景；19年下半年開始建設 Flutter 基礎能力，並服務了淘寶特價版業務，在引擎、圖片庫、內存優化和加載性能等關鍵技術上作了沉澱；同時經過對 Flutter 的引擎改造，封裝出 Flutter 2D Canvas 能力，向上支持小程序 Canvas 組件及小遊戲引擎，服務 2D/2.5D 遊戲化業務，並在業務場景中落地。

在這個過程當中，咱們也沉澱瞭解決內存問題和圖片問題等方案，以及 Flutter 技術與 Web 技術的對比與思考，取得了必定的技術及業務價值。 經過這些嘗試，加深了咱們對 Flutter 技術的掌控力和理解。在咱們看來， Flutter 的橫空出世，徹底能夠被看做吹響了 Native 體系復興的號角。 在保持 Native 性能優點的前提下，Flutter 帶來了優秀的跨端一致性、貼近前端的研發效率，以及強大的 UI 表現力，爲集團業務使用 Native技術棧帶來了新的可能。

從業務應用上看：Flutter 目前帶來的最大價值是研發效率的提高。在基建和 native 擴展能力完備的前提下，開發基於 Flutter 的純 Dart 業務的人效比以前各端分別開發的效率提升了接近 2 倍，單位時間內的需求響應能力也相應提升了接近2倍，目前已在閒魚和特價版業務開發中獲得了很好的工程化驗證。

從適應場景看：Flutter 目前比較適合承載富圖文內容，如詳情、Feeds 流、用戶主頁等常規業務開發，以及 2D/2.5D 遊戲場景以及富動效業務。 Flutter 經過單端技術棧能夠同時知足之前須要 iOS、Android 以及前端技術棧分別負責的業務場景，甚至能夠經過端雲一體化的開發模式使用 Dart 負責一部分服務端業務邏輯開發，能夠幫助業務團隊拓展業務邊界的同時，實現先後端研發能力閉環。

Flutter 目前的限制在於，動態性能力及前期的投入成本。前期投入成本主要指技術學習與團隊研發模式升級的成本，涉及到技術路線選擇，是咱們和每一個業務團隊須要一塊兒思考和判斷的，這裏不展開談。

動態性能力是 Flutter 的相對短板，目前可以經過 Flutter 模板化技術實現基於模板的組件級動態化能力，但基於性能、審覈及對原生 Flutter 體系的侵入性等多種因素，目前還不能去直接實現UI + 邏輯動態化能力。 Flutter Web 方案雖然不存在審覈限制，但受限於瀏覽器 DOM API 與 widgets 體系的差別性，目前仍舊存在較嚴重的性能瓶頸和渲染差別性，僅可做爲降級的備用方案，暫時沒法做爲動態化的主要實現方案。

將來在動態化方向的探索也將是個長期的博弈過程。若是後面咱們能夠解決好 Flutter 動態化的問題，那麼 Flutter 徹底有機會成爲集團業務的核心研發模式之一。

綜上咱們認爲，入局 Flutter 的時機已成熟，協力共建 Flutter 集團移動生態，這件事情大有可爲。

AliFlutter - 經濟體移動小組Flutter共建項目

在這樣的背景下，經濟體移動技術小組今年也將端側架構治理的重點方向放在了 Flutter 上。移動技術小組從戰略角度提出了 AliFlutter 項目，目標很是明確：

• 從經濟體層面拉通 Flutter 體系建設，打造 Flutter 的公共技術基礎設施，制定 Flutter 容器、中間件與 API 標準，建設 Flutter 研發支撐與數據運維能力，複用關鍵技術；
• 聯合各 BU 構建經濟體Flutter技術社區，沉澱共享集團 Flutter 技術及業務組件、能力與解決方案，服務集團 Flutter 業務，共建集團 Flutter 技術生態；
• 在經濟體層面構建 Flutter 的對外影響力，聯合各 BU 一致對外，打造阿里在行業內的 Flutter 技術制高點。

爲經濟體的 Flutter 技術體系「建基礎、育社區、扛大旗」，咱們義不容辭。

將來 AliFlutter 的總體架構以下所示：

AliFlutter 建設的第一步，就是要構建集團的 Flutter 基礎設施、提供公共容器與組件、研發支撐服務與標準化研發流程，爲集團的 Flutter 業務提供一個基礎的Flutter公共研發服務能力，搭建好技術共建共享的基礎和平臺；

第二步，咱們要服務好 Flutter 業務應用，探索業務應用模式與 Flutter 技術特性的結合點，並在過程當中打磨技術，造成針對業務特色的解決方案與技術沉澱，真正盤活集團內的 Flutter 社區共建氛圍與生態；

第三步，面向將來，解決好Flutter應用的幾個核心關鍵問題：跨端與交互能力、業務研發效率與業務交付效率，經過技術賦能業務，讓 Flutter 真正成爲集團移動業務的核心研發模式。

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

基礎設施建設

從19年10月 AliFlutter 項目啓動開始到如今，咱們基本構建起了一套 Flutter 的公共基礎設施，包括 Artifacts 與 pub 庫，Flutter 標準容器與 API 標準，並實現了 Flutter 的構建打包自動化，定義了標準的引擎定製工做流與業務研發工做流。目前基礎設施已經具有支撐集團 Flutter 業務研發的能力，並支持各 BU 按需定製。

▐ Artifacts倉庫

產物服務器主要是爲了配合引擎定製，加速經過 Flutter 命令獲取 Engine 中間產物的後端服務，便於統一 Flutter 開發者的工做環境。

開發者可經過設置 FLUTTER_STORAGE_BASE_URL來將Flutter工具鏈獲取 artifacts 的地址指向該服務，同時經過 namespace 即可實現定製化的獲取 artifacts 的能力以及內網加速服務。

Namespace 設計爲區分不一樣 BU 的引擎產物，同時提供了公共 namespace 來存儲公共產物，確保定製性和公共能力的按需配置；若後端存儲上不存在須要獲取的產物地址，則會觸發從 Flutter 官方鏡像作一次獲取並緩存在服務端。

各 BU 可按需定製引擎，並按規定的路徑格式上傳至本身 namespace 中，便可實現從 namespace 中獲取定製版本的引擎中間產物。

▐ pub倉庫

相似於 Node.js 世界的 npm，Flutter 使用 pub 來管理三方組件與依賴。考慮到易用性、安全性等需求，爲了管理集團內的公共二方組件，咱們也搭建了內網環境的 Flutter pub 庫。該庫的目標是成爲集團的 pub 發佈平臺，管理集團內全部2、三方 pub package。

用戶可經過設置 PUB_HOSTED_URL 指向內部地址，來實現經過 Flutter 工具鏈獲取配置以及發佈二方 pub 的能力，用戶也能夠經過 Web portal 的方式訪問 pub 庫並查詢已發佈的 pub 組件。

▐ 容器、中間件與API

對於業務的接入而言，現階段核心要解決的問題就是提供一個統一的 Flutter 運行時容器，以及一系列集團標準化移動中間件的 Flutter 封裝與 API 能力，並提供集團標準的插件擴展方式供業務方獨立開發業務功能。

鑑於集團應用基本上均以混合棧爲主，咱們將 FlutterBoost 做爲 Flutter 容器混合棧的基礎，並配合集團標準路由與導航中間件提供了統一的混合棧路由導航能力，業務經過標準路由註冊便可快速實現 Flutter 頁面和 Native 頁面的混合導航能力。

容器經過對接高可用平臺，提供了初始化性能埋點與 Crash 數據上報等標準監控能力，爲 Flutter 業務的技術性能分析和問題排查提供了基礎。集團移動端積累了一整套的標準中間件體系，包括網絡庫、圖片庫、push 消息、配置下發、數據採集與監控等一系列基礎能力，在 Flutter 體系內無縫使用移動中間件能力對於業務是剛需。

同時，小程序體系建設過程當中造成的一系列標準 API，也很大程度上實現了一個完整的小程序運行環境的底層能力抽象，對於 Flutter 體系標準化的訪問系統能力，實現平臺無關的跨端能力是個很是好的補充。咱們聯合淘寶中間件團隊與小程序團隊，對基礎中間件和小程序 API 實現作了 Flutter 側的封裝與標準化，將來也將對 Flutter 中間件和 API 能力進行系統支持。

▐ 標準化Flutter構建

因爲 Flutter 研發體系較新，且構建 Pipeline 相較傳統的移動構建流程又存在必定特殊性，產物構建配置複雜耗時長易出錯，給 Flutter 業務的構建和發版帶來了很大阻礙。 所以咱們也聯合研發支撐部的同窗，以插件的形式實現了 Flutter 腳本化的構建流程，支持雙端自動整包打包和 Flutter Module 打包。 目前 AliFlutter 的構建流程默認使用 AliFlutter 的 Flutter 倉庫以及集團內部 pub 倉庫，引擎產物也統一按配置從 artifacts 倉庫獲取，較好的實現了支持 Flutter 業務的自動化構建需求。

業務應用

在夯實 Flutter 集團共建基礎以後，第二步，咱們 AliFlutter 在業務應用方面也作了大量工做。

一方面經過原生 Flutter 的工程化能力持續服務淘系與集團業務；另外一方面經過 Flutter Canvas 項目服務了小程序場景及遊戲化場景下的互動業務

▐ 淘系與集團業務支撐

目前淘寶特價版已完成詳情業務的 Flutter 改造並上線，採用 Flutter 使業務在需求節奏不變的狀況下人力投入減小一半，對緩解業務研發壓力起到了明顯的做用；同時應用的總體性能和穩定性與 Native 基本持平。

後續特價版將基於 Flutter 繼續拓展業務改造範圍，並沉澱基於 Flutter 的業務域解決方案。

目前盒馬、ICBU 、優酷也基於 AliFlutter 進行了容器接入升級與業務適配，盒馬依託閒魚的 Flutter 遊戲引擎實現了盒馬小鎮業務，ICBU 在主鏈路相關頁面使用了 Flutter，優酷則基於 Flutter 實現了會員訂單頁等場景。同時咱們也在和釘釘及 Google 一塊兒探索 Flutter 桌面端的解決方案。

▐ Flutter Canvas

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

在小程序場景中 Canvas 做爲承載互動遊戲的主要能力發揮了重要做用。然而受限於小程序架構下 app context 和 page context 的隔離設計，存在從 app worker 到 page renderer 的通訊瓶頸，沒法充分發揮出 web canvas 的性能，若是有一個 native 版的 canvas 實現將可直接在 native 層對接 app worker ，下降通訊成本，充分發揮 Canvas 的性能。

Flutter 底層基於 Skia，其性能和移動端複雜異構機型的適配性均獲得過長期的檢驗，且 Flutter 基於瀏覽器的設計實現了一條平臺無關的渲染管線，並對瀏覽器實現作了極大的簡化，提供了很好的可靠性和性能。那麼若是可以將這條渲染管線直接用於向業務容器提供 Canvas 能力，經過 binding 方式直接向小程序和小遊戲容器提供與 Web Canvas 一致的標準 API，一方面能夠複用 Flutter 的底層能力，爲非 Dart 環境提供渲染支持，另外一方面能夠藉助 Flutter 簡化高效的渲染管線實現提供更好的渲染性能。

目前 Flutter Canvas 已落地手機淘寶，並在小程序運動銀行業務進行了灰度試點，初步具有了承載小程序 Canvas 業務的能力；其性能在 Android 低端機上的表現有優點，能夠做爲 Web Canvas 方案的有益補充。

將來 Flutter Canvas 一方面將藉助 Flutter 渲染管線的跨平臺與高性能特色，以及 Flutter 對 Vulkan 和 Metal 的適配支持，在移動端得到更好的適配性以及性能；同時將繼續實現 3D API ，支撐將來互動類的業務應用。

將來建設

紮根業務以後，接下來的第三步，咱們要緊貼 Flutter 體系在阿里集團將來的建設目標，持續回答好Flutter面向將來建設路徑中的幾個關鍵問題。那麼首先，Flutter體系在阿里集團的建設目標應該是什麼？我的覺得：

Flutter應成爲阿里集團將來跨多端多平臺的核心業務研發模式之一。

那麼，咱們目前離這個目標還有多大差距？在我看來，若是要想讓Flutter成爲業務的核心研發模式，那麼必須解決好跨端能力、交互能力、業務研發效率以及業務交付效率四個核心問題。

• 從跨端能力看：Flutter雖然已具有了很好的跨多端能力與高還原度，但涉及到平臺能力時，仍然須要經過各端擴展實現，還未造成小程序體系這樣的標準化的容器和API封裝能力。那麼如何更好的解決Flutter的容器化問題，讓業務不感知平臺差別性？
• 從交互能力看：Flutter如何利用好自身交互能力的優點，在提供媲美前端的富交互體驗的同時，下降Native富交互特性開發的門檻，真正吸引Native開發者使用Flutter技術開發業務？
• 從業務研發效率看：雖然 Flutter 的 Hot Reload/Hot UI 機制已經讓開發 Native 頁面的效率追上了前端，但在工程解耦方面仍然有很大提高空間，目前還沒法高效的支持多業務團隊並行開發；另外一方面如何與現今流行的 Serverless 能力結合，實現端雲一體研發模式，使業務實現研發閉環，也須要實踐的檢驗。
• 從業務交付效率看：目前 Flutter 仍屬於 Native 方案，依賴端側發版，交付效率低，沒法很好的承載電商系靈活性和實效性的需求；那麼如何解決Flutter的動態化，幫助業務實現快速迭代？

解決好這幾個問題，才能真正讓 Flutter 成爲集團移動業務的核心研發模式，爲集團業務研發帶來一個飛躍性的提高。下面講講咱們在這幾個方向的思考和探索。

▐ 提高跨端能力：Flutter 容器化

從工程角度看，雖然 Flutter 經過 Skia 跨平臺圖形渲染和自建事件體系基本實現了對宿主平臺的最小依賴，但對於平臺側能力，目前 Flutter 還未也沒有必要從應用框架角度作到一個統一的抽象，這就須要咱們根據業務的訴求和特色進行有選擇的封裝。

小程序 API 就作了一個很是好的示範，目前阿里小程序體系提供的API達到了200+，很好的對移動端的UI、多媒體、文件緩存、網絡、設備能力、數據安全以及業務相關能力進行了封裝，讓業務開發者在小程序側針對API進行系統能力調用，無需關心平臺實現。

所以 AliFlutter 容器接下來的規劃就是從工程體系的角度，提供一套標準化的 API 能力，以規範並抽象移動端的端基礎能力，使業務儘可能少甚至不關心平臺差別性，專一於業務；同時藉助標準化 API 的能力，實現跨多端多平臺部署。

從移動端架構角度看，各個時期的跨平臺方案都對 API 能力有着共同的訴求，從 H5 到 Weex ，再到後面的小程序，以及 Flutter 等容器環境，進行了多輪的 API 重複建設，形成了缺乏 API 接口的標準化定義，以及缺乏實現層統一管控的現狀。

若是可以在 API 的 native 實現上作到接口統一，再經過各個容器分別提供接口供業務使用，能夠更好的作到實現收口，並在統一實現層跨容器實現對系統資源的統一調度、管控和度量。

▐ 提高交互能力：UI + 遊戲引擎

前文提到過，Flutter 目前最大的價值在於研發效率的提高，這是吸引業務團隊應用Flutter技術的起點；但僅僅依靠研發提效還遠遠不夠，當經過各類工程化手段解決好當前研發痛點，提高研發效率以後，如何說服業務繼續使用Flutter體系進行業務開發？Flutter帶來的長遠價值在哪裏？

我的認爲，這個落腳點應該在經過遊戲交互能力的泛化，打破 UI 與遊戲引擎的邊界，用遊戲化的方式創造更有表現力的交互體驗，創造新的業務玩法和價值。

你們知道傳統的 UI 和遊戲引擎是相互獨立的兩個體系，在 H5 應用中，每每是經過 DOM 或者上層應用框架作 UI，經過創建在 canvas 上的 H5 遊戲引擎實現遊戲能力。

若是在遊戲應用中有 UI 的需求，解決方案通常是自建一套簡單的 UI 體系與事件體系，經過自繪的方式在遊戲中疊加 UI ，獨立遊戲引擎亦是如此。

Flutter 從技術原理上看更像是一個創建在 Skia 圖形庫上的遊戲引擎，它經過細粒度的 widgets 設計向上構建 UI 系統；一樣得益於這樣的細粒度設計，咱們也徹底能夠直接經過 widgets 能力組合出一個完整的遊戲引擎，提供Game，Scene 及 Sprite 動效等 widgets 並擴展對應的 elements 和 render objects，並與 UI 體系共用一套事件處理機制、分層與渲染合成機制。 這樣作就至關於打破了原來H5中DOM UI和Canvas遊戲的邊界，讓兩個體系在 widgets 概念下完美融合起來，經過遊戲引擎的能力賦能UI實現更多之前UI體系難以低成本實現的動效效果（好比一隻小盒馬一口吃掉了一個訂單組件等等）。

咱們相信，這個方向的探索將會進一步釋放 Flutter 的技術潛力，帶來更多的業務可玩性與創造性，解放產品和設計的想象力，爲業務創造更多價值。

▐ 提高研發效率：工程解耦與端雲一體化

Flutter 工程解耦

前端體系的研發效率很大程度上來自於基於 URI 的統一路由體系帶來的頁面間解耦性，與頁面內基於 Web API 的標準化帶來的內聚性。 然而目前的 Flutter 研發模式，仍須要多個業務團隊工做在同一個工程下，互相之間存在源碼依賴，將來若是跨業務團隊大規模應用Flutter技術，必將拖慢業務的研發效率。

從工程解耦角度看，目前 AliFlutter 容器經過混合棧與標準路由能力基本實現了頁面研發的解耦，將來的容器化建設經過提供小程序對等的 API 能力封裝，業務對平臺無感知，可以讓咱們有機會解耦業務研發，實現與小程序開發接近的研發體驗和效率。

理想的方案是：業務能夠從業務維度建立一個獨立的 Dart 工程，只包含業務相關的頁面和邏輯代碼，經過 Flutter 的 Hot UI 開發頁面，經過IDE提供的基於 Flutter Web 的能力本地預覽工程並調試 API 與系統調用，完成研發期工做；也可生成預覽二維碼，使用預裝有 AliFlutter SDK 環境的宿主應用掃碼預覽；研發與構建鏈路分離，雲端主動拉取業務倉庫代碼參與整包構建。以此達到相似小程序研發方式的前端研發體驗，同時實現業務間的研發解耦和並行發佈，提升業務的交付效率。

端雲一體化

現在 Serverless 概念愈來愈多的受到業務研發的重視和應用，集團在新一代的端雲一體化研發模式上的探索這一年多來也作的如火如荼。

結合輕量級容器環境、多語言支持能力與統一的 API 服務端編程，端側同窗能夠很容易的使用客戶端語言如 Java、JS、Swift 甚至 Dart 來開發服務端業務能力，實現服務編排、服務端 FaaS 業務邏輯與 API 自動生成，達到先後端工程體系歸一，業務研發閉環的效果。

目前閒魚在 Dart FaaS 雲端一體化的探索走在了前面，經過集團的容器規範實現了Dart function容器，並聯合服務端爲部分業務須要的領域服務抽象出來 BaaS 層（存儲、消息隊列等），並封裝了面向前端的 BFF（Backend for Frontend）能力層，使移動端開發者能夠很容易的使用Dart封裝FaaS業務邏輯，同時進行移動端和服務端 FaaS 開發，大大提升了業務研發效率。

經過將原有的端側請求接口、組裝數據並轉換爲 ViewModel 的邏輯都後移到了服務端，通過字段映射與頁面編排，移動端可直接獲取 ViewModel 並刷新頁面，經過 BinderAction 雙向交互狀態數據，有效屏蔽了通訊細節，提升了開發效率。

雲端一體化除了帶來了研發與協同效率的提高，同時也重塑了生產關係，使端側業務從只關注端側體驗和邏輯的開發角色，變成可以向業務總體結果負責；同時也讓服務端更專一於領域服務的沉澱。

Flutter 良好的跨端特性，可以屏蔽掉端差別化，配合 Flutter 容器化改造，更近一步的簡化了業務的全鏈路研發模式。

將來如何在 FaaS 模式下，沉澱出一套能夠服務集團業務研發的通用端側和服務端通訊調度框架，讓集團 Flutter 開發者和業務都能共享到 Serverless 技術和雲端一體化提效的紅利，是須要咱們共同去探索和定義的新問題。

▐ 提高交付效率：Flutter 動態化

實現動態化是交付效率提高的重要方式。 對於電商強運營強時效性特性來講，動態化幾乎是一個必備的訴求，但從技術上看也是一個很是敏感的需求，是一個在系統廠商平臺管控下長期博弈的過程。

在我看來，動態化技術須要解決的核心問題，是在保證業務發佈肯定性的前提下，尋求技術性能、業務迭代效率與靈活性三者之間合理的平衡點。

下面講講咱們在 Flutter 動態化上的兩個思路與嘗試： Flutter 模板化方案與 Web on Flutter。

Flutter 模板化方案

動態模板化方案是集團內較爲成熟的一套基於Native技術的模板化方案，專一於 UI 模板渲染，沒有執行邏輯和運行時環境，目前被普遍應用於電商系的一些核心業務場景。

同時該方案提供了配套的組件平臺，支持在線模板編輯、預覽、測試及發佈整套流程，結合發佈平臺造成了一整套完善的業務開發生態閉環。

在 Flutter 體系下，目前閒魚團隊依據標準模板協議在 Flutter 側實現了一套 Dart 版 SDK ，經過模板下發實現了Flutter端的輕量級動態化組件編排能力；並經過一年多的迭代逐步解決了渲染性能與渲染一致性問題，較好的賦能了Flutter業務的組件動態化能力。

那麼，將來 Flutter 與動態模板化方案有沒有更好的結合點？

答案是確定的。從 DSL 角度看，目前模板的寫法基本上來自 Android XML ，對組件開發者尤爲是非 Android 開發者不夠友好，具有必定的學習成本；而 Flutter 的結構與屬性都可經過 widgets 表達，能夠極爲靈活且平臺中立的用聲明式代碼構建UI並綁定數據，易於開發者編寫組件並經過 Flutter 框架獨立調試與測試；在移動端運行時，能夠按需按場景翻譯成 native 組件或 Flutter 組件。 將來咱們也將持續在這個方向上作探索。

Web on Flutter

相比貼近 Native 研發模式的模板組件化渲染方案，Web on Flutter 但願經過類 H5 的 DSL + JS ，藉助Flutter的渲染能力，實現貼前端技術棧的動態化能力。

目前基於 Web 渲染的小程序方案存在啓動耗時高，渲染性能距原生 UI 有較大差距等性能問題，這些問題很大程度上都源自於瀏覽器引擎的設計歷史包袱（渲染管線複雜、CSS multi-pass layout及legacy實現等），以及JS到Native通訊效率低（bridge）。

Flutter 的設計思路源自瀏覽器，一方面直接吸取了前端框架近年來的演進成就，原生支持了聲明式-響應式編程範式，提升了移動端的研發效率；另外一方面，Flutter 緊貼 native 開發模式有限定義了 UI 結構、佈局與渲染的必要元素，在知足native UI開發模式的前提下簡化了能力定義與佈局算法（single-pass layout與repaint boundary等概念），很大程度上簡化了渲染管線的複雜度，直接爲Flutter帶來了接近原生的性能體驗。

同時，Flutter 的 widgets 設計巧妙，結構佈局屬性等基礎元素均使用 widgets 表達，且可經過基礎 widgets 的組合來構成複雜組件，這種細粒度+組合能力設計讓 Flutter 有極強的表現力，並具有向上對接各類研發模式的可能性。

所以，經過 widgets 組合小程序 DSL，支持小程序 CSS 有限集，實現渲染層替換瀏覽器引擎，並對接JS引擎支持JS執行能力，是一個將Flutter應用於小程序生態的合理探索方向。

相比把開發者慣壞了的瀏覽器，這種方案在 CSS 的能力支持上必然是受限的，沒法知足全部 CSS3 標準的實現，更多經過緊貼 Flutter widgets 的現有能力以及必要的 widgets 擴展，在不破壞 single-pass layout 的前提下組合出 CSS 能力。

但從 Flutter 原生開發的角度看，只要 Flutter 現有的原生能力可以知足業務需求，那麼受限的 CSS 實現也同樣能夠提供和 Flutter 對等的能力解決業務問題。同時，經過受限的 CSS 能夠換來與 Flutter 至關的高性能，與基於 Web 的實現相比，在性能上帶來了質變。

咱們在18年末經過一個內部項目實現了這個思路的原型，經過使用 C++ 重寫 Flutter 的 widgets、rendering、painting 及事件管理等 Dart framework 中的中低層能力，並在 widget 上用 C++ 實現了 CSSOM + DSL -> Widgets 的響應式框架，直接從 C++ 層提供 render 實現，將傳統由 JS 承擔的模板展開、tree-diff計算與渲染工做交給C++層，經過Flutter提供的Widgets tree到RenderObjects tree的diff能力實現，顯著提升了性能。

從實現的簡單的demo看，相對小程序的web渲染性能有了大幅的提高。這種方案的問題在於和Google代碼庫分裂後的長期維護性。「Flutter和Web生態如何對接」這篇文章對集團內在這個方向上嘗試的幾種思路作了較爲全面的對比，將來咱們也將繼續在這個方向上作深刻和持續的探索。

總結與展望

Flutter 體系化建設目前在淘系剛剛起步，仍然有大量工做須要去作，咱們在基礎設施、工程化以及經過Flutter定義和收斂業務域研發模式上作的許多建設性的事情，正朝着把Flutter打造爲統一移動應用基礎研發框架，助力業務迴歸移動端研發模式這個大目標一點點邁進。

在移動技術小組啓動 AliFlutter 項目以前，閒魚技術部已經在 Flutter 技術建設上作了大量探索和投入。

一方面經過 Flutter 技術賦能業務提效升級，拿到了很好的業務成績；

另外一方面沉澱Flutter的技術與業務解決方案，並經過開源反哺社區，在海內外Flutter技術社區中創建了顯著的技術影響力與領導力，也涌現出一衆Flutter技術專家。

接下來AliFlutter的重點任務，就是要和閒魚、財富等先驅應用者以及盒馬、釘釘、飛豬、優酷、餓了麼、CBU等Flutter的實踐者一塊兒，在集團層面把Flutter的場子建起來，把集團Flutter生態拉起來，讓技術和經驗可以共同沉澱和分享，一塊兒來把Flutter技術體系在阿里的應用生態內作大作強，真正成爲集團業務的核心研發模式，並讓每一個參與者都能從中受益。

咱們一直堅信 Flutter 技術的先進性和應用前景，將來咱們將繼續立足淘系服務集團業務，和集團開發者攜手前行，在 Flutter 這個技術方向上堅決的走下去。