卷首語： Flutter 2.0 來了，而他們早已率先應用了Flutter
作者：田曉旭
2020年3月4日，谷歌發佈了Flutter 2.0，這個版本是Flutter的重大升級，開發人員可以基於此從同一代碼庫構建跨平臺軟件，並在任何平臺上快速構建可移植的應用程序。
2018年12月5日，Google 在 Flutter Live 上宣佈正式發佈 Flutter 1.0 。當時，Flutter的主要目標還是iOS和Android。而現在Flutter 2.0支持使用相同的代碼庫將本地應用程序發佈到5個操作系統，分別是iOS、Android、Windows、macOS 和 Linux，甚至它還可以嵌入到汽車、電視和智能家電中。
Flutter 2.0的發佈意味着 Flutter 已經從移動開發框架擴展爲一個可移植框架，對於Flutter的應用，很多開發者都躍躍欲試。根據谷歌2020年公佈的數據來看，截至2020年第一季度，Flutter共吸引了超過200萬開發者，每月活躍的開發人員數量有將近 50 萬，Google Play Store 上的Flutter應用約爲5萬個。而現在，Google Play Store 上Flutter支持的應用程序已經增長到 15 萬個了。
一個新技術的普及，企業級應用一定會先在頭部互聯網企業產生，並逐步優化降低門檻。那麼國內都有哪些企業率先實踐了Flutter？他們具體是怎麼應用的？下面我們總結了一些比較典型的企業應用案例。
貝殼Flutter混合容器實踐
通常純 Flutter 應用的頁面路由直接由 Flutter 自身來管理，但是對於原生 App 要引入 Flutter 技術，就會涉及原生頁面與 Flutter 頁面之間切換，此時的頁面路由需要單獨管理和實現。
在實踐Flutter混合容器時，貝殼對比了Flutter官方和閒魚FlutterBoost兩種實現方式。通過八個方面的對比，最終選擇了在整體方案上採用官方 1.12 的共享引擎的方式，在路由管理的實現上借鑑閒魚 FlutterBoost 的實現。
貝殼容器方案整體架構圖
具體實踐：《貝殼 Flutter 混合容器實踐》
美團外賣 Flutter 動態化實踐
美團外賣的用戶端和商家端因爲業務特點不同，因此採用的技術方案也不同。用戶端的用戶量龐大，對動態性要求更高，在低PV頁面使用了RN來做頁面級的跨端動態化，而在高PV頁面使用了自研的區塊級動態化和觸達提升；商家端頁面複雜度更高，用戶端實現的小功能，在商家端配置時有很深的層級和複雜的聯動組件，同時商家端還會關聯到發配送等複雜邏輯，因此商家端在選型時更看重跨平臺框架的性能瓶頸與雙端一致性。
早期，美團外賣商家端也曾嘗試使用 RN 作爲跨平臺的技術方案，但過渡版本無法達到預期的要求。這時，Flutter “多端一致”和“渲染性能”上的優勢讓美團外賣團隊眼前一亮，因此決定選用Flutter方案。但當時Flutter仍處於發展階段，很多功能和解決方案都不完善，尤其是在動態化方面，還沒有成熟且大範圍落地的方案，而美團外賣商家端業務發展對於動態化需求又非常強烈，因此美團外賣內部立項了Flap項目，專門來支撐 Flutter 動態化能力。
美團Flap項目是一套完整的業務解決方案，支持大廠應用的複雜業務，而不是重展示輕交互或是 UI 與動態模板的方案。Flap項目使用純Dart語言實現，在不引入其它技術棧的情況下，實現了視圖與邏輯一體化的動態化方案。
據瞭解，截至2020年底，美團外賣業務已經真實上線了 100+ Flap 頁面，40+業務模塊。商家端的跨端與動態化覆蓋度達到 90% 左右，同時在多個業務線實行需求動態發佈流程，可動態上線的需求佔比 60~80%。
具體實踐：《純 Dart 的挑戰：美團外賣 Flutter 動態化實踐》
京東技術中臺的 Flutter 實踐
京東很早就開始研究跨端的開發解決方案，最早使用的是Hybrid App 技術方案，2015年底開始轉向RN技術棧，2018年中，開始關注Flutter技術。
隨着京東內部越來越多團隊使用Flutter，京東內部發布了JDFlutter引擎。在Flutter官方引擎的基礎上，做了功能擴展和優化，包括Flutter工程改造、路由及多頁面管理、擴展UI組件庫、原生能力擴展和Android端動態化支持。
JDFlutter整體框架結構
具體實踐：《京東技術中臺的 Flutter 實踐之路》
飛豬 App的Flutter 實踐
2013年，隨着阿里巴巴All in Mobile，飛豬（當時還叫阿里旅行）也有了獨立的 App。隨着業務的不斷髮展，App變得越來越臃腫，技術改造帶來研發效率/性能體驗提升的同時，也增加了維護的複雜度。由於旅行業務域邏輯複雜，在實際交付時會出現兩端開發理解偏差引發的線上問題，例如機票交易鏈路因爲漏測引發線上故障。
從技術方案來看，兩端的具體實現依賴原生能力，系統平臺層的差異帶來了業務表現的差異，這需要更底層的技術方案來解決。在對比了Native、動態模板、H5、Weex、Flutter等多個方案之後，飛豬最終選擇了Flutter。
2019 年，飛豬開始在商家版 EBK 改造項目上試水 Flutter，在研發效率和用戶體驗上都有不錯的收益。隨着 Flutter 混合技術棧的完善，2020 年飛豬 Android 端在機票航變和酒店相關簡單業務做了 Flutter 試水，對接的首個版本是 1.12，最終穩定性和性能都符合預期，類似機票航班詳情頁的需求一人就可以完成。
具體實踐：《飛豬 Flutter 技術演進及業務改造實踐》
Flutter 2.0發佈帶來了更多的功能和特性，隨着插件生態的豐富和社區生態的完善，相信Flutter的進入門檻會進一步降低，期待未來有更多的企業實踐案例。
目錄
熱點 | Hot
又一個技術風口來了
Docker 起死回生了
觀點 | Opinion
企業架構方法論可以簡化嗎？
推薦文章 | Article
從 0 開始構建核心業務微服務治理平臺的實踐
30 萬行代碼的平臺升級：給跑着的汽車換輪胎