作者|董岩(思牧)
出品|阿裡巴巴新零售淘系技術部
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 釋出平台，管理集團内所有二、三方 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 這個技術方向上堅定的走下去。