Google I/O Extended ：2025 Flutter 的現狀與未來

大家好，我是 Flutter GDE 郭樹煜，Github GSY 項目的維護人，今天主要分享的內容是「Flutter 的現狀與未來」，可能今天更多會是信息科普類型的內容，主要是分享關于 Flutter 的現狀與未來

現狀

其實 Flutter 從開源到現在一直以來“爭議”還是比較多的，但是開源到現在也有 8 年時間了，如果從內部立項看，去年也已經過了十周年，官方去年也發過十周年的紀念內容，所以兜兜轉轉到現在，其實 Flutter 已經不算是一開始一樣的小眾框架了，比如在國內大廠，它可能不是主力框架，但是也開始融入到各個地方，比如這張圖，我們可以看到不少熟悉的身影：

當然，在中小企業內的比例就更高一些，比如 2025 年 6 月騰訊統計了當前市面上應用熱門跨平臺框架 Flutter、RN 使用情況

Flutter 整體滲透率約 13%，在旅游類應用滲透率最高（29.5%）
React Native 整體滲透率約 9%，在旅游類產品滲透率最高（18.2%）

可以看到 Flutter 最多應用在工具類，而 RN 最多應用于購物類，數據來自騰訊端服務

另外對于 Flutter 在國內的影響還有鴻蒙，自從 2024 年鴻蒙 Next 發布之后，Flutter 也引來了新的進程，由華為主導的跨平臺框架適配鴻蒙 Next 里，Flutter 是最早開源的，而后期華為也針對 Flutter 適配鴻蒙做了許多工作，例如 Impeller 的移植支持：

而之所以會這樣，其中一部分原因就是，也是早期 ArkUI 在底層渲染設計就參考了 Flutter ，甚至有不少以 Flutter 命名，另外其系統的構建基座（GN/ninja）都和 Flutter 十分貼合。

華為近期也提到過，目前鴻蒙 TOP 應用中 40%采用跨平臺三方框架，其中主流就主要以 Flutter、RN 等框架為主，所以可以看到鴻蒙也是為 Flutter 提供了全新的開發場景：

而提到鴻蒙這里就不得不提微信，前面我們看到微信有使用 Flutter，而微信在鴻蒙 Next 的應用上，也有部分頁面是通過 Flutter 進行適配，例如 ArkUI Inspector 下可以看到微信的朋友圈是 Flutter 實現：

另外，在之前微信小程序的 skyline 的渲染引擎，也可以看到是基于 Flutter 的身影：

·read dependencies for .../libskyline.so from cache or meta： 就記錄了 libskyline.so 的依賴庫

當然，這還不是 Flutter 應用最意向不到的地方，你甚至可以在 OPPO 的 ColorOS 的靈動島在運行時的輸出上，可以看到此時 ColorOS 靈動島的 UI 渲染也是基于 Flutter 實現的：

還有 OPPO 的開發平臺上，也可以看到過負一屏相關的 log 截圖，相關輸出也是 Flutter：

前面提到的這些 Flutter 應用場景，上層使用的都是不是 Dart ，只是在底層使用了 Flutter 渲染引擎，類似的我還看到過有一個叫 Shaft 的項目，他用 Swift 重構了 Flutter 的上層，替代了 Dart ，這些也都是 Flutter 的另類應用。

而如果再看一些新的全球使用案例，對應的有：

NotebookLM ：Google 旗下的AI筆記應用，但是在播客圈爆火，能將音頻源轉化播客的對話，之前一直是 Web，而剛剛推出的 App 采用了 Flutter 開發
Google Cloud：新的 Cloud Assist 采用 Flutter 編寫，另外類似 Google Pay，Google Classroom，Google One 也是
Universal：環球的主題公園的 App
teamLab: 東京的博物館 App
GE Appliances: 通用電氣設備的嵌入式領域
LG：去年說過的 LG 電視 webOS 使用了 Flutter ，今天計劃推出全新的 webOS-Flutter SDK
**Canonical **：Ubuntu 的維護和支持企業，將 Flutter 用于 Ubuntu 的第一方應用市場，并且 Flutter 現在在 PC 端的需求，例如的多窗口等需求，都是由其提供支持

另外， Flutter 技術服務公司 VGV，在和 ? Trackhouse Racing 建立戰略合作并提供技術支持的同時，還贊助了 NASCAR 比賽的 99 號雪佛蘭賽車，把 Flutter Logo 也打到了車頭上，從這點看，也有以 Flutter 為技術服務過的還不錯的公司：

而根據 Apptopia 的統計數據，2024 年 AppStore 里 Flutter 占據所有新免費 iOS 應用的近 30% ，雖然這個數據已經不是很亮眼了，但是在如今這個市場環境下還算可以：

而對于 Dart ，根據 JetBrains 的統計，過去五年的受眾增長上， Dart 在跟上了前十的位置，而 Dart 基本都來自 Flutter 開發，所以這也可以看出這些年 Flutter 的一個增長趨勢：

事實上，Dart 一直都一門保守的語言，它的新特性增加都十分克制，如果真要說開發體驗，肯定是不如 Kotlin ，但是它的好處在于，可以完完全全貼合 Flutter 的需要去調整，完全屬于 Flutter 的形狀，而自從 2021 全面支持空安全之后，這些年來也陸陸續續增加了不少新特性，比如這次 I/O 發布的 Dart 3.8 ，就新增了可識別空值的元素（Null-aware elements ）支持：

這個語法糖可以用于在 List、Set、Map 等集合中處理可能為 null 的元素或鍵值對，簡化顯式檢查 null 的場景：

最后，Dart 3.8 也開始嘗試交叉編譯支持，目前暫時新增了從 Windows、macOS 開發機器編譯為原生 Linux 二進制文件的支持，這個支持也可以更多用于對嵌入式平臺的支持，雖然暫時還不應用官方，但是交叉編譯對于 Dart 來說確實是一個不錯的補充：

3.32 和未來

本次 I/O 發布的 Flutter 3.32 其實并不算是一個很大的版本更新，但是它帶來了幾個關鍵的東西。

Property Editor

第一個就是 Property Editor，它需要 Flutter 3.32+ 才支持使用，屬于 IDE 增強工具，可以直接在可視化界面查看和修改 Widget 屬性：

簡單來說，就是開發者可以快速發現和修改 Widget 的現有和可用的參數，不需要跳轉到定義或手動編輯源代碼，而在 Property Editor 中選擇一個 Widget 時，它對應的文檔會顯示在頂部，可以直接閱讀 Widget 文檔無需跳轉：

比如可以看到，你修改的參數，可以會同步到代碼和運行中的程序里：

當然，這個功能單獨來看并不是十分實用，可支持的屬性也比較少，但是如果能夠搭配后續的 master 的控件實時預覽，那么整體實用性就可以提高不少，目前 Widget 預覽功能已經在 master 可以體驗：

而 Flutter Widget Preview 之所以正式開始推進落地，核心主要于 Flutter Web ：

html render 移除后，Flutter 在 Web 端統一了 canvas 渲染實現
Flutter 3.31 beta 開始支持 Web hot reload

所以，可以簡單理解，控件預覽就是在項目的 .dart_tool 目錄下生成一個預覽工程，并通過 Flutter Web 的方式進行渲染，所以整體可交互程度也會比較高。

合并線程

在 3.32 開始， Windows 和 macOS 也開始支持合并 Dart UI 線程和平臺線程，這個合并其實從 3.29 就開始了，而它的最終目標肯定就是在全平臺上都讓 Dart UI 線程和平臺線程合并統一。

而之所以會有這樣的改動，是因為之前 Flutter 里的運行機制：isolate、 Thread、Runner ，簡單說就是：

Dart 代碼都是運行在某個 isolate 里面，比如我們入口的 main 就是運行在 root isolate 里，也是我們 Dart 代碼的「主線程」
isolate 和線程之間的關系并非 1:1 ，只是執行的時候需要一個線程來完成
Runner 其實是 Flutter 上的抽象概念，它和 isolate 其實并沒有直接關系，實際上 Engine 并不在乎 Runner 具體跑在哪個線，對于 Flutter Engine 而言，它可以往 Runner 里面提交 Task ，所以 Runner 也被叫做 TaskRunner，例如 Flutter 里就有四個 Task Runner（UI、GPU、IO、Platform）

而在 Android 和 iOS 上，以前會為 UI，GPU，IO 分別創建一個線程，其中 UI Task Runner 就是 Dart root isolate，也就是 Dart 主線程， Platform Runner 其實就是設備平臺自己的主線程。

所以，在過去 Flutter 的 UI Runner 和平臺的 Platform Runner 是處于不同線程，其中 Dart 的 root isolate 會在被關聯到 UITaskRunner 上。

而現在兩個線程被合并了，說人話就是： UI Runner = Platform Runner ，首先這個調整比較大，但是不那么麻煩，因為前面我們說過，Runner 其實并不關心你跑在哪個線程，所以實際上切換的時候，就是讓 Runner 關聯到對應的 MessageHandler 線程即可。

用于處理 isolate message 的 event loop 的默認實現，實際就是沒有一個專用的事件循環線程，而是在有新消息到達時將 dart::MessageHandlerTask 發布到線程池。

為什么要這么做？其實原因就是，在此之前，Dart 和平臺之間跑在不同線程，Dart 調用平臺 API 都需要通過 MethodChannel 的異步交互，不管是在性能和交互便捷性上都不盡人意。

而現在跨平臺開發里，這類型調用都開始支持同步調用了，比如 RN 就支持同步平臺互操作的能力，而對于 Flutter 來說，通過 ffigen 和 jnigen ，也可以實現 dart 和 oc 和 java 的同步調用，但是這里面有個基礎前提，那就是 dart 和平臺需要在同一線程，所以線程同步就這么提上了日程。

當然，合并我那線程后，也帶來了一些問題，比如：

在 Android 斷點開發時，斷點 Dart 代碼現在會導致 ANR 彈框，因為以前斷點 dart 并不會阻塞 UI 線程，所以并不會觸發 ANR ，但是現在同個線程后，這個 ANR 頻率有些感人
一些原生 Plugin ，以前寫的邏輯占用了部分主線程，但是因為和 Dart 線程是分開的，所以造成的卡頓不明顯，但是合并線程后，導致的卡頓掉幀就十分明顯
因為線程合并之后，啟動引擎、應用和設置 Dart 代碼都運行的平臺線程上，會導致第一個可交互幀的時間變長，而針對這個，Flutter 也增加了 Engine 會在單獨的 Dart UI 線程上啟動引擎，然后在引擎初始化后會將 UI 任務移至平臺線程合并，從而改善應用啟動延遲的問題

最后，合并線程可以讓 App 使用 Dart FFI 與原生 API 進行直接互作了，例如在 Windows 上啟用了合并線程，開發者就可以使用 Dart FFI 通過 win32 API 直接調整應用窗口的大小 ，而不需要走繁瑣的 Channel。

所以，線程合并的主要目的，是為了拋棄歷史產物 MethodChannel，而在互操作這件事情，未來肯定是 Dart 和平臺語言直接互調用，而 3.32 也提到了，ffigen/jnigen 也在持續改進并內測，預計下半年會有全新的消息。

多窗口

多窗口相信也是許多 Flutter 開發者關心的，而目前官方的多窗口功能已經可以在對應的 PR 上去編譯體現，以下是我在 windows 和 macOS 上的試用體驗：

其實這里有個有趣的地方是，目前多窗口是由 Ubuntu 團隊在推進支持，但是最先支持的是 windows ，然后 macOS ，目前 Linux 進度是最落后的，這也是這里面比較有趣的地方。

目前體驗下來，Windows 上的性能還過得去，而在 macOS 上暫時的性能會差一些，因為 Flutter 一直以來都是單窗口設置，而在多窗口下，需要實現的單一 Engine 在渲染多個視圖時，光柵線程、UI 線程和 GPU 訪問權限等資源必須被共享或復用，這導致了在處理多個渲染目標時內部存在「競爭」或「低效調度」等問題，比如：

一個視圖的光柵化阻塞了另一個視圖等情況，所以需要改進 UI 和光柵線程之間的并行化支持。

目前基于線程合并的推進，多窗口也開始支持 ffi 版本的實現，基于 ffi 版本整體的性能體驗也會更好一些。

iOS 26

iOS 26 的液態風格也是近期 Flutter 上的熱門話題，比如 RN 用的是原生控件，所以它可以很方便就用到液態玻璃的特性，而 Flutter 是自渲染，所以存在特性兼容成本。

目前其實已經有不少開發者通過著色器在 Flutter 上復現了相應的 UI 和 UX 效果，目前體驗下來，有不少實現的還原度和體驗還是相當不錯的：

當然，這里想說的是，對于 iOS 26 的液態玻璃實現，官方已經明確了不會內置支持，甚至連 Android 的最新 Material 3 Expressive 也是，因為恰好在 Android 和 iOS 的設計風格大變的節點， Flutter 官方打算推動一個醞釀許久的計劃：移除 Cupertino 和 Material 的內置：

事實上這也是社區一直以來大家的話題，就像近期的 Flutter 更新里，總是包含了許多 Cupertino 風格的內置更新，包括本次 I/O 的 3.32 也是，但是作為平臺風格控件，社區更多認為，它在設計上不應該內置在 Framework 。

Flutter 是一個跨平臺的自渲染控件，它的核心競爭力主要是多平臺統一的渲染能力，這也是它和 RN 之間的最大區別，RN 大多數情況下是保留了平臺的特性效果，這明顯是兩個不同的需求，而官方應該更多集中精力在渲染性能和穩定性支持上。

當然不是說就完全放棄平臺特色控件的支持，而是它更多應該是一個外部依賴包推進，而不是在 Framework 里內置去跟進，抽離出來獨立的特色 Package 也能更好推進特性開發，現在 Framework 里，一個簡單的 UI 性質調整，光跑 test 可能都要 30 分鐘，而且 merge 要應對的 ci 、reivew和沖突也十分繁瑣，導致這類特性推進成本偏高。

所以抽離出特色控件，也是為了后續可以更快捷跟進實現，iOS 26 的出現，無疑推動了 Flutter 對抽離特色控件這件事的落地。