【文章內容使用 Gemini 1.5 Pro 自動產生】

關於網頁、社群和程式碼範例 - Q3 2021 調查結果

Flutter UX 團隊的季度調查報告回來了！這是我們第 14 次季度調查，在 8 月份持續了一週，透過各種管道宣佈，例如 IDE 彈出視窗、推特公告以及在 flutter.dev 上。我們收到了超過 8,000 位您的回應，一如往常，我們從中學到了很多關於您需求的資訊。

如果您想了解團隊如何分析資料，請查看此影片。

在本季度，我們發現 92% 的受訪者對 Flutter 感到滿意（39% 有些滿意 + 53% 非常滿意）。這個數字在過去 4 個季度一直很穩定，而 Flutter 開發人員的數量也在持續增長。我們仍然想聽聽您對 Flutter 各個部分的想法，因此在本季度的調查中，我們詢問了以下三個主題：

• 開發人員社群
• 網頁支援
• 原始碼檔案中的程式碼範例。

請继续阅读，了解我們從調查中學到了什麼以及我們打算做些什麼。

開發人員社群

Flutter 很自豪能成為一個開源專案。Google 的 Flutter 團隊在社群計畫上投入了大量資源，以建立一個友善且包容的開發人員社群，並讓 Flutter 開發人員獲得成功。由於了解我們需要在哪些地方投入更多資源以及做得更好非常重要，因此我們詢問受訪者他們對 Flutter 開發人員社群的各種陳述的認同程度。當我們說「開發人員社群」時，我們指的是社交網路群組、問答論壇、聊天室、聚會等等。

49% 的所有開發人員表示，他們參與了某種形式的線上或線下社群。我們發現大多數開發人員在社群中感到受到歡迎（86%）並敢於提出問題（86%）。

我們要感謝您，我們的開發人員社群，為建立一個安全和支持的空間。Flutter 旨在帶來 樂趣，而擁有一定的心理安全感，能夠嘗試新事物、犯錯，以及對自己能夠建造的東西感到驚奇，是獲得樂趣的重要組成部分。我們確定了 Flutter 團隊可以努力發揮影響力的幾個領域，例如讓更多問題得到解答，以及為社群中的領導者提供更好的曝光率。我們將與社群密切合作，共同改善兩者。

網頁支援

Flutter 團隊在今年早些時候宣佈 網頁支援已穩定。現在，在 6 個月後，大約 13% 的 flutter run 指令以及 11% 的 flutter build 指令都針對網頁。因此，我們想知道穩定版本發佈後，您對網頁支援的看法如何變化。我們在 2020 年第 3 季度也詢問了類似的調查問題，因此我們能夠比較一些數據點。

首先，我們發現 38% 的開發人員在調查前一個月中使用 Flutter Web 應用程式進行開發。此外，在所有開發人員中，有 52% 的開發人員在過去 6 個月（自穩定版本發佈以來）使用過 Flutter Web 應用程式。本節中的問題僅針對這組開發人員。

總體而言，有 63% 的開發人員對 Flutter 開發生產級別 Web 應用程式的能力感到滿意（23% 非常滿意）。當我們專門詢問 Flutter 應用程式在網頁上的效能時，67% 的開發人員感到滿意（23% 非常滿意）。雖然這個數字低於整體滿意度，但我們很高興地看到對網頁效能的滿意度從 2020 年第 3 季度的 59% 上升到 67%。

為了了解我們有哪些機會，我們詢問開發人員遇到了哪些效能問題。不出所料，初始頁面載入速度是最常見的效能問題（48%），其次是捲軸（32%）。在頁面載入方面，我們正在研究縮減 Canvas Kit 下載大小並提供啟動畫面的 API。在捲軸方面，我們正在解決許多行為問題以及由於圖片解碼造成的卡頓。您可以在 公開路線圖 中找到更多詳細資訊。

我們還詢問了哪些功能需要改進。SEO 被最多開發人員選中（36%），其次是下載（套件）大小（27%）。雖然我們了解索引在網頁上的重要性，但我們最初發佈的網頁支援專注於 Web 應用程式的利基市場，這些應用程式更重視內容創作，因此不需要索引。Rive 使用的 rive.app 就是一個很好的例子。他們有一個用 HTML 編寫的登陸頁面，該頁面對 SEO 友好，而當使用者啟動用 Flutter Web 編寫的主要應用程式時，SEO 就變得不再必要。我們目前的計畫是首先提高 Flutter 在網頁上的品質，使其在 Web 應用程式中表現出色，然後再解決其他用例，例如更重視內容消費的應用程式或頁面。

原始碼檔案中的程式碼範例

由於 Flutter 是一個開源專案，因此您可以在 IDE 中跳轉到 API 的定義並閱讀其程式碼範例，這些範例嵌入在原始碼中。但是，框架團隊正在考慮將程式碼範例從原始碼移到單獨的檔案中，以便啟用語法高亮顯示並將符號轉換為可點擊的連結。（有關更多資訊，請查看 中型程式碼範例 和 測試程式碼範例 的設計文件。）由於這可能會影響您使用文件的方式，因此我們在本次調查中加入了一個部分，以了解有多少人可能會受到提議的設計的影響。

令我們驚訝的是，許多人經常使用原始碼檔案。事實上，有 70% 的開發人員每週至少閱讀一次原始碼檔案，如果不是每天的話。

我們想了解有多少人實際上閱讀並使用了 /// 註釋中的程式碼範例。結果表明，50% 的受訪者閱讀了程式碼範例，大約 21% 的受訪者複製了程式碼範例，即使現在這樣做不太容易。

然後我們詢問了與 /// 註釋中的程式碼範例互動時的相關問題。我們發現最大的問題是缺乏語法高亮顯示（27%）。此外，大量的程式碼範例塊使得閱讀其餘的文件變得困難（25%）。

這個結果支持將程式碼範例單獨儲存的益處，這將縮短實際 API 文件的長度，並啟用對語法高亮顯示和將符號轉換為可點擊的連結的支援。但是，由於許多人今天閱讀和複製文件中的程式碼範例，我們可能會考慮使用語法高亮顯示以內聯方式顯示程式碼；因此，在視覺上將程式碼範例與其餘文件隔開。

如果您有興趣關注這個主題，請關注與導航支援相關的以下問題： Dart，IntelliJ Plugin，VSCode Plugin。

下次調查見！

我們看到越來越多的開發人員將 Flutter 作為其主要工作的一部分。這對我們來說是個好消息，我們致力於根據您的回饋，為您提供最佳的跨平台技術。

請繼續將您的回饋意見發送給我們。但季度調查不是您唯一可以使用的管道。如果您有需要跟進的緊急問題，請在 GitHub 上提交。

Flutter UXR 團隊將繼續每季度進行調查。我們會在 flutter.dev、Flutter IDE Plugin 和 Twitter @FlutterDev 上宣佈調查。請繼續貢獻您的想法，因為團隊正在尋找重要問題的答案。您也可以透過 註冊即將進行的 UX 研究 來參與其他研究。

再次感謝所有參與本次調查並提供寶貴回饋的人。我們的目標是建立一個您喜歡的產品，我們感謝您抽出時間和精力幫助我們。

關於網頁、社群和程式碼範例 - Q3 2021 調查結果 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

Dart 診斷訊息

您是否曾經看到一條錯誤訊息，卻不知道它的含義以及您應該如何處理？實際上，可能比您想像的更多資訊可以幫助您回答這些問題。

讓我們舉一個相當常見的例子。以下程式碼中存在一個問題：

在 IntelliJ IDEA 中，該訊息顯示在 Dart Analysis 視圖中：

在 Visual Studio Code 中，問題訊息顯示在「問題」面板中：

看起來很奇怪，因為我們剛剛在上一行檢查了 values 不是 null。

該訊息告訴我們出了什麼問題，但並沒有真正幫助我們理解為什麼檢查不充分或如何回應錯誤。這些額外資訊實際上是可用的；只是可能不清楚如何找到它。本文的其餘部分將向您展示如何在 IntelliJ IDEA、Visual Studio Code 和 dart analyze 命令列工具的輸出中找到這些額外資訊的位置。

IntelliJ IDEA

如果您將滑鼠懸停在突出顯示的文字上，您可以獲得更多資訊：

懸停包含我們上面看到的訊息（我們稱之為 問題訊息），但也包含其他有用的資訊：

• 指向有關診斷的外部文件的連結
• 一條 上下文訊息，解釋為什麼 null 比較不足以將屬性的類型提升為非空類型
• 一條 修正訊息，描述您可以採取的一些措施來修正程式碼

上下文訊息包含與類型提升相關的額外文件的 URL，並告訴您欄位定義的行和檔案。遺憾的是，您無法從懸停導航到上下文位置，但您可以從 Dart Analysis 視圖導航。

雖然 Dart Analysis 視圖僅顯示問題訊息，但雙擊該訊息會將您導航到報告問題的帶有紅色波浪線的文字。對於其他有用的功能，請顯示上下文選單：

使用上下文選單，您可以導航到報告診斷的位置（使用 跳轉到來源，其工作方式與雙擊問題訊息相同）或導航到 values 的宣告（使用上下文訊息標記的選單項）。選擇 打開文件 將打開有關診斷的外部文件。

Visual Studio Code

在 Visual Studio Code 中，有兩種方法可以查看額外資訊。第一種是展開「問題」面板中的條目：

第一行是我們之前看到的訊息（我們稱之為 問題訊息）。雙擊第一行或第二行會將您導航到出現問題的帶有紅色波浪線的文字。

第二行是一條 修正訊息，描述您可以採取的一些措施來修正程式碼。它還包含一個由診斷 ID 標記的連結，該連結會打開有關診斷的外部文件。

第三行是一條 上下文訊息，解釋為什麼 null 比較不足以將類型提升為非空類型。雙擊上下文訊息會將您導航到 values 的宣告。上下文訊息包含與類型提升相關的額外文件的 URL。

您也可以透過將滑鼠懸停在突出顯示的文字上來查看此資訊，這會導致打開懸停文字：

懸停文字包含與「問題」面板相同的資訊。它包含一個連結，可將您帶到外部文件，以及另一個連結，可導航到 values 的宣告。

dart analyze

命令列分析器 dart analyze 可以顯示與 IDE 相同的資訊，但您需要使用 --verbose 旗標才能查看所有資訊。

總結

我希望本文能幫助您更輕鬆地找到理解分析器診斷所需的資訊。

如果您發現仍然難以理解的診斷訊息（因為訊息不清楚、需要上下文訊息來幫助您找到其他相關程式碼位置，或者文件不夠完整），請透過建立 dart-lang/sdk 議題告知我們。我們一直有興趣改進工具。

Dart 診斷訊息 最初發佈在 Dart 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

Google Summer of Code 2021 成果

Google Summer of Code (GSoC) 是一個全球性的計劃，旨在讓學生開發人員參與開放原始碼軟體開發。Google 贊助學生在夏季與一個指導性的開放原始碼組織合作進行一個為期 10 週的編程專案。在過去的 16 年中，已有超過 16,000 名學生參與了 Google Summer of Code。

2021 年是 Dart 組織第二次作為指導性組織參與 Google Summer of Code。繼我們在 3 月份 徵集學生提案 之後，我們收到了來自世界各地學生的 92 份專案提案，其中我們非常興奮地接受了 3 個專案。今天，我們很高興與大家分享我們的成果，由參與這些專案的學生進行描述。

Dart 的基於 Cronet 的 HTTP Client

作者：Soumyadip Mondal

cronet 套件是一個用於 Dart 原生平台的 HTTP 套件，由 Chromium 的網路引擎 支援。

當 Dart 已經在 dart:io 中支援 HTTP 時，您可能會問「為什麼要加入一個 HTTP 套件？」。其中一個原因是 package:cronet 可以使用 QUIC/HTTP3 協議，這是社群 強烈要求 的功能。除此之外，在許多情況下，package:cronet 比 dart:io 更快。

Cronet 的 Dart 繫結讓我們可以輕鬆存取其 功能，例如：socket 的可重用性、強大的快取和壓縮演算法、請求優先順序，以及 更可靠的 網路連線。各種 Google 產品——包括 YouTube、Chrome、Google 地圖、Google 相簿和 Google 應用程式——都已經依賴 Cronet 函式庫來滿足其網路需求。使用 package:cronet，您可以使用與 dart:io 類似 的 API 存取 Cronet 函式庫，只需對現有的 Dart/Flutter 應用程式進行很少或不進行程式碼更改。

查看 github.com/google/cronet.dart 以獲得 基準測試、範例 以及與 dart:io 的 比較。另請查看關於 package:cronet 的這篇部落格文章，以獲得技術概述和我們面臨的挑戰的討論。

Flutter 桌面工具

作者：Abdullah Deshmukh

在 Flutter 2 中桌面支援的 Beta 版發佈後，我們需要一個範例應用程式來示範如何編寫可以在 Windows、macOS 和 Linux 上運行的 Flutter 應用程式。我參與了該範例的開發，其形式是一個 Flutter linting 工具，可幫助您管理 Flutter 專案的 lint 規則。應用程式的原始碼顯示了您如何實現基本的桌面應用程式技術，例如讀寫檔案、實現響應式佈局、使用持久性儲存，甚至如何處理 YAML 檔案。此外，該範例還可以用於測試 Flutter 應用程式到各種桌面應用程式商店的分發。

如需更多詳細資訊，請造訪 GSoC ‘21：為 Flutter 建立桌面範例。

pub.dev 的許可證檢測

作者：Bharat Biradar

在 pub.dev 上發佈的套件會根據各種指標進行評估，例如是否遵循 Dart 檔案慣例、是否有 CHANGELOG 檔案等。此分析由 pana（Dart 套件分析）完成。Pana 還負責檢測發佈套件的許可證識別碼。

到目前為止，pub.dev 上顯示的許可證名稱是透過簡單的正則表達式啟發式方法確定的，它們僅支援檢測少數許可證，準確性較差。此專案的任務是為 pana 建立一個許可證檢測器，以根據 SPDX 匹配指南檢測 SPDX 許可證。

為 pana 建立的許可證檢測器使用與 v2_licenseclassifier 相同的方法，並進行了修改以更好地滿足我們的需求。

給定套件的 LICENSE 檔案，pana 使用三個步驟來檢測 SPDX 許可證識別碼：

1. 從 SPDX 語料庫中消除明顯的不匹配： 將文字拆成標記（基本上是單詞），檢查 LICENSE 檔案是否有足夠數量的標記（至少 50%）與已知許可證相比，並消除所有不滿足條件的已知許可證。此步驟允許 pana 快速排除許多許可證，允許在步驟 2 中進行更昂貴的計算。
2. 在未知許可證和剩餘的 SPDX 許可證中尋找匹配的子字串： 對於剩餘的已知許可證，在未知文字中尋找與已知許可證文字匹配的子字串。我們尋找子字串，因為未知文字可能包含多個許可證。在識別匹配的子字串時，我們忽略標記少於閾值 * known_license_中的_標記數的序列，因為此類序列沒有足夠的標記密度來構成匹配。如果對於給定的已知許可證找不到具有足夠標記密度的子字串，則我們知道它不是匹配項。
3. 確定置信度分數： 此步驟估計找到的子字串的置信度分數（介於 [0,1] 之間）。首先，使用 levenshtain 單詞差異 將子字串與檢測到的 SPDX 語料庫許可證進行比較。然後，如果如下計算的置信度高於設定的閾值，則將許可證視為匹配項：

我們希望這能讓您對許可證檢測過程有所了解。如果您想試用許可證檢測器，您可以在 pana 儲存庫 中找到它。

非常感謝所有使用 Dart 申請 Google Summer of Code 2021 的人，感謝今年完成專案的學生，以及感謝幫助我們度過一個精彩的程式碼夏季的導師。如果您有興趣了解更多關於 Google Summer of Code 中 Dart 的資訊，請查看我們 2020 年的文章。

Google Summer of Code 2021 成果 最初發佈在 Dart 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

免費學習 Flutter 的書籍，限時供應！

我們聽說很多人都想要學習 Flutter，但不知道從哪裡開始。所以我們有好消息要告訴你 - 我們將在接下來的 3 個月內免費贈送一本書，還可以參加讀書會來幫助您追蹤進度並回答問題。

《Flutter Apprentice》是為了在行動開發基礎之上建立而寫的。它將帶領您完成您的第一個完整的 Flutter 應用程式，包括設計複雜的 UI，以及更進階的概念，例如持久性、狀態管理，以及使用 Firebase 的雲端儲存。這本書甚至還涵蓋了在 iOS 和 Android 平台上發佈的內容。

《Flutter Apprentice》出自 Razeware，該團隊開發了 raywenderlich.com 的書籍、影片和教學課程。這本書的售價通常為 60 美元，但您可以在 2021 年 10 月 6 日到 2022 年 1 月 6 日之間免費存取《Flutter Apprentice》。

《Flutter Apprentice》是一本實用的書籍，有許多範例可以供您參考，以及您可以用在自己的應用程式中的程式碼。它基於最新的 Flutter 2.5 版本和 Dart 語言中的最新功能。無論您是想要深入了解 Flutter 更進階功能的經驗豐富的開發人員，還是您是應用程式開發新手並且有興趣將 Flutter 加入您的前端開發工具集中，我們相信您都能在其中找到很多有用的內容。

一起學習

我們很高興舉辦 《Flutter Apprentice 讀書會》，這是每週一次的機會，可以聆聽現場討論，並由這本書的作者和社群專家解答您的問題。我們將與 Flutteristas 和 Flutter 社群中的其他知名領袖合作，主持讀書會。每個週三下午 12 點（美國東部時間）/ 上午 9 點（太平洋時間）加入 Flutter Community YouTube 頻道 參加總結和討論。

關注我們，參加隨堂測驗、贏取您自己的 Dash 毛絨玩具的機會、與這本書的作者進行 AMA 等等。

取得存取權

若要開始，請前往 flutter.dev/apprentice-giveaway，您將在其中找到存取這本書的說明。

您也可以訂閱 Flutter 團隊的更新。我們期待在旅途中與您同行；一路順風！

使用 Flutter Apprentice 免費學習 Flutter！ 最初發佈在 Flutter 上的 Medium，人們在這裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

介紹 Flutter Meetup 網絡！

Flutter Meetup 網絡 (FMN) 是一個由對 Flutter 熱情的 Meetup 小組組成的國際網絡。FMN 計畫的使命是 透過賦予社群組織者權力，讓他們能夠透過引人入勝的活動來教育和啟發當地社群，從而培養一個蓬勃發展的全球 Flutter 開發人員社群。

Meetup（以及類似的開發人員社群）是極好的資源。隨著 Flutter 在過去幾年中越來越受歡迎，全球各地自發地出現了 100 多個 Meetup 小組，用來慶祝 Flutter 並教育其成員有關 Flutter 的知識。這些小組的志願者舉辦了 許多 棒的活動和研討會。

我們 Flutter 團隊見證並感謝這些了不起的社群。💙 Flutter Meetup 網絡 (FMN) 現在將正式推出，以支援這些小組。網絡成員將能夠存取各種資源（更多詳細資訊即將推出！），讓規劃和主辦以 Flutter 為主題的活動變得更加容易。

除了建立人脈之外，Meetup 還有許多其他優點。當您在目前的 Flutter 專案中遇到問題時，很有可能您可以在當地的 Flutter Meetup 中找到一位開發人員，他們已經解決了類似問題。或者，也許他們知道最適合您需求的套件。

我們很高興支援我們了不起且熱情的組織者，並迫不及待地想看看 Flutter Meetup 網絡在未來會做些什麼。

加入您附近的 Meetup！

介紹 Flutter Meetup 網絡！ 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

早期採用者使用 Flutter Web 應用程式開發的經驗

兩年前，Flutter 宣布為準備使用 Flutter Web 支援進行開發的公司提供 早期採用者計劃。今天，其中一家早期採用者 Supernova， 推出了其設計系統平台，該平台同時使用 Flutter 建立，並為 Flutter 輸出程式碼。

我們認為 Supernova 是 Flutter 在 Web 上實現的體驗的一個很好的例子。我和 Supernova 的 CEO Jiří Třečák 和 CTO Artem Ufimtcev 坐在一起，了解更多關於他們使用 Flutter Web 支援所構建的內容。

您如何向從未聽說過 Supernova 的人描述它？

通常情況下，設計和開發團隊是分開的，從未真正共同合作；這是因為工具是專為其中一個團隊而設計的。因此，我們決定建立一個平台，讓設計師和開發人員可以走到一起，作為一個團隊共同合作。

告訴我更多關於 Supernova 概念背後的靈感。

這個概念源於在設計過程中需要一定程度的自動化，以減輕迭代工作流程的繁瑣。我們今天推出的工具可以自動將設計師建立的設計系統轉換為開發人員可以直接使用的程式碼形式。

您能更詳細地說明使用者在此版本中可以期待的功能嗎？

在此版本中，您可以將 Figma 設計導入 Supernova，管理樣式、素材或其他元件，然後將它們輸出為程式碼。我們建立了一個文件編輯器，讓您可以根據您的設計系統建立文件，最後，還建立了一個自動化引擎，可以在設計更改時自動更新您的文件和程式碼。

我們平台中的 所有內容 都是使用 Flutter 和 Dart 建立的。其中有很多複雜的邏輯，因此我們的應用程式比大多數應用程式更依賴于 Dart，Flutter 用於視覺化層。除了 Flutter 的 CanvasKit 渲染器之外，我們還擁有自己的 Skia 引擎，用於從 Figma 中的資料模型解析和渲染元件。

為什麼您選擇 Flutter 和 Dart 作為構建內容的不可或缺的一部分？

我們選擇 Flutter 的主要原因是我們能夠按照自己的意愿改造平台。

最初，Supernova 是一個原生 macOS 應用程式，但我們看到了對基於 Web 的解決方案的濃厚興趣。Flutter 承諾使用一個程式碼庫部署到其他平台，這使得它成為一個有吸引力的選擇。我們知道我們最終希望有一個桌面應用程式，因為我們的工具非常依賴於計算，並且與典型的網站相比，它對效能的要求更高。

我們選擇 Flutter 的主要原因是我們能夠按照自己的意愿改造平台。我們知道我們將擁有許多不常見的視覺操作，而不是使用 WebGL 從頭開始構建，Flutter 為我們提供了一種存取低層渲染引擎的方法，以便我們能夠以自己的方式構建它，使用經過良好測試的框架。

儘管我們在早期遇到了一些困難，但由於 Flutter 提供的靈活性，我們認為做出了正確的決定。

因此，這並不總是順風順水。你能描述一下這些困難以及你在這過程中學到了什麼嗎？

我們在開發 Flutter Web 應用程式時遇到的第一個技術挑戰之一是路由問題。當 Router API 發佈時，我們立即重新設計了路由系統以採用它，這被證明對 Web 應用程式更有效。雖然它提供了更好的整合到瀏覽器歷史記錄中，但它對於巢狀路由來說過於複雜。因此，我們讓在頁面之間共享狀態控制器（在本例中是 MobX 儲存）成為可能，以模擬巢狀路由。這種方法使維護和實作變得更加簡單。

我們學到的最主要的一點是 Dart 和 JavaScript 之間的互操作性對於 Web 應用程式的重要性。如果您還目標是 Flutter 支援的其他平台，那麼使用 Web 特定函式庫會有一些限制，但如果您的主要關注點是 Web 應用程式，那麼它可以節省大量時間。我們了解到，使用 JavaScript 函式庫和嵌入 HTML 可以彌補缺少 Web 支援的 Plugin。例如，我們使用這種方法來建立程式碼預覽 Widget，我們將其作為 HTML 嵌入，並使用 JavaScript 函式庫來進行語法高亮顯示。我認為，在建立 Flutter Web 應用程式時，熟悉 JavaScript 非常有幫助，同時還要了解 Dart/JavaScript 互操作性和 HTML 嵌入的優點和限制。

我們還了解到，使用 Flutter 為 Web 應用程式優化效能與為 Flutter 支援的其他平台優化效能並沒有太大區别。在大多數情况下，可以使用兩種方法解决问题：

1. 將 Widget 重新建立定位到 Widget 樹的尽可能小的部分。使用 MobX 作為主要狀態管理系統意味著重新建立只會影響 UI 中必要的部分。
2. 使用带有按需子项构建器的列表。我们尽力在任何地方使用 ListView 构建器和 Sliver，以便我们只构建当前在屏幕上可见的部分。

尽管有困难，但 Flutter 是否帮助你克服了某些特定的技术挑战？

透過 Flutter 使用 CanvasKit 渲染器比使用 WebGL 從頭開始撰寫著色器要愉快得多。CanvasKit 為我們提供了更多更高級别的渲染工具，讓我們可以專注於將 Figma 的非標準矢量模型轉換為與我們的 Skia 渲染引擎一起使用的細微差別。

開發人員通常低估了字體管理的挑戰。在本例中，我們必須支援設計師可能使用的所有字體。由於 google_fonts 套件 可以自動從 Google 直接下載字體，Flutter 在這方面幫助很大。

最後，Flutter 還允許我們共享驅動 Supernova 平台和我們建立的用於在 Figma 中運行的獨立 Plugin 的程式碼庫。雖然前端完全不同，但它們共享相同的資料模型和邏輯。

我很好奇，您如何看待使用 Flutter 在 Web 上的體驗與使用更傳統的框架相比？

總體而言，有很多相似之处。Flutter 中的概念，例如它对 UI 的反应式方法、Widget、Flexbox 布局，甚至状态管理，都可以在许多现代 Web 框架中找到。

然而，Flutter 有几方面不同。與其他 Web 框架不同，Flutter 不依賴於 HTML 或 CSS 來撰寫 UI 元件。相反，您必須了解哪些 Widget 存在，以及如何將它們組合在一起以實現與使用 CSS 才能實現的相同 UI。也就是说，Flutter 附带了对 Material 的开箱即用支持，因此如果您习惯了这种外观和感觉，它可以帮助您入门。

我发现 Dart 背后的理念大相径庭。

另一个重要区别是语言。虽然本质上 Dart 与 JavaScript 相似，但我发现 Dart 背后的理念大相径庭。在使用 Dart 编写代码一段时间后，您会发现它专为安全性、可预测性而设计。诸如健全的空安全之类的语言功能在 JavaScript 和与 JavaScript 兼容的语言世界中并不常见，我们发现它们对于使复杂应用程序稳定且可维护至关重要。另一个令我们惊喜的是 Dart 的注解处理和代码生成功能。

由于您是早期采用者，您觉得 Flutter 的 Web 支持有哪些改进？

我們一直從第一個技術預覽版開始就在 Web 上使用 Flutter。在那時，Web 目標不支持使用瀏覽器歷史記錄的導航，效能很差，缺少很多 Widget 和 Plugin，工具和偵錯程式也不存在。

現在有了穩定版本，我們在所有這些領域都看到了進步，並且對我們在 Web 上使用 Flutter 的決定充滿信心。如果您將技術預覽版與 Flutter 2.5 版本進行比較，您會發現效能有了實質性改进，特別是在渲染複雜佈局方面。

也就是说，仍然有提高的空间！特别是，我们期待看到用于检查 CanvasKit 渲染 Widget 的更好的工具，因为今天的浏览器工具不支持它。

最后一个问题，如何开始使用 Supernova？

隨著今天的發佈，Supernova 現在對每個人都可用！要開始使用，請訪問 supernova.io 註冊並提供您 Figma 設計檔案的連結。然後，從那裡開始，基本而言，整個世界都向您敞開了。您可以立即開始為 Flutter（或任何其他框架）輸出程式碼，或獲取圖示的素材以開始撰寫文件。

我們很高興看到 Flutter 的早期採用者在 Web 上推出產品。請務必親自查看！如果您正在使用 Flutter 在 Web 上進行開發，請告訴我們。一如既往，您可以在 Twitter 上找到我們 FlutterDev。我們迫不及待地想看看您創作了什麼！

http://creativecommons.org/licenses/by/4.0/

【文章內容使用 Gemini 1.5 Pro 自動產生】

我們對未來版本優先考慮事項，重點關注效能、開發者體驗和 Web 整合

Flutter 的 Web 支援在 2021 年 3 月 達到了穩定里程碑。那麼接下來呢？

根據我們的使用者研究，Web 是超過 10% Flutter 專案的目標。因此，我們現在的重點是提高初始穩定版本的品質，並讓更多人能夠將他們的 Flutter Web 應用程式部署到生產環境。

我們根據 Flutter 季度調查的結果以及我們在問題、面對面討論和社交媒體上聽到的意見來確立這些優先事項。我們剛剛收到了第三季度調查的結果，我們很高興看到這個計畫符合您的回饋。

本文將更詳細地介紹我們的路線圖以及為每個優先事項規劃的工作。某些功能可能跨越幾個季度，而其他功能則需要 [調查 (🔍)] 才能確定解決方案。

WEB 外觀和感覺

Flutter Web 應用程式在 Web 上感覺自然至關重要。這包括諸如捲軸行為、文字功能、啟動畫面、超連結、SEO 和其他 Web 特定的 UI 功能等功能。

RTL 文字

先前，Flutter 為阿拉伯語和希伯來語等從右到左 (RTL) 語言提供了不完整的 Web 支援。雖然框架本身支援 RTL 文字，但 Web 引擎生成了未定義的行為，因為它忽略了 LTR 和 RTL 之間的區別。

最近的穩定版本 (2.5) 加入基本的 RTL 支援，因此所有主要 RTL 語言的使用案例都可以在 Flutter Web 應用程式中支援和使用。大部分與基本支援相關的問題都已解決，我們計畫修復剩餘的問題。

• 為文字編輯實作 RTL 支援（已修復）
• Web 上的 RTL 文字渲染故障（已修復）
• 具有 TextDirection.rtl 的 TextField，在 Web 上游標位置錯誤（已規劃）
• RichText 中的 InlineSpans 在 RTL 應用程式中重疊（已修復）

捲軸行為

雖然 Flutter 2 包含 多項改進 以支援桌面瀏覽器上的捲軸行為（例如捲軸列支援），但在瀏覽器或執行 Web 應用程式的作業系統上，捲軸行為有時看起來或感覺不對。

雖然其中一些行為取決於 Flutter 桌面支援的工作，但我們計畫在此路線圖中解決一些特定於捲軸物理和捲軸列的問題（如下所列）。我們也計畫調查觸控板支援。

• PageScrollPhysics 有奇怪的行為
• (無限) 列表 Widget 中沒有捲軸列
• Mac 桌面捲軸物理應維持範圍
• 讓捲軸列避免遮擋 Sliver 和媒體查詢填充
• MaterialScrollBehavior.buildScrollbar 需要更新

🔍 研究觸控板支援

應用程式載入 API

某些 Web 應用程式在應用程式載入時或提供自訂體驗時，更喜歡顯示啟動畫面、載入指示器或登陸頁面。目前，沒有簡單的方法可以實作自訂體驗或指示 Flutter Web 應用程式正在載入；當使用 CanvasKit 的較大 bundle 大小渲染時，這變得更加重要。

我們在此的工作重點是為您提供應用程式啟動週期的明確 API，該 API 可用於預載應用程式、控制應用程式的載入週期，以及建立啟動畫面或載入指示器。

• 為 Web 加入啟動畫面支援

無障礙性

無障礙性是我們的首要任務之一；我們的目標是為您提供必要的工具來建立無障礙的 Web 應用程式，這些應用程式可以在最常見的螢幕閱讀器上良好運行。

Flutter 2.2 對無障礙性支援進行了重大改進。從那以後，我們聽到了一些嘗試使用螢幕閱讀器（例如 JAWS）瀏覽 Web 應用程式的最終使用者的意見。

在此路線圖中，我們專注於使用 支援的螢幕閱讀器（例如桌面瀏覽器的快顯通知）時出現的問題。我們還將繼續調查改進整體無障礙性支援的方法。

• 使用 Enter 鍵時，無法宣布按鈕按下
• 方向鍵和 B 鍵不會更新螢幕閱讀器焦點

效能

效能是我們始終優先考慮的領域，以改善使用 Flutter Web 應用程式的使用者體驗。目前，我們的重點是改善捲軸卡頓，並加快 Web 應用程式的初始載入速度。

捲軸卡頓

根據我們最近的季度調查，捲軸卡頓是所報告的頂級效能問題之一。我們的目標是確保 Flutter Web 應用程式可以透過行動設備上的手勢或桌面上的滑鼠/鍵盤順暢捲軸，但這也取決於 Web 應用程式期望使用者捲軸瀏覽的內容類型和數量。

在接下來的幾個月裡，我們將主要專注於改善由於圖片解碼引起的卡頓，我們將繼續調查捲軸效能問題，以找出可以改善的其他使用案例。

• 將圖片解碼移動到 Web 工作執行緒
• 在 CanvasKit 渲染器中降低平台視圖的成本

捆綁 CanvasKit（離線支援）

目前，在 CanvasKit 中渲染的 Flutter Web 應用程式需要額外的步驟才能作為漸進式 Web 應用程式 (PWA) 在離線狀態下運行。為了讓應用程式在離線模式下能直接作為 PWA 完整運行，並確保應用程式符合嚴格的內容安全政策，我們需要捆綁 CanvasKit 和字體備份。

我們將首先捆綁 CanvasKit，然後捆綁字體，最後加入必要的工具以啟用離線模式。

• CanvasKit 後端不應依賴於易變的 Google 字體
• 支援捆綁 CanvasKit 而不是 CDN

CanvasKit 下載大小

CanvasKit 比基於 DOM 的方法具有更好的效能，因此它是在桌面瀏覽器上的預設渲染器。但是，下載應用程式所需的時間會影響初始載入效能（以及在 Web 上運行的 Flutter 應用程式的 Lighthouse 分數）。

在此路線圖中，我們將調查減少 CanvasKit 下載大小的方法，以改善初始載入效能。我們希望確保最終使用者的設備或瀏覽器不會處理過大的負載。

🔍 改進 CanvasKit 下載大小

🔍 尋找合理大小的 emoji 字體備份

與 HTML 內容整合

能夠與瀏覽器程式碼整合對於利用 Web 平台的優勢至關重要。Flutter Web 應用程式有兩種方式可以與 HTML 整合：1) 在 Flutter Web 應用程式中使用 HTML 平台視圖，或 2) 將 Flutter 作為內容島嵌入到現有的 Web 應用程式中（有點像 Web 的加到應用程式）。雖然前者現在存在，可能需要改進，但後者將是一個需要進一步設計和開發的新功能。

使用自訂元素嵌入（加到應用程式）

目前，將 Flutter Web 應用程式嵌入到現有的網站/Web 應用程式中的唯一方式是透過 iframe。雖然這對某些使用案例有效，但對於那些逐漸遷移 Web 應用程式以使用 Flutter 來說並不總是理想的解決方案。

在此路線圖中，我們將調查和設計自訂解決方案，讓您能夠嵌入 Flutter Web 應用程式，類似於加到應用程式的行動情境。

🔍 將應用程式渲染到自訂元素中

開發者體驗

Flutter 生態系統包括您在開發中使用的功能，但目前缺乏 Web 支援，例如外掛、除錯、熱重載等等。為了讓您在 Web 上擁有良好的開發者體驗，我們將繼續縮減行動和 Web 之間的差異。

相機外掛

自初始穩定版本發佈以來，相機外掛一直是最常被要求的外掛之一；許多人發現，當將 Flutter 行動應用程式移植到 Web 時，這種差異是一個障礙。

在 Flutter 2.5 穩定版本中，我們提供了一個 外掛 的早期版本，該外掛可以初始化相機、顯示相機預覽並拍照。隨著我們收到回饋，我們將改進此外掛。

• 為 Web 加入相機支援（已透過部分待審查的 PR 修復）

感謝您！

雖然這是我們目前 Web 路線圖的概述，但我們的 GitHub 問題列表 仍然是我們正在進行的工作的真實來源。我們可能會根據我們的學習成果和您的意見來加入、延長或延遲功能。

與往常一樣，我們非常重視您的回饋，並感謝您的支援！

Flutter：Web 上的下一步是什麼？ 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

宣佈 Dart 2.14

今天，我們發佈了 Dart SDK 的 2.14 版本，這是我們持續努力的最新成果，旨在透過獨特的可移植性、生產力和穩健性組合，打造構建應用程式的最佳平台。這次，我們對 Apple Silicon 提供了更好的支援，並進行了許多生產力增強，例如用於在您編寫程式碼時透過程式碼樣式分析來捕捉錯誤的標準 lints、更快的 pub 工具、使用 cascades 更好地格式化程式碼，以及一些小型語言功能。

Dart SDK 中的 Apple Silicon 支援

自從 Apple 在 2020 年底宣佈了他們新的 Apple Silicon 處理器以來，我們一直致力於更新 Dart SDK，以增加對在新處理器上原生執行的支援。所需的變更已在開發頻道中提供了一段時間，在過去一個月中在測試頻道中提供，而從 Dart 2.14.1 開始，現在已在 Dart 穩定頻道中提供。當您 下載 macOS SDK 時，請務必選擇 ARM64 選項。請注意，Flutter SDK 中捆綁的 Dart SDK 尚未包含這些改進。

該支援包括在 Apple Silicon 上運行 SDK/Dart VM 本身，以及支援編譯在 Apple Silicon 上運行的可執行檔（使用 dart compile）。Dart 命令列工具現在啟動速度更快，因為它們使用了原生 Apple Silicon 支援。

為 Dart 和 Flutter 共享的標準 lints

開發人員通常更喜歡他們的程式碼遵循某種樣式。這些規則中的許多規則不僅僅是樣式偏好（例如眾所周知的 tab 與空格的討論），還涵蓋了可能導致錯誤或引入錯誤的編碼樣式。例如，Dart 樣式指南要求對所有控制流程結構（例如 if-else 陳述式）使用大括號。這可以防止經典的 懸空 else 問題，其中對如何解釋多個巢狀 if-else 陳述式存在歧義。另一個例子是類型推斷。雖然在使用初始值宣告變數時使用類型推斷是可以的，但在 宣告未初始化的變數 時指定類型很重要，以確保類型安全。

強制執行良好程式碼樣式的一個選項是透過某種形式的人工強制執行，通常是透過程式碼審查。但是，通常透過在您編寫程式碼時運行的靜態分析來強制執行規則會更有效。

在 Dart 中，這種靜態分析是高度 可配置的，我們有 數百條樣式規則（也稱為 lints）。有了這麼多的選項，選擇要啟用哪些規則可能會有點讓人不知所措。Dart 團隊維護著一份 Dart 樣式指南，其中描述了我們認為編寫和設定 Dart 程式碼樣式的最佳方式，但從歷史上看，我們沒有一套與樣式指南相對應的官方 linter 規則集。

許多開發人員——以及 pub.dev 網站 評分 引擎——都使用了 pedantic linter 規則集。然而，pedantic 起源於 Google 內部的 Dart 樣式指南，由於歷史原因，它與一般的 Dart 樣式指南不同。此外，Flutter 架構從未使用過 pedantic 規則集，而是有自己的一套規範規則。

這聽起來可能有點混亂，確實如此。但隨著今天的發佈，我們很高興地宣佈，我們現在有一套全新的 linter 集合，它們實作了樣式指南，並且 Dart 和 Flutter SDK 已更新，預設為新專案使用這些規則集。規則集如下：

• package:lints/core.yaml: Dart 樣式指南中的主要規則，我們認為所有 Dart 程式碼都應該遵循。pub.dev 評分引擎已更新為使用這些規則而不是 pedantic。
• package:lints/recommended.yaml: 核心規則，以及其他建議的規則。建議所有通用 Dart 程式碼都使用此集。
• package:flutter_lints/flutter.yaml: 核心和建議的規則，以及其他 Flutter 特定的建議規則。建議所有 Flutter 程式碼都使用此集。

如果您有現有專案，我們強烈建議您升級到這些新的規則集。從 pedantic 升級 只需幾個步驟。

Dart 格式化工具和 cascades

我們對 Dart 格式化工具如何使用 cascades 格式化程式碼進行了多項優化。以前，格式化工具在某些情況下會產生令人困惑的格式。例如，在此範例中，doIt() 是在什麼上調用的？

1

var result = errorState ? foo : bad..doIt();

它看起來像是總是在 bad 上調用的，但實際上 cascade 適用於整個 ? 表達式，因此 cascade 是在該表達式的結果上調用的，而不僅僅是在 false 子句上。新的格式化工具使這一點更加清晰：

1
2

var result = errorState ? foo : bad
  ..doIt();

其他變更與包含多個 cascades 的行的格式化方式以及 cascades 通常縮排的程度有關。我們還大大提高了格式化包含 cascades 的程式碼的速度；在為 protocol buffers 生成的 Dart 程式碼中，我們看到格式化速度提高了 10 倍。

有關所有詳細資訊，請參閱 追蹤議題。

Pub 支援忽略檔案

目前，當您將套件 發佈 到 pub.dev 社群儲存庫時，pub 會抓取該資料夾中的所有檔案，但有一些例外，會跳過隱藏檔案（以點開頭的檔案：.）和 .gitignore 中列出的檔案。一些開發人員要求能夠控制在 .gitignore 列表之外忽略哪些檔案。例如，您可能在 tool/ 資料夾中有一些用於 維護 套件的內部開發工具，但這些工具與 使用 套件的人無關。

Dart 2.14 中更新的 pub 命令支援新的 .pubignore 檔案，您可以在其中列出不想上傳到 pub.dev 的檔案。此檔案使用與 .gitignore 檔案相同的格式。有關詳細資訊，請參閱 套件發佈文件。

Pub 和 dart test 效能

雖然 pub 可能最常用於管理程式碼相依關係，但它還有第二個重要的用途：支援工具。一個這樣的例子是 Dart 測試工具，透過 dart test 命令公開。此命令實際上只是 pub run test:test 命令的包裝器，它在 package:test 中運行測試入口點。在調用該入口點之前，pub 首先將其編譯為可以更快運行的原生程式碼。

在 Dart 2.14 之前，對 pubspec 的任何變更（包括與 package:test 無關的變更）都會使此測試的構建失效，您會看到一堆如下所示的輸出，其中包含“正在預編譯可執行檔”：

1
2
3
4

$ dart test
正在預編譯可執行檔... (11.6s)
預編譯 test:test。
00:01 +1: 所有測試都通過了！

在 Dart 2.14 中，pub 對何時使構建步驟失效更加智慧，因此只有在版本變更時才會進行構建。此外，我們改進了使用平行化執行構建步驟的方式，因此步驟本身完成得更快。我們在測試的一些套件中看到它花費的時間減少了一半。

新的語言功能

Dart 2.14 還包含許多小型語言功能。這次，我們專注於更具體的改進，這些改進的用途可能更狹窄，但可以啟用以前不支援的更專門的用例。

首先，我們加入了一個新的 三重移位 運算子（>>>）。這與現有的移位運算子（>>）類似，但 >> 執行算術移位，而 >>> 執行邏輯或無符號移位，其中零位元被移位到最高有效位元，無論被移位的數字是正數還是負數。

我們還移除了一個對類型引數的舊限制，該限制不允許使用泛型函數類型作為類型引數。以下所有內容在 2.14 之前都是無效的，但現在允許：

1
2
3

late List<T Function<T>(T)> idFunctions;
var callback = [<T>(T value) => value];
late S Function<S extends T Function<T>(T)>(S) f;

最後，我們對註釋類型進行了一些小調整。（註釋，例如 @Deprecated，通常用於 Dart 程式碼中以捕捉中繼資料。）以前，註釋不能傳遞類型引數，因此 @TypeHelper<int>(42, "The meaning") 之類的程式碼是不允許的。此限制現已移除。

套件和核心函式庫變更

我們對核心 Dart 套件和函式庫進行了許多增強，包括：

• dart:core：在 Object 類中加入了靜態方法 hash、hashAll 和 hashAllUnordered。這些方法可以用於以一致的方式組合多個物件的雜湊碼（hashAll 範例）。
• dart:core：原生的 DateTime 類現在可以更好地處理夏令時變更前後的本地時間，這些變更不精確為一小時——例如，澳大利亞的豪勳爵島，它使用 30 分鐘的偏移量。
• package:ffi：增加了使用 arena 分配器管理記憶體的支援（範例）。Arenas 是一種基於區域的記憶體管理形式，其中資源會在 arena/區域退出後自動釋放。
• package:ffigen：現在支援從 C 類型定義生成 Dart 類型定義。

重大變更

Dart 2.14 還包含一些較小的、先前已宣佈的 重大變更。預計這些變更只會影響一些專門的用例。

#46545：移除對 ECMAScript5 的支援

所有現代瀏覽器 都支援最新的 ECMAScript 版本，因此兩年前我們 宣佈 了棄用 ECMAScript 5 (ES5) 支援的計劃。這使我們能夠利用最新 ECMAScript 中的改進並生成更小的輸出。在 Dart 2.14 中，這項工作已完成，Dart Web 編譯器不再支援 ES5。因此，不再支援舊版瀏覽器——例如 IE11。

#46100：棄用 stagehand、dartfmt 和 dart2native

在 2020 年 10 月的 Dart 2.10 部落格文章 中，我們宣佈了將所有 Dart CLI 開發人員工具合併到一個單一的、組合的 dart 工具（類似於 flutter 工具）中的工作。作為該演進的一部分，Dart 2.14 棄用了以前的 dartfmt 和 dart2native 命令，並停止了 stagehand。這些工具在 統一的 dart 工具 中都有等效的替代品。

#45451：棄用 VM 原生擴展

我們棄用了 Dart VM 的原生擴展，這是我們從 Dart 程式碼調用原生程式碼的舊機制。Dart FFI（外部函數介面）是我們目前用於此用例的機制，我們正在積極地 發展 它，使其更加強大和易於使用。

Null safety 更新

我們在 3 月的 Dart 2.12 版本中推出了健全的 null safety。Null safety 是 Dart 的最新主要生產力功能，旨在幫助您避免 null 錯誤——這是一類通常難以發現的錯誤。

自從我們的上次更新以來，我們在將現有套件和應用程式遷移到啟用 null safety 的健全檢查優點方面取得了巨大進展。對於 pub.dev 上的套件，前 250 個套件中的 100% 現在支援 null safety，前 1000 個套件中的 94% 支援它。這意味著更多開發人員可以以完全 健全的 null safety 運行他們的應用程式。分析顯示，56% 的 flutter run 會話以完全健全的方式執行。感謝生態系統中的所有開發人員的遷移工作！

2.14 的可用性和持續的發展勢頭

包含上述變更的增強型 Dart SDK 現在已在 Dart 2.14.1 和 Flutter 2.5 SDK 中提供。我們希望您會喜歡新的增強功能和特性。

此外，我們也想藉此機會感謝出色的 Dart 社群。正如在最近對程式語言調查的多次更新中所見，Dart 的發展勢頭強勁。備受尊敬的 RedMonk 排名 提到了“Dart 的顯著上升”，並首次將 Dart 排在前 20 名。StackOverflow 全面的 2021 年開發人員調查 同樣令人高興：據報導，Dart 是開發人員第七喜歡的程式語言。我們真的很高興看到 Dart 平台持續增長和發展勢頭。

宣佈 Dart 2.14 最初發佈於 Medium 上的 Dart，人們在那裡透過醒目顯示和回應這個故事來繼續對話。

【文章內容使用 Gemini 1.5 Pro 自動產生】

Flutter 2.5 的新功能

您好，歡迎來到 Flutter 2.5！這是一個重大版本，在 Flutter 版本史上擁有第二高的統計數據：來自 252 位貢獻者和 216 位審查者的 4600 個已關閉議題和 3932 個已合併 PR。如果我們回顧過去一年，我們看到 1337 位貢獻者創建了 21,072 個 PR，其中 15,172 個已合併。雖然「Flutter 的新功能」部落格文章重點關注新功能，但我們在 Flutter 中的首要任務始終是確保您擁有所需功能的最高品質水準。

事實上，此版本繼續進行許多重要的效能和工具改進，以追蹤您自己應用程式中的效能問題。同時，還有一些新功能，包括 Android 全螢幕支援、更多 Material You（也稱為 v3）支援、更新的文字編輯以支援可切換的鍵盤快捷鍵、在 Widget Inspector 中更詳細地查看您的 Widget，以及在 Visual Studio Code 專案中新增相依性的新支援，以及在 IntelliJ/Android Studio 中從測試執行中獲取覆蓋率資訊的新支援，以及一個全新的應用程式範本，作為您真實世界 Flutter 應用程式的更好基礎。此版本充滿了令人興奮的最新更新，讓我們開始吧。

效能：iOS 著色器預熱、非同步任務、GC 和訊息傳遞

此版本附帶了一些效能改進。此列表中的第一項是關於從離線訓練執行中建立 Metal 著色器預編譯的 PR (#25644)，如我們的基準測試所示，它將最差情況下的影格柵格化時間縮短了 2/3，將第 99 個百分位數的影格縮短了一半。我們繼續努力減少 iOS 卡頓，這是在這條道路上的又一步。然而，著色器預熱只是一個卡頓的來源。先前，處理來自網路、檔案系統、外掛或其他隔離區的非同步事件可能會中斷動畫，這是另一個卡頓的來源。在這個版本中，針對 UI 隔離區事件迴圈的排程策略進行了改進 (#25789)，現在影格處理優先於處理其他非同步事件，在我們的測試中消除了這種來源的卡頓。

另一個卡頓的原因是，當垃圾收集器 (GC) 暫停 UI 線程以回收記憶體時。先前，一些圖片的記憶體只會在 Dart VM 執行的 GC 響應中被懶惰地回收。作為先前版本中的解決方案，Flutter 引擎將提示 Dart VM，圖片記憶體可以透過 GC 回收，這在理論上可以導致更及時的記憶體回收。不幸的是，在實際中，這導致了過多的主要 GC，有時記憶體仍然無法快速回收，以避免記憶體有限設備上的低記憶體情況。在此版本中，未使用的圖片的記憶體被渴望地回收 (#26219，#82883，#84740)，大幅減少 GC。

例如，在我們的其中一項測試中，播放 20 秒的動態 GIF 從需要 400 多個 GC 變為只需要 4 個 GC。較少的 GC 表示涉及圖片出現和消失的動畫會有更少的卡頓，並消耗更少的 CPU 和電源。

Flutter 2.5 中的另一個效能改進是 Dart 和 Objective-C/Swift (iOS) 或 Dart 和 Java/Kotlin (Android) 之間傳送訊息的延遲。作為 調整訊息通道 的一部分，從訊息編解碼器中移除不必要的複製操作會根據訊息大小和設備減少延遲，最多可達 50% (#25988，#26331) 。

您可以在 Aaron Clarke 的 改善 Flutter 中平台通道效能 部落格文章中閱讀有關此工作的更多詳細資訊。

如果您要定位 iOS，則最後一個效能更新是：在此版本中，在 Apple Silicon M1 Mac 上構建的 Flutter 應用程式可在 ARM iOS 模擬器上原生運行 (#pull/85642)。這表示在 Intel x86_64 指令與 ARM 之間沒有 Rosetta 轉換，這會提高 iOS 應用程式測試期間的效能，並讓您避免一些細微的 Rosetta 問題 (#74970，#79641)。這是 Flutter 對 Apple Silicon 的全面支援之路上的又一步。敬請期待更多資訊。

Dart 2.14：格式化、語言功能、預設提供的 pub 和 lint

當然，沒有 Flutter 語言和運行時，Flutter 就不是 Flutter。此版本 Flutter 附帶了 Dart 2.14。Dart 的新版本 附帶了新的格式化，使 級聯 更加清晰，新的 pub 支援忽略檔案，以及新的語言功能，包括傳奇的三重移位運算子的回歸。此外，Dart 2.14 最棒的功能之一是，此版本創建了一組標準的 lint，在新的 Dart 和 Flutter 專案之間共享，這些 lint 預設提供。

您不僅在創建新的 Dart 或 Flutter 專案時會獲得這些 lint，而且透過 幾個步驟，您也可以將相同的分析添加到現有的應用程式中。有關這些 lint、新的語言功能等的詳細資訊，請查看 Dart 2.14 的版本發布公告。

架構：Android 全螢幕、Material You 和文字編輯快捷鍵

Flutter 2.5 版本包含一些對框架的修復和改進。從 Android 開始，我們修復了一組與全螢幕模式相關的問題，這些問題總共獲得了將近 100 個好評。模式本身的名稱使它成為我們最喜歡的新功能之一：放鬆、粘性、粘性沉浸式和邊到邊。此更改還添加了一種方法，可以在其他模式下監聽全螢幕更改。例如，如果使用者與應用程式互動，當系統 UI 回來時，開發人員現在可以編寫程式碼以返回全螢幕或執行其他操作。

在此版本中，我們繼續為新的 Material You（也稱為 v3）規範構建支援，包括對浮動動作按鈕大小和主題的更新 (#86441)，以及一個新的 MaterialState.scrolledUnder 狀態，您可以在 PR 中的範例程式碼中看到 (#79999)。

在談到捲軸時，另一個改進是添加了捲軸指標通知 (#85221，#85499)，即使使用者沒有捲軸，它也會提供可捲軸區域的通知。例如，以下顯示了根據 ListView 的底層大小顯示或隱藏捲軸條：

在這種情况下，您不需要编写任何代码，但如果您想要捕获 ScrollMetricNotification 变化，您可以这样做。特别感谢社区贡献者 xu-baolin，他为这部分工作付出了很多努力，并想出了一个很棒的解决方案。

社区的另一个优秀贡献是在 ScaffoldMessenger 中添加了 Material 横幅支持。您可能还记得 ScaffoldMessenger 来自 Flutter 2.0 版本发布公告，它是一种更健壮的方式，可以在屏幕底部显示 SnackBars 以向用户提供通知。在 Flutter 2.5 中，您现在可以在支架的顶部添加横幅，它会一直保持直到用户将其关闭。

您的应用程序可以通过调用 ScaffoldMessenger 的 showMaterialBanner 方法来获得此行为：

横幅的 Material 指南 指出您的应用程序应该一次只显示一个，因此如果您的应用程序多次调用 showMaterialBanner，ScaffoldMessenger 将维护一个队列，并在前一个横幅关闭时显示每个新的横幅。感谢 Calamity210 为 Flutter 中的 Material 支持添加了这个很棒的功能！

在 Flutter 2.0 及其新的文字编辑功能（如文字选择枢轴点以及在处理键盘事件后能够停止其传播）的基础上，在此版本中，我们添加了使文字编辑键盘快捷键可覆盖 (#85381) 的功能。如果您希望 Ctrl-A 执行自定义操作而不是选择所有文字，您可以执行此操作。DefaultTextEditingShortcuts 类包含 Flutter 在每个平台上支持的每个键盘快捷键的列表。如果您想覆盖任何内容，请使用 Flutter 现有的 Shortcuts Widget 将任何快捷键重新映射到现有的或自定义意图。您可以在想要应用覆盖的 Widget 树中的任何位置放置该 Widget。在 API 参考 中查看一些示例。

外掛：相機、圖片選取器和 Plus 外掛

另一個已進行大量改進的外掛是 相機外掛：

• 3795 [camera] android-rework part 1: 支持 Android 相机功能的基础类
• 3796 [camera] android-rework part 2: Android 自动对焦功能
• 3797 [camera] android-rework part 3: Android 与曝光相关的功能
• 3798 [camera] android-rework part 4: Android 闪光灯和缩放功能
• 3799 [camera] android-rework part 5: Android FPS 范围、分辨率和传感器方向功能
• 4039 [camera] android-rework part 6: Android 曝光和对焦点功能
• 4052 [camera] android-rework part 7: Android 降噪功能
• 4054 [camera] android-rework part 8: 支持最终实现的模块
• 4010 [camera] 不要在 iOS 上触发平坦的设备方向
• 4158 [camera] 修复在 iOS 上设置对焦和曝光点的坐标旋转
• 4197 [camera] 修复相机预览不始终在方向改变时重建
• 3992 [camera] 阻止在设置不支持的对焦模式时崩溃
• 4151 [camera] 引入 camera_web 包

image_picker 外掛 也進行了很多工作，重點關注端到端的相機體驗：

• 3898 [image_picker] 图片选择器修复相机设备
• 3956 [image_picker] 更改 Android 上相机捕获的存储位置为内部缓存，以符合新的 Google Play 存储要求
• 4001 [image_picker] 删除对相机权限的冗余请求
• 4019 [image_picker] 修复相机作为来源时的旋转

这项工作改进了相机和 image_picker 外掛在 Android 上的功能和稳健性。此外，您会注意到 camera 外掛 的早期版本已提供，其中包含 Web 支援 (#4151)。此預覽版為在 Web 上查看相机预览、拍照、使用闪光灯和缩放控件提供了基本支持。它目前不是 认可外掛，因此您需要 显式地添加它 才能在您的 Web 應用程式中使用。

最初的 Android 相機重寫工作是由 acoutts 貢獻的。相机和 image_picker 的工作由 Baseflow 完成，Baseflow 是一家专门从事 Flutter 的咨询公司，以 他们在 pub.dev 上的自己的包 而闻名。camera_web 的工作主要由 Very Good Ventures 完成，这是一家位于美国的 Flutter 咨询公司。非常感谢大家对 Flutter 社区的贡献！

Flutter 社区组织的另一个宝贵社区贡献是 “Plus” 外掛。在这个 Flutter 版本中，Flutter 团队的每个对应外掛现在都带有类似于 battery 的推荐：

此外，由于这些外掛不再积极维护，因此不再将其标记为 Flutter 收藏外掛。如果您还没这样做，我们建议您迁移到以下外掛的 Plus 版本：

Flutter DevTools：效能、Widget Inspector 和潤色

此版本的 Flutter 附帶了一些對 Flutter DevTools 的改進。最重要的是，DevTools 中添加了支援，以利用引擎更新 (#26205，#26233，#26237，#26970，#27074，#26617)。這些更新中的一組使 Flutter 能夠更好地將追蹤事件與特定影格關聯起來，這有助於開發者確定影格超支的原因。您可以在 DevTools 影格圖表中看到這一點，該圖表已重建為「實時」的；影格會在您的應用程式中渲染時在該圖表中填充。從該圖表中選擇一個影格將導航到該影格的時間軸事件：

Flutter 引擎現在還會在時間軸中識別著色器編譯事件。Flutter DevTools 使用這些事件來幫助您診斷應用程式中的著色器編譯卡頓。

有了這個新功能，DevTools 可以檢測到您是否由於著色器編譯而丟失了影格，以便您可以修復問題。要像第一次一樣運行您的應用程式（在您的著色器快取填充之前，就像它對任何使用者一樣），請使用 flutter run 和 --purge-persistent-cache 標誌。這將清除快取，以確保您正在重現使用者在「首次運行」或「重新打開」（iOS）體驗時看到的環境。此功能仍在開發中，因此請 提交議題 報告您遇到的問題，或報告我們可以做出的任何改進，以幫助除錯著色器編譯卡頓。

此外，當您在應用程式中追蹤 CPU 效能問題時，您可能會被來自 Dart 和 Flutter 函式庫以及引擎的原生程式碼的分析資料淹沒。如果您想關閉這些資料中的任何資料以專注於您自己的程式碼，可以使用新的 CPU 分析工具 (#3236)，它讓您能夠隱藏來自這些來源的分析資訊。

對於您沒有過濾掉的任何類別，它們現在都已使用顏色編碼 (#3310，#3324)，這樣您就可以輕鬆地看到 CPU 影格圖表中的哪些部分來自系統的哪些部分。

效能不是您要除錯的唯一事項。此版本的 DevTools 附帶了對 Widget Inspector 的更新，它讓您可以在 Widget 上懸停以評估物件、查看屬性、Widget 狀態等。

而且，當您選取一個 Widget 時，它會自動填充到新的 Widget Inspector 主控台中，您可以在其中探索 Widget 的屬性。

在斷點處暫停時，您也可以從主控台中評估運算式。

除了新功能外，Widget Inspector 也經過了改頭換面。為了使 DevTools 成為一個更有用的目的地，用於了解和除錯您的 Flutter 應用程式，我們與位於芬蘭的創意科技公司 Codemate 合作，進行了一些更新。

在此螢幕截圖中，您可以看到以下更改：

• 更好地傳達除錯切換按鈕的作用 - 這些按鈕有新的圖示、以任務為導向的標籤，以及描述其作用和何時使用它們的豐富工具提示。每個工具提示都會進一步鏈接到功能的詳細文件。
• 更容易扫描和定位感兴趣的 widget - Flutter 框架中常用的 widget 现在会在 Inspector 左侧的 widget 树视图中显示图标。它们还会根据其类别进行颜色编码。例如，布局 widget 将以蓝色显示，而内容 widget 将以绿色显示。此外，每个 Text widget 现在都会显示其内容的预览。
• 将布局资源浏览器和 widget 树的颜色方案对齐 - 现在更容易从布局资源浏览器和 widget 树中识别同一个 widget。例如，以下屏幕截图中的“Column” widget 在布局资源浏览器中以蓝色背景显示，而在 widget 树视图中则以蓝色图标显示。

我們很樂意 聽取您有關這些更新產生的任何問題的意見回饋，以及我們可以做的任何其他改進，以確保 DevTools 運作良好。這些重點只是開始。若要完整列出此版本 Flutter 中 DevTools 的新增功能，請查看版本發布公告：

• Flutter DevTools 2.3.2 版本發布公告
• Flutter DevTools 2.4.0 版本發布公告
• Flutter DevTools 2.6.0 版本發布公告

IntelliJ/Android Studio：整合測試、測試覆蓋率和圖示預覽

Flutter 的 IntelliJ/Android Studio 外掛在此版本中也進行了一些改進，首先是能夠運行整合測試 (#5459)。整合測試是整個應用程式測試，在設備上運行，位於 integration_test 目錄中，並使用與 Widget 單元測試中相同的 testWidgets() 功能。

若要將整合測試添加到您的專案，請 按照 flutter.dev 上的說明操作。若要將測試與 IntelliJ 或 Android Studio 連接，請添加一個運行配置，該配置啟動整合測試，並連接一個設備供測試使用。運行配置允許您運行測試，包括設置斷點、單步執行等。

此外，Flutter 的最新 IJ/AS 外掛讓您能夠查看單元測試和整合測試運行的覆蓋率資訊。您可以從工具列按鈕中存取它，該按鈕位於「除錯」按鈕旁邊：

覆蓋率資訊使用編輯器邊緣的紅色和綠色條顯示。在此示例中，第 9-13 行已測試，但第 3 和 4 行未測試。

最新版本還包括能夠預覽從 pub.dev 建立的基於 TrueType 字體檔案的包中使用的圖示 (#5504，#5595，#5677，#5704)，就像 Material 和 Cupertino 圖示支持預覽一樣。

若要啟用圖示預覽，您需要告訴外掛您正在使用哪些包。外掛設定/偏好設定頁面中有一個新的文字欄位：

請注意，這適用於在類別中定義為靜態常數的圖示，如螢幕截圖中的範例程式碼所示。它不適用於運算式，例如 LineIcons.addressBook() 或 LineIcons.values['code']。如果您是未支援此功能的圖示包的作者，請創建一個 議題。

有關 Flutter 的 IntelliJ/Android Studio 外掛的更多更新資訊，請查看版本發布公告：

• Flutter IntelliJ Plugin M57 版本發布
• Flutter IntelliJ Plugin M58 版本發布
• Flutter IntelliJ Plugin M59 版本發布
• Flutter IntelliJ Plugin M60 版本發布

Visual Studio Code：相依性、修復全部和測試執行器

Flutter 的 Visual Studio Code 外掛也在此版本中得到了改進，首先是兩個新的命令「Dart: Add Dependency」和「Dart: Add Dev Dependency」 (#3306，#3474)。

這些命令提供了類似於 Jeroen Meijer 的 Pubspec Assist 外掛 一段時間以來提供的功能。這些新的命令預設提供，並提供一個從 pub.dev 定期獲取的包類型以過濾的列表。

您可能還會對「Fix All」命令感興趣 (#3445，#3469)，該命令可用于 Dart 檔案，並可以修復與 dart fix 相同的所有問題，以一步驟修復當前打開的檔案。

這也可以通過將 source.fixAll 添加到 editor.codeActionsOnSave VS Code 设置来设置为在保存时运行。

或者，如果您想尝试预览功能，可以启用 dart.previewVsCodeTestRunner 设置，并查看使用新的 Visual Studio Code 測試執行器運行的 Dart 和 Flutter

【文章內容使用 Gemini 1.5 Pro 自動產生】

柵格執行緒效能優化技巧

最近，我坐下來調整 FlutterFolio 的效能，這個應用程式是作為 Flutter Engage 的設計展示而建立的。只改變了一處，我就讓 FlutterFolio 變得快了很多。

不過，首先，我必須找出要改什麼。這篇文章就是關於這個搜尋的。

FlutterFolio 是一個功能完整的應用程式，從設計到實作，花了 6 個星期 (!) 時間完成，支援行動裝置、桌面和網頁。開發團隊顯然必須做一些妥協 - 沒有任何批評。專案的範圍和非常短的時程迫使他們這樣做。

事實上，這是一個絕佳的機會，因為這個應用程式比我想到的所有範例應用程式都更加「真實」。

而且，效能優化在真實應用程式上比在合成問題上更好解釋。

第 1 步：效能分析

任何優化的第一步是什麼？量測。知道一個應用程式看起來很慢是不夠的。你需要更精確一點。兩個原因：

1. 量測可以將我們引導到最糟糕的肇事者。任何應用程式的每個部分都可以變得更快、更有效率。但是，你必須從某個地方開始。效能分析讓我們看到哪些部分做得還可以，哪些部分做得不好。然後，我們可以專注於做得不好的部分，並在有限的時間內取得更大的進展。
2. 我們可以比較前後。有時，程式碼變更看起來像是個好主意，但實際上，它並沒有產生顯著的差異。有了基準（之前）就表示我們可以量化變更的影響。我們可以將之前與之後進行比較。

應用程式的效能分析很困難。我在 2019 年寫了一篇關於這方面的 長篇文章。所以，讓我們從簡單的開始。我們在 profile 模式下執行應用程式，開啟效能覆蓋圖，並使用應用程式，同時觀察效能覆蓋圖的圖表。

我們立即看到柵格執行緒正在努力。

這尤其發生在捲軸瀏覽應用程式的主頁時。您應該始終優先考慮使用者花費大部分時間的部分或效能問題對使用者特別明顯的部分。換句話說，如果您有兩個效能問題，其中一個發生在開始畫面，另一個埋藏在設定頁面中，請先修復開始畫面。

讓我們看看柵格執行緒在做什麼。

旁白：UI 執行緒 vs. 柵格執行緒

其實，讓我們先澄清柵格執行緒做什麼。

所有 Flutter 應用程式都在至少兩個並行執行緒上運行：UI 執行緒和柵格執行緒。UI 執行緒是您建立 Widget 和應用程式邏輯運行的地方。（您可以建立隔離區，這表示您可以在其他執行緒上運行邏輯，但為了簡單起見，我們將忽略這一點。）柵格執行緒是 Flutter 用來 柵格化 您的應用程式的方式。它接收來自 UI 執行緒的指令，並將它們轉換成可以傳送到圖形卡的東西。

為了更具體，讓我們看看一個 build 函數：

1
2
3

Widget build(BuildContext context) {
  return Image.asset('dash.png');
}

上面的程式碼在 UI 執行緒上運行。Flutter 架構找出要放置 Widget 的位置、要給它什麼尺寸，等等 - 仍然在 UI 執行緒上。

然後，在 Flutter 知道有關畫面的所有資訊之後，它就會交給柵格執行緒。柵格執行緒會取得 dash.png 中的位元組，調整圖片的大小（如果需要），然後應用不透明度、混合模式、模糊等等，直到它取得最終的像素。然後，柵格執行緒將得到的資訊傳送到圖形卡，因此也傳送到螢幕。

第 2 步：深入時間軸

好的，回到 FlutterFolio。開啟 Flutter DevTools 讓我們可以更仔細地查看時間軸。

在 效能 標籤中，您可以看到 UI 執行緒（淡藍色條）做得很好，而柵格執行緒（深藍色和紅色條）在每個畫面中花費了令人驚訝的時間，特別是在捲軸向下瀏覽主頁時。因此，問題不在於低效的 build 方法或商業邏輯。問題是要求柵格執行緒做太多事。

事實上，每個畫面 都花費了很長時間在柵格執行緒上，這告訴了我們一些事情。它表示我們要求柵格執行緒做一些工作 一次又一次 - 它不是偶爾做一次的事情。

讓我們選擇一個畫面，看看 時間軸事件 面板。

時間軸的頂部，帶有淺灰色背景，是 UI 執行緒。再次，您可以看到 UI 執行緒不是問題。

在 UI 執行緒下方，您可以看到柵格執行緒上的事件，從 GPURasterizer:Draw 開始。不幸的是，這就是事情變得有點模糊的地方。有許多對異國情調名稱方法的呼叫，例如 TransformLayer::Preroll、OpacityLayer::Preroll、PhysicalShapeLayer::Paint 等等。沒有關於這些方法中發生了什麼事情的詳細資訊，而且這些不是大多數 Flutter 開發人員認識的名稱。

它們是來自 Flutter 引擎的 C++ 方法。如果您想，您可以 搜尋 這些方法名稱，閱讀程式碼和註解，看看幕後發生了什麼。有時，這可以讓您對柵格執行緒在做什麼有更多直覺。但是，這種研究對於找出效能問題來說並不嚴格需要。（我直到相對最近才做過這種研究，但仍然能夠優化許多應用程式的效能。）

然後，有一個標記為 SkCanvas::Flush 的長事件。它花了 18 毫秒，遠遠超過合理範圍。不幸的是，該事件也沒有任何詳細資訊，因此我們需要做一點偵探工作。

SkCanvas 中的 Sk 代表 Skia，這是 Flutter 用於在其堆疊最底層進行渲染的圖形引擎。SkCanvas 是一個低階 C++ 類別，類似於 Flutter 自己 的 Canvas（如果您使用 CustomPaint，您可能已經熟悉它）。您應用程式的所有像素、線條、漸變 - 所有 UI - 都會經過 SkCanvas。而且，SkCanvas::Flush 是這個類別在收集到所有需要的資訊後進行大部分工作的地方。文件 指出 Flush 方法「解決所有未決的 GPU 作業」。

讓我們回顧一下我們從效能時間軸中学到的东西：

• 柵格執行緒是主要問題。UI 執行緒做得相對良好。
• 在捲軸時，柵格執行緒在 每個畫面 中花費了很長時間。一些昂貴的柵格化工作一直在進行。
• SkCanvas::Flush 花費了很長時間，這表示 Skia 正在做很多功課。

我們 不知道 那個功課是什麼。讓我們回顧一下程式碼。

第 3 步：閱讀程式碼

有了知識，讓我們看看原始碼。如果程式碼不熟悉（就像我對 FlutterFolio 的情況一樣），最好從 profile 模式切換到 debug 模式，並使用 Flutter Inspector 跳轉到相關 Widget 的原始碼。

FlutterFolio 的主頁，至少在行動裝置上，似乎基本上是一個由 BookCoverWidgets 填充的垂直 PageView。查看 BookCoverWidget，您可以看到它本質上是一個 各種 Widget 的堆疊，從底部的大型圖片開始，繼續是一些動畫覆蓋層、主要文字內容，最後是頂部的滑鼠懸停覆蓋層。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

child: Stack(fit: StackFit.expand, children: [
  /// /////////////////////////////<br>
  /// 背景圖片
  // 當我們滑鼠懸停時，動畫縮放
  AnimatedScale(
    duration: Times.slow,
    begin: 1,
    end: isClickable ? 1.1 : 1,
    child: BookCoverImage(widget.data),
  ),

  /// 黑色覆蓋層，在滑鼠懸停時淡出
  AnimatedContainer(duration: Times.slow, 
     color: Colors.black.withOpacity(overlayOpacity)),

  /// 當處於大型模式時，顯示一些漸變，
  /// 應該位於文字元素下方
  if (widget.largeMode) ...[
    FadeInLeft(
      duration: Times.slower,
      child: _SideGradient(Colors.black),
    ),
    FadeInUp(child: _BottomGradientLg(Colors.black))
  ] else ...[
    FadeInUp(child: _BottomGradientSm(Colors.black)),
  ],

  /// 放在文字內容下方，點擊時取消焦點。
  GestureDetector(behavior: HitTestBehavior.translucent, 
      onTap: InputUtils.unFocus),

  /// BookContent，顯示大型封面或小型封面
  Align(
    alignment: widget.topTitle ? Alignment.topLeft : Alignment.bottomLeft,
    // 根據我們處於哪種模式，對填補進行動畫轉場
    child: AnimatedContainer(
      duration: Times.slow,
      padding: EdgeInsets.all(widget.largeMode ? Insets.offset : Insets.sm),
      child: (widget.largeMode)
          ? LargeBookCover(widget.data)
          : SmallBookCover(widget.data, topTitle: widget.topTitle),
    ),
  ),

/// 滑鼠懸停效果
  if (isClickable) ...[
    Positioned.fill(child: FadeIn(child: RoundedBorder(color: theme.accent1, ignorePointer: false))),
  ],
]),

現在，請記住：您正在尋找的是在每個畫面中都會發生的東西（也就是說，它始終存在），並且可能對於 Skia 渲染器來說繪製起來很昂貴（圖片、模糊、混合等等）。

第 4 步：深入探討

現在，您需要深入探討以找出可能存在问题的 Widget。一種方法是暫時從應用程式中移除各種 Widget，看看這對效能有什麼影響。

請記住，堆疊的第一個子元素是背景，每個後續子元素都是之前 Widget 上方的圖層。所以，第一個子元素是背景圖片，由 BookCoverImage 表示。您可以移除它，但主頁看起來會像這樣：

這就失去了整個頁面的意義。仔細查看 BookCoverImage，您可以看到它只是一個簡單的 Image 函式包裝器。除了一个值得注意的例外（本文稍後會提到）之外，這裡沒有什麼可以改進的地方。

繼續，有這段程式碼：

1
2
3

/// 黑色覆蓋層，在滑鼠懸停時淡出
AnimatedContainer(duration: Times.slow, 
  color: Colors.black.withOpacity(overlayOpacity)),

這是一個用透明黑色覆蓋整個圖片的 Widget。overlayOpacity 預設情況下為 0（而且大部分時間都是如此），所以這個圖層是完全透明的。嗯。讓我們將它移除，並再次在 profile 模式下執行應用程式。

有趣！柵格執行緒仍然承擔了大量負載，但效能有了顯著改善。

我決定為 FlutterFolio 實作一個更強大的效能分析工具，以便我可以證明改進是真實的，而不仅仅是偶然。這個變更讓我柵格化所花費的 CPU 時間整體減少了 20%，潛在的卡頓減少了 50%。

總的來說，這是一個巨大的變化，因為移除了一個大部分時間都無效的單個 Widget。

修復 很簡單：

1
2
3
4

/// 黑色覆蓋層，在滑鼠懸停時淡出
if (overlayOpacity > 0)
  AnimatedContainer(duration: Times.slow,
      color: Colors.black.withOpacity(overlayOpacity)),

現在，您只在它具有非零不透明度（也就是說，它至少部分可見）時才會加入透明覆蓋層。您避免了（非常常見的！）情況，即建立並柵格化一個完全透明的圖層，但它没有任何效果。

就這樣，應用程式變得更加流暢，也更節省電量。

注意：為什麼你需要這樣做？Flutter 不應該足夠聰明地為我們執行這個優化嗎？請閱讀 此處 的議題，了解為什麼它做不到。為什麼透明不透明度在第一時間會變慢？這超出了本文的範圍，但它與堆疊中更上方的 BackdropFilter Widget 相關，它會與下方每個 Widget 相互作用。

本文的主要目的不是教你關於這個特定效能陷阱的知識。你可能永遠不會再看到它。我的目標是教你如何一般性地優化柵格執行緒效能。

第 5 步：概括

在繼續處理一個完全不同的問題之前，通常最好查看專案中的其他地方，看看是否有類似的問題。我們的應用程式中是否有其他地方使用了大面積覆蓋層？你能避免它們嗎？

在這種情況下，接下來的幾行會建立在您捲軸時會淡入的大型漸變：

1
2
3
4
5
6
7
8
9
10
11

/// 當處於大型模式時，顯示一些漸變，
/// 應該位於文字元素下方
if (widget.largeMode) ...[
  FadeInLeft(
    duration: Times.slower,
    child: _SideGradient(Colors.black),
  ),
  FadeInUp(child: _BottomGradientLg(Colors.black))
] else ...[
  FadeInUp(child: _BottomGradientSm(Colors.black)),
],

而且，果然，移除這些動畫的、幾乎佔據全螢幕的漸變會顯著改善捲軸效能。不幸的是，在這種情況下，解決方案不像之前的範例那样简单。這些漸變不是無形的。它們會在使用者到達特定封面時開始淡入。移除它们 确实 会造成視覺上的差異。

一個想法是稍微延遲淡入，這樣動畫只会在使用者降落在特定 BookCover 上時才會開始。這樣一來，您就可以減輕柵格執行緒的負載，而使用者在捲軸時，也希望可以避免一些潛在的卡頓。

但是，這涉及到對應用程式的動態設計進行修改，因此需要與更廣泛的團隊討論。許多效能優化都會屬於這類。效能優化通常是折衷的過程。

重複步驟 2-5 直到滿意

到目前為止，我們只查看了一種類型的問題。總是會有更多問題。

以下是一個關於下一步的想法：應用程式的圖片資產是否太大？請記住，柵格執行緒負責取得圖片位元組、解碼它們、調整大小、應用濾鏡等等。如果它將一個 20 MB 的高解析度圖片載入到螢幕上的一個小頭像圖片中，那麼您就是在浪費資源。

當您的應用程式在 debug 模式下執行時，您可以使用 Flutter Inspector 來 反轉過大的圖片。

這將會反轉顏色並翻轉應用程式中對於實際用途來說太大的所有圖片。然后，您可以仔细检查应用程序，并注意不自然的变化。

debug 模式還會在每次遇到這種圖片時報告一個錯誤，例如：

[錯誤] 圖片 assets/images/empty-background.png 的顯示大小為 411×706，但解碼大小為 2560×1600，額外使用了 19818KB。

不過，這裡的解決方案並不直接。在行動裝置上，您不需要 2560×1600 的圖片，但在桌面上，您可能需要。請記住，FlutterFolio 是一個在所有 Flutter 目標上執行的應用程式，包括桌面。如有疑問，請 閱讀 API 文件。

結語

如您所見，優化效能是一门艺术和科学。強大的基準測試以及對框架及其內建 Widget 的深刻理解都有助於這一點。

最终，熟能生巧。優化足夠多的應用程式，你就會變得更好。

祝您狩獵愉快。

柵格執行緒效能優化技巧 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

https://creativecommons.org/licenses/by-nc/4.0/