Flutter 這兩年的熱度不斷提升，行業內投入建設 Flutter 的公司也越來越多，有很明顯的上升趨勢。
作爲一個技術框架，Flutter 該有的功能都有了，但要把它應用到業務中去，還得解決工程問題、複用已有的技術積累、融入業務的工作流等，還要針對特定的業務場景做增強和擴展。所以，我們的核心目標是把 Flutter 從一個單點的技術框架，打造成完整的企業級解決方案。
Flutter 社區發展情況
在官方四月底的統計數據中，自發布以來的 16 個月內，已有 200 萬開發者使用 Flutter，三月份的時候也有 10% 的增長，Google Play Store 中發佈的 Flutter 應用約有 5 萬個，僅在 2020 年 4 月就有近 1 萬個應用上傳。開發者所在的團隊，初創公司最多，佔了 35%，26% 是企業開發者，19% 是獨立開發者，還有 7% 的設計機構。
Flutter 使用者數量排名前五的地區是印度、中國、美國、歐盟和巴西。很神奇，國內開發者對 Flutter 的熱情比出生地美國還要高。從各種公開信息來看，頭條、微信、QQ、美團、抖音、快手都對 Flutter 保持的密切的關注，而且已經不是小規模嘗試了，有些公司已經鋪開準備大規模建設了。
簡單來講，Flutter 的發展勢頭越來越猛，國內大公司都在建設，Flutter 更受新興業務的青睞。
阿里淘系的業務背景
淘系業務面臨較大的競爭壓力，整個移動互聯網的競爭也越來越激烈，爲了吸引並留住用戶，對產品的性能、使用體驗和迭代效率都有更高的要求，像直播 / 短視頻 / 沉浸式交互 /AR//3D 等新交互形式可以明顯的提高業務競爭力，這些技術基本上都是原生能力，所以需要一個和原生技術結合度好，而且又能避免寫重複代碼的技術方案。Flutter 比較符合這個定位。
除了淘寶 App 本身，還有一系列淘系應用，如閒魚、淘寶特價版、直播 App、躺平等新興應用不斷出現，整個阿里已經有 30+ App 在使用或者在嘗試 Flutter 了，爲了減少重複建設，需要沉澱出通用的技術能力，站在現存的技術積累之上，打造出完整的技術體系。
阿里在 Flutter 的技術積累
手淘從 Flutter 剛誕生以來就對它保持關注，2018 年開始就持續做技術探索，去年啓動了 AliFlutter 的項目，希望可以拉通阿里內部 Flutter 相關的技術積累，有了一些初步的成果。
基礎設施建設
首先標準化了 Flutter 的工程構建。有統一的代碼倉庫來管理 Flutter 的源碼，有專門的升級發版節奏，確保可以跟進官方的迭代。客戶端打包的環境配置比較複雜，還要和阿里自身的開發環境做融合，這些功能已經形成了平臺和工具，也開放了部分功能讓大家可以定製和擴展自己的引擎。
另外還提供了阿里內部的 pub 庫實現包管理，類似前端的 npm，讓 Flutter、Dart 的通用功能庫有地方可以承接。
而且還與手淘的基礎設施做了緊密結合。對接了內部的摩天輪（MTL）打包平臺、性能穩定性監控的高可用平臺，手淘基礎的圖片庫、網絡庫、日誌、埋點和一部分基礎中間件。Flutter 的開發、測試、打包、集成、發佈、運維監控等功能，都融入了客戶端開發本身的工作流中。
完善 Flutter 的基礎設施是後續所有工作的基礎，讓 Flutter 開發不再處於刀耕火種的工作環境。
內核增強與擴展
把 Flutter 落地到業務的過程，也不是一帆風順的。性能倒不是瓶頸，但是包體積太大、內存佔用高是經常遇到的問題，所以去年有一部分精力花在 Flutter Engine 本身的優化上，分析二進制產物的包結構，壓縮 Flutter Engine 和 Dart AOT 編譯產物的大小。分析 DartVM 的內存管理機制和 snapshot 功能，不斷優化內存。而且有針對性的對圖片庫的內存、Engine 的啓動流程做了優化。
在圖形化方面，Flutter Engine 提供了一套兼容性和性能都比較好的圖形接口，而且跨平臺一致。所以基於 Flutter Engine 封裝了 2D Canvas API 透出到 JS 環境，性能和穩定性相比之前的技術都有大幅提升。而且對接到了淘寶小程序的容器環境，支撐互動類的業務。
信息互通
在阿里內部建立了 AliFlutter 信息互通的虛擬組織，淘寶、閒魚、特價版、飛豬、盒馬、UC、釘釘、CBU/ICBU、優酷、本地生活、搜索、天貓精靈等 BU 都有接口人在參與，定期開會同步信息，避免出現重複建設。
另外在社區我們和 Google 官方團隊也保持着聯繫，定期開語音會議。這個合作關係建立之後，在社區也可以混個臉熟，我們提的 issue 和 PR 說不定會被優先處理~
技術探索和實踐
我們團隊積累了 15+ 高質量的技術文章分享在內部的技術論壇，在原理分析、性能優化、應用和實踐這三個大類裏，分析 DartVM 的原理以及背後的 GC 和 Snapshot 機制，研究 Flutter 的渲染管線，思考 Web 生態和 Flutter 對接的方案，優化 Flutter Engine 的啓動時間和包大小，解決實際業務中圖片庫接入、長列表內存佔用高等問題。
- 阿里 Flutter 體系化建設
- 閒魚 Flutter 一體化演進之路
- Flutter Widget 和 CSS 佈局原理 PK
- Flutter 和 Web 生態對接
- Flutter 渲染引擎深入分析
- 在 Flutter 體系中對接手淘圖片庫
- 細化 Flutter List 內存回收，解決大 Cell 問題
- Flutter 瀑布流及通用列表解決方案
目前待解決的問題
下圖左側是 Flutter 官方做過一次問卷調查，評選出了開發者實際開發過程中最關心的問題。
前六項任務摘錄出來如下：
這是面向所有社區開發者的問卷，我們在實際業務中遇到的問題也類似，總結下來主要是對開發效率、調試測試、解決方案、功能複用的訴求比較強烈。說明 Flutter 作爲一個新興的研發模式，在工程、工具方面做得還不夠成熟，生態還不夠繁榮，尤其是貼合業務場景的解決方案比較少。
這些問題是我們下一步的工作重點，從實際的業務痛點出發，不斷完善 Flutter 的內核能力和平臺支撐，在保障產品質量和體驗的同時，提升業務的交付效率。
總結與未來規劃：Unicorn 獨角獸
用「獨角獸」項目孵化更多「獨角獸」。快速迭代，野蠻增長！
解題思路
前面介紹了，這個項目的核心目標是：
- 在業務視角，完善 Flutter 的研發模式和平臺支撐，在保障產品質量和體驗的同時，提升業務的交付效率。
- 在技術視角，建設產品化的 Flutter 技術體系，將一個單點的技術框架，打造成完整的企業級解決方案。
爲了實現上面的目標，我們從四個層面做建設，最下面是對 Flutter 本身內核的增強，然後再向上提供一站式的研發平臺提升業務的迭代效率，同時也提供產品化的服務保障整個項目可持續迭代，最上面是業務支撐，解決在業務落地過程中實際遇到的問題。
這個項目並沒有推翻任何積累，沒有造新輪子，而是用更加體系化的方式，梳理在做的關於 Flutter 的事情，做一個整體規劃，並且和集團內所有做 Flutter 技術的團隊保持信息同步，以開放的心態做技術，技術成果互通互享。
整體規劃
順着上面的思路，把各項內容展開來看，是這個樣子的：
整個項目是在之前的技術積累上進一步做建設，首要原則是降低對 Flutter 本身技術的侵入性，確保架構可持續迭代。因爲 Flutter 還是一個快速迭代的技術，一旦開始分化，再跟進官方的進展就很難了，前期接入的業務就會成爲歷史包袱，要極力避免這種情況。
電商系的業務場景很複雜，不同場景的技術訴求也不一樣，所以架構上要做到可靈活擴展，讓垂直類的能力可以快速接進來，實現差異化。另外爲了降低業務的使用成本，要保證功能的開箱即用，優化開發體驗。
關於演進路線，Flutter 本身的技術特點也比較適合歷史包袱比較少的新興業務，所以優先考慮的是新型 App 和垂直類的業務，然後再推廣到常規業務中。從技術角度是自底向上做建設，首先保障底盤的穩定性，而不是上來就搭花架子。對接好基礎設施之後，下一步是爲業務提效，然後再做擴展和對接，最後沉澱出靠譜的技術方案回饋社區。
基礎能力增強
基礎能力的建設和可以分爲三層：
- 應用層 ：這部分主要解決在業務實踐過程中遇到的問題，提供解決方案。閒魚是 Flutter 的技術先驅，在應用層有很多積累，比如 Boost(混合棧) 和 Candy(遊戲化開發)，除此之外我們還有正在做 DX Flutter 容器 (模板化 / 動態化渲染)，卡片級嵌入 (multi-window) 等技術方案。
- 引擎層 ：這部分逐漸走向技術的深水區，分別在啓動鏈路、AOT 編譯、DartVM、渲染管線、圖形化 / 光柵化等領域做優化和增強，在業務無感的情況下，提升內核的性能和穩定性。
- 對接層 ：這部分工作大部分已經完成，繼續查漏補缺，不斷完善使用體驗。
一站式研發平臺
回顧前面列的 Flutter 還存在的問題，大部分在於工程鏈路和生態不夠成熟，這是業務使用 Flutter 時遇到的最大阻力。這部分帶有業務屬性的工作 Google 官方不會爲你做，必須要企業自己來做。所以除了完善 Flutter 基礎能力之外，面向業務場景，還要有全鏈路的平臺和工具支撐，才能真正提升業務的迭代效率。
基於手淘首頁在用的模板化的框架實現部分 UI 的動態化，加上 Flutter 的跨平臺渲染能力，再結合 GAIA 端雲一體化的研發模式，形成一個完整的研發閉環，從開發者視角整理工作流，用一個平臺提供所有能力。目標是降低 Flutter 在業務中的使用成本，讓開發者可以在 60 分鐘內完成 App 首次接入，30 分鐘內就可以開始寫第一行代碼。
業務支撐
整個項目首先支撐的是淘系 1+X 的 App，貼身解決業務遇到的實際問題。另一方面也會做一些產品化的事情，把可複用的技術方案沉澱下來，有地方承接和展示，而且會貢獻代碼和方案到社區，提升大家在公司內外的技術影響力。
產品化
整個技術產品的邏輯是 Cycle + Core，即「研發閉環」+「跨平臺內核」。
跨平臺內核是對 Flutter 本身的 Framework 和 Engine 持續做增強，保持和官方版本的同步，儘量將通用的代碼合回官方倉庫。研發閉環是根據當前的業務環境、結合已有的技術積累、提供平臺支撐，把功能做得完備，而且好用。
核，深入研究引擎技術；環，不斷提高迭代效率。
技術細節
前面是概述，其中幾項具體的技術我可以簡單介紹一下。
- 工程和效率
在真正的業務實踐裏，很少把一整個 App 都用 Flutter，基本上都是把 Flutter 當成一個模塊引入，在開發和調試 時還依賴自身的各種庫，如網絡、圖片、安全認證等。而 Flutter 的工具鏈是要基於殼工程來打包和調試的，很多情況下，在殼工程裏沒法實現完整的業務邏輯。
所以我們在 Flutter 工具鏈基礎上提供了掃碼開發的能力，直接使用完整的 App，如淘寶特價版，掃碼連接本地環境，修改代碼後可以實時在真機上預覽實際效果。
除了對本地開發環境的增強，我們也在考慮和雲平臺的聯動，藉助 FaaS 的支持，實現在一個工程裏、一套技術棧開發完整的應用邏輯。
- 模板化開發
Flutter 的動態化能力一直是比較弱的，然而電商系的應用對動態化有強訴求，在淘寶 App 首頁和核心交易鏈路裏使用到了一個模板化的渲染框架 DinamicX，可以動態下發模板來驅動頁面渲染，使用到的組件以及綁定的業務邏輯是原生語言開發的，如 Java 和 Objective-C，不支持 JS 等依賴腳本引擎的語言，這樣性能更好，審覈風險更低。
我們正在把這一套成熟的模板化的渲染協議遷移到 Flutter 上來，既不破壞 Flutter 頁面本身的性能體驗，也在一定程度上提供了動態化的能力。
- 多 FlutterView 嵌入
在 Flutter 頁面的某個區塊使用原生組件可以用 PlatformView，還有一種情況是，在原生渲染的頁面裏，某一個區塊是用 Flutter 實現的。也就是說，不拿 Flutter 寫一個完整的頁面，而是寫一個（或多個）組件嵌入到原生頁面中，這項能力在真實的業務場景中也是有訴求的。
Flutter 倉庫的 issue 裏也有人提出了 multi-window API 的需求，我們也在評估各種實現方案，關鍵問題是要不要在多個窗口間複用同一個 Engine 實例，以及如何管理多個 Scene 等。這方面我們也在開源社區裏討論技術方案，及時跟進這項功能的實現。
- 業務實踐
閒魚是使用 Flutter 技術的先驅，積累了比較豐富的實踐經驗，淘寶特價版也在大範圍的使用 Flutter，期待業務開發者們給大家介紹更豐富的細節吧。
本文轉載自公衆號前端之巔（ID：frontshow）。
原文鏈接：