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

Flutter 登上 GDC 舞台

去年，Flutter 的休閒遊戲工具包迎來了 重大更新。本週，Flutter 在舊金山舉行的 遊戲開發者大會 (GDC) 上首次亮相，這是遊戲產業最頂尖的專業活動，致力於支持遊戲開發人員及其技能的發展。請继续阅读，了解開發者們在 Flutter 上構建遊戲的進展，以及 Flutter 遊戲開發的未来展望。

自 Flutter 休閒遊戲工具包 發佈以來，Flutter 在遊戲開發領域取得了顯著進展。在過去的 12 個月裡，使用 Flutter 開發了超過 15,000 款新的行動遊戲。

Flutter 已證明是各種規模遊戲應用的吸引人選項，它為首次接觸遊戲開發的新手開發者（例如 Tatsuya，他利用 Flutter 在閒暇時間創造了 Tinies Merge，並在 Google Play 的獨立遊戲節 上入圍前 20 名）以及 Trivia Crack 等熱門遊戲背後的團隊（在全球擁有數億次下載量！）提供了支持。

為什麼選擇 Flutter 開發遊戲？

對於 2D 休閒遊戲，特別是介面驅動型或回合制遊戲，Flutter 提供了令人信服的优势。它是開源軟體，這意味著它消除了授權費，提供了對遊戲機制的深度控制，以及對豐富的插件生態系統的存取。Flutter 的「熱重載」功能加快了開發速度，而其優化的引擎確保了跨設備（包括瀏覽器）的順暢效能。Flutter 能夠一次構建，跨平台部署，包括 iOS、Android、網頁、桌面和 Google Play 遊戲 for PC，簡化了遊戲的覆蓋範圍。因此，如果您是遊戲開發者，不要忽視 Flutter 的潛力——嘗試用 Flutter 開發您的下一款遊戲，並幫助我們傳播這個消息！

2024 年及以後：共同打造 Flutter 遊戲開發生態系統

在 2024 年，我們致力於賦能您使用 Flutter 創造出色的休閒遊戲體驗。我們的重點將放在：

• 簡化開發： 預計將擴展遊戲開發資源，例如範本、插件整合和深入指南，以加快您的工作流程，並釋放 Flutter 的遊戲開發潛力。
• 擴展覆蓋範圍： 我們正在努力使 Flutter 遊戲在網頁和其他平台上的部署更加順暢，為您的作品打開新的受眾群體。
• 為未來奠定基礎： 雖然 2D 行動遊戲支援是我們的首要重點，但我們熱衷於將 3D 功能作為 Flutter GPU 努力的一部分進行探索。您可以查看我們的一些 早期實驗，了解我們的進展。

特別感謝社群

我們對社群的堅定支持和重大貢獻表示衷心的感謝，這些貢獻推動了 Flutter 在遊戲開發領域的非凡發展。

我們對您的工作感到敬畏，並對許多傑出的貢獻表示衷心的感謝，包括：

• Luan Nico，Lukas Klingsbo，Erick Zanardo，Renan Araujo，Arron Washington，Pasha Stetsenko，Jochum van der Ploeg，Fernando Ultremare，DevKage (Flame)：您對 Flame 引擎及其相關專案的工作對 Flutter 遊戲開發具有變革意義。
• Rafael Barbosa (Bonfire：您強大而多功能的遊戲引擎是構建 RPG 風格遊戲的絕佳工具。
• Filip Hráček：您的範本和教程為許多新的遊戲開發者提供了寶貴的起點。
• Jeff Ward：將 Dart 嵌入其他遊戲引擎中開闢了令人興奮的可能性。
• @VeryGoodVentures 的出色團隊：您精美的遊戲和分享最佳實務的意願提高了所有人的標準。
• Abedalkareem Omreyh (遊戲服務)，August，subhash279 (音訊播放器)，Marco Bavagnoli (Flutter SoLoud) 和 無數其他人 創造了必不可少的套件：您提供的基礎使複雜且引人入勝的遊戲在 Flutter 中成為可能。

這個列表只是社群中人才的冰山一角。對於我們無法個別提名的所有人：我們對您的貢獻深表感謝，您使 Flutter 成為一個充滿活力的遊戲開發場所！

同時，我們也向使用 Flutter 發佈遊戲的開發者們表示最衷心的感謝。您的創意和激情激勵著我們不斷突破可能的界限，使 Flutter 成為全球開發者更強大的工具。

Flutter 作為遊戲開發平台的旅程才剛剛開始。我們致力於與社群共同成長，聆聽您的回饋，并構建您所需的工具。

我們迫不及待想看看您會建立什麼！

Flutter 登上 GDC 舞台 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

Dart 參與 2024 Google 暑期程式碼計畫

Google 暑期程式碼計畫 (GSoC) 的重點是將來自世界各地的學生開發人員帶入開源軟體開發領域。Google 贊助學生在夏季與一個指導開源組織合作進行一個為期 12 週（或更長時間）的程式設計專案。在過去的 19 年裡，已有超過 20,000 名貢獻者參與了 Google 暑期程式碼計畫。

我們很高興地宣布，Dart 專案將在 2024 年 Google 暑期程式碼計畫中指導貢獻者（第五次！）。

您有興趣嗎？

若要立即開始，請閱讀 專案構想列表，以找到與您的技能和興趣相符的專案。正式申請必須在 4 月 2 日之前提交。我們鼓勵潛在的申請者提前提交草稿並徵求回饋。

Dart 團隊預計會有足夠的導師來接受少數申請，因此也請查看 其他指導組織。

如果您有關於 Dart 和 GSoC 的具體問題，請在 我們的專用郵件列表 中提問。

若要進一步了解 Google 暑期程式碼計畫，請觀看以下影片或閱讀 Google 暑期程式碼計畫的貢獻者指南。

我們期待您的回音！

Dart 參與 2024 Google 暑期程式碼計畫 最初發佈於 Medium 上的 Dart，人們在那裡透過醒目顯示和回應這個故事來繼續討論。

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

Flutter 如何促進 L+R 設計師和開發人員的合作

您可能熟悉 Global Citizen (GC)，這是一個致力於消除世界貧困和幫助地球的組織。當 GC 想要重新編寫一個行動應用程式來幫助完成這項工作時，他們聯繫了我們的工作室 L+R，共同設計、開發和同步推出 Android 和 iOS 版本的應用程式。

Flutter 的靈活性、預建 Widget 清單和強大的動畫功能讓 L+R 團隊能夠實施以設計為導向的開發流程。使用 Flutter 時，我們的開發人員擁有一個空白畫布，可以將自訂設計變為現實。對於 L+R 來說，這意味著我們的設計團隊可以釋放他們的創造力，打造以使用者為中心的應用程式，這些應用程式看起來很棒，體驗也很棒。

以下是 Global Citizen 應用程式中的一些螢幕截圖：

設計流程

在開始新的客戶專案時，設計師首先在 Figma 中建立一個設計系統。這包括品牌指南 - 例如調色盤和文字排版 - 以及小的可重複使用元件。

在開始重寫 Global Citizen 應用程式時，設計團隊擴展了現有指南，以提供具有更高對比度元素的新面貌。這不僅有助於引導使用者的注意力，還改善了可訪問性。

UI 元素在 Figma 中被建立為 元件。每個元件可能具有不同的 變體，具體取決於元件類型或狀態。例如，下圖顯示了幾個按鈕變體：

在開發新的元件時，設計團隊參考了 Figma 中的 Material 和 iOS 設計套件以獲取靈感。這有助於將設計轉換為程式碼，因為這些 Figma 元件與 Material 和 Cupertino 函式庫中提供的 Widget 密切相關。

在整個設計過程中，團隊將小的可重複使用元件組合成更大的功能特定元件，然後將這些元件組合成完整的頁面。這使 Global Citizen 的產品團隊能够擴展應用程式，添加新的功能，同時保持與最初愿景的一致性。

專案範本

在 L+R，我們團隊從第一個公開發佈版本開始就一直在使用 Flutter。為了讓我們的團隊快速簡便地構建 Flutter 應用程式，我們建立了一個 開源儲存庫，它作為專案範本，為我們構建的所有 Flutter 應用程式提供了基石。

這個簡潔的專案包含一組可以自訂並用於客戶應用程式的 Widget。例如，Figma 設計檔案中所呈現的按鈕（如上所示）可以使用專案範本中的 _BaseButton 類別構建。此類別接受不同的顏色、文字樣式和內嵌，以最佳匹配為該專案設定的設計系統。

，

為了讓根據品牌指南輕鬆地為這些元件設定樣式，我們使用 ThemeData 類別。開發人員從 Figma 中取得顏色方案和文字樣式，並將它們對應到相應的主題屬性。

我們的團隊盡可能地利用 ThemeData 中現有的屬性，然後使用 ThemeExtension 功能完成剩餘的設定。

Flutter 的 Widget 函式庫

如上所述，專案範本包含一組可重複使用的 Widget。在開發這些 Widget 時，我們盡可能地使用 Material 和 Cupertino 函式庫中的預先存在的 Widget。在 Global Citizen 應用程式中，大約一半的元件來自 Material 或 Cupertino Widget。

例如，Material 中的 TextField 和 TextFormField Widget 包含與設計相符的所有必要的自訂和功能。Material 中的 TextButton 也用於實作 _BaseButton Widget。在這種情況下，我們利用了 TextButton 現有的突出顯示功能，但我們將其包裝到一個具有擴展功能的新 Widget 中，以更好地滿足我們的需求。

擁有這些開箱即用的 UI 元件，可以輕鬆地為其設定樣式，這使得構建和維護我們的 Widget 變得更加容易。但是，有時我們的設計師會創建無法使用 Flutter 的 Material 或 Cupertino Widget 重新建立的自訂元件。在這些情況下，開發團隊會使用低階 Flutter Widget 創建我們自己的自訂 Widget。

Global Citizen 應用程式中的一個範例是進度指示器。對於這個應用程式，我們的設計師創建了一個自訂進度指示器，如以下 GIF 中所示。現有的 Material 和 Cupertino 進度指示器不適用於此設計。但是，我們的開發人員可以輕鬆地使用容器、行和列以及內在動畫創建一個全新的 Widget。

社群函式庫對於更複雜和靈活的元件也非常有用。例如，我們使用社群構建的 flushbar 在 Global Citizen 應用程式中顯示警報通知。

熱重載

在將 Figma 設計轉換為 Flutter 程式碼時，設計師和開發人員的合作非常重要。設計師通常會提供回饋，導致樣式、佈局或動畫的微調。熱重載使這種合作變得更加高效。

使用熱重載，開發人員可以在與設計團隊進行螢幕共享時調整程式碼（無論是在 UX 階段、UI 概念階段、前端實施階段，甚至是在設計 QA 階段）。在螢幕共享時，設計師可以立即看到更改的結果。這使得除錯和迭代變得更快。

流暢的動畫

有助於應用程式感覺精緻的一件事是添加周到的動畫。Flutter 的動畫框架靈活而強大，但設計師可能難以理解。對我們團隊有所幫助的一件事是參考開源應用程式中的精美動畫。具體來說，我們查看了 Wonderous 應用程式 的程式碼庫。從那時起，我們利用了為 Wonderous 提供動力的開源函式庫 flutter_animate，為關鍵功能添加了簡單但豐富的動畫。

以下鏈接中的影片突出了「採取行動」流程的一部分，使用者在其中瀏覽一系列信息螢幕以了解有關問題的更多信息。

查看 action_learn_animations 影片。

使用 flutter_animate，我們能夠執行以下操作：

• 在使用者向前移動時為步驟指示器製作動畫
• 在頁面之間添加輕微的淡入淡出轉場
• 在觀看影片後將「播放影片」按鈕轉換為成功勾號

總的來說，Flutter 允許設計和開發使用靈活的方法。Flutter 的預建 Widget 使創建可重複使用、可以設定樣式以匹配客戶品牌形象的 UI 元件變得更加容易。Flutter 社群在技術發展過程中發揮著重要作用，提供高品質的函式庫並擴展可用資源。Flutter 的關鍵功能（如熱重載）支持設計師和開發人員之間更好的協作。所有這些加在一起就會產生一個既美觀又實用的應用程式！

有關應用程式的更多信息，請查看 新 Global Citizen 應用程式：每日行動主義和可衡量的影響力，盡在您的口袋。您也可以 將 Global Citizen 應用程式下載 到您的行動裝置上。

L+R 是一個國際策略、設計和行動技術工作室。我們提供許多服務，例如 UX 設計、行動開發和策略咨詢。

Flutter如何促進L+R設計師和開發人員的合作 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

使用 Gemini API、Impeller 更新和 Windows Arm64 支援徹底改變應用程式開發

今天，我們向您介紹一個新的 Flutter 版本，Flutter 3.19。此版本帶來了新的 Gemini Dart SDK、讓開發人員能夠為 Widget 動畫加入精細控制的 Widget、透過 Impeller 更新提升渲染效能、幫助實作深層連結的工具、Windows Arm64 支援等等！

Flutter 社群持續令人印象深刻，由 168 位社群成員合併了 1429 個拉取請求，其中 43 位社群成員提交了他們的第一個 Flutter 拉取請求！

請繼續閱讀，了解 Flutter 社群為這個最新版本貢獻的所有新增功能和改進！

AI 整合

Gemini Google AI Dart SDK beta 版本發佈

Google AI Dart SDK 已發佈至 beta 版本。這讓您能夠使用 Google 最新一代 AI 模型 Gemini 來為您的 Dart 或 Flutter 應用程式建立生成式 AI 功能。現在在 pub.dev 上有一個 google_generative_ai 套件。在 這篇部落格文章 中了解如何在您的 Dart 或 Flutter 應用程式中使用 Google AI Dart SDK，或者直接跳入 Dart 快速入門。

架構

捲軸改進

過去，如果您拖動兩根手指，Flutter 的捲軸速度會快兩倍。您現在可以使用 MultiTouchDragStrategy.latestPointer 來設定預設的 ScrollBehavior，以獲得與手指數量無關的捲軸行為。有關此變更的更多資訊，請參閱 遷移指南。

我們還完成了針對 SingleChildScrollView 和 ReorderableList 的錯誤修復，解決了许多報道的當機和意外行為。

在二維捲軸中，我們解決了一個問題，因此現在，如果您在捲軸進行時（無論是在任何方向）拖動或點擊，捲軸活動會按預期停止。

two_dimensional_scrollables 套件中的 TableView Widget 也已在上次版本發佈後更新，提供了更多潤色，加入了對合併單元的支援，並在 3.16 的上次穩定版本發佈後採用了 2D 基礎的更多新功能。

AnimationStyle

感謝 Flutter 社群成員 TahaTesser 的 貢獻，Flutter 有了一個新的 AnimationStyle Widget，讓使用者可以覆蓋 Widget（例如 MaterialApp、ExpansionTile 和 PopupMenuButton）中的預設動畫行為，讓開發人員能夠覆蓋動畫曲線和持續時間。

SegmentedButton.styleFrom

Flutter 社群成員 AcarFurkan 加入了一個 styleFrom 靜態實用方法，就像其他按鈕類型提供的那些方法一樣。此方法讓您能夠快速建立可以與其他分段按鈕共用或用於設定應用程式 SegmentedButtonTheme 的 SegmentedButton 的 ButtonStyle。

Adaptive Switch

這個自適應組件在 macOS 和 iOS 上看起來和感覺起來像原生組件，而在其他地方則具有 Material Design 的外觀和感覺。 它不依賴於 Cupertino 函式庫，因此其 API 在所有平台上完全相同。

查看 自適應開關拉取請求 和在 Switch.adaptive 建構函數的 API 頁面 上的實時範例。

SemanticsProperties 無障礙識別碼

SemanticsProperties 中的一個新的無障礙識別碼為原生無障礙層級結構中的語義節點提供了一個識別碼。在 Android 上，它會在無障礙層級結構中顯示為 resource-id。在 iOS 上，這會設定 UIAccessibilityElement.accessibilityIdentifier。我們感謝社群成員 bartekpacia 做出的此項變更，這涉及了 引擎 和 框架。

提升對文字 Widget 狀態的存取權

我們在 TextField 和 TextFormField 中加入了對 MaterialStatesController 的支援，以便您可以監聽 MaterialState 變更。

UndoHistory 堆疊

我們 修復了 一個問題，在該問題中，撤消/重做歷史記錄可能會在日文鍵盤上消失。您現在可以在項目被推入到 UndoHistory 堆疊之前修改它。

引擎

Impeller 進展

Android OpenGL 預覽

在 3.16 穩定版本中，我們邀請使用者在啟用 Vulkan 的 Android 設備上試用 Impeller，覆蓋了現場 77% 的 Android 設備。在過去的幾個月裡，我們將 Impeller 的 OpenGL 後端提升到與 Vulkan 後端的功能一致，例如，透過加入對 MSAA 的支援。這意味著，幾乎所有 Android 設備上的 Flutter 應用程式都應該能夠正確渲染，除了少數尚未完成的功能，例如自訂著色器和對外部紋理的完全支援，這些功能很快就會推出。

我們請求 Flutter 開發人員升級到最新的穩定版本，並提交有關在 啟用 Impeller 時觀察到的任何不足的錯誤。在此階段的回饋對確保 Impeller 在 Android 上取得成功以及我們能夠在今年晚些時候的版本中自信地將其設為預設渲染器至關重要。Android 硬體生態系統比 iOS 生態系統更加多元。因此，關於 Impeller 最有用的回饋應包括有關發生問題的特定設備和 Android 版本的詳細資訊。

此外，作為提醒，Impeller 的 Vulkan 後端在 除錯 版本中啟用了超出 Skia 所使用的額外除錯功能，這些功能具有額外的執行時間開銷。因此，重要的是要從 分析 或 發佈 版本中提供關於 Impeller 效能的回饋。錯誤報告應包含來自 DevTools 的時間線，以及在相同設備上的 Skia 後端的比較。最後，與往常一樣，我們非常感謝包含演示問題的小型可重現測試案例的回饋。

路線圖

在渲染保真度之後，我們在 Impeller Android 預覽期的主要關注點是效能。我們持續取得了漸進的進展，但是還有一些較大的改進正在進行中。我們預計工作將利用 Vulkan 子傳遞 來大幅提高進階混合模式的效能。此外，我們還預計渲染策略從始終在 CPU 上細分每條路徑轉變為 「先模板化然後覆蓋」 方法的變化將大幅降低 Impeller 在 Android 和 iOS 上的 CPU 使用率。最後，我們預計對 高斯模糊 的全新實作將與 Skia 實作的吞吐量相符，並改進 iOS 上模糊的慣用方法。

API 改進

字形資訊

此版本包含 dart:ui 的 Paragraph 物件上的兩個新方法：getClosestGlyphInfoForOffset 和 getGlyphInfoAt，它們分別回傳新的類型 GlyphInfo 的物件。查看有關新的 GlyphInfo 類型的文件。

GPU 追蹤

在金屬 (iOS、macOS、模擬器) 上的 Impeller 和啟用 Vulkan 的 Android 設備上，Flutter 引擎現在在除錯和分析版本的時間線中報告每個畫面的 GPU 時間。可以透過 DevTools 中的「GPUTracer」標題檢視 GPU 畫面時間。

請注意，由於非 Vulkan Android 設備可能會錯誤地報告其對查詢 GPU 時間的支援，因此 Impeller 的 GPU 追蹤只能在這些設備上透過在 AndroidManifest.xml 檔案中設定的旗標來啟用。

1
2
3

<meta-data
  android:name="io.flutter.embedding.android.EnableOpenGLGPUTracing"
  android:value="true" />

效能優化

專用常數

團隊為 Impeller 加入 對專用常數的支援。在 Impeller 的著色器中利用此功能，將 Flutter 引擎的未壓縮二進制文件大小減少了 將近 350KB。

背景濾鏡加速

還有很多工作要做，但是此版本包含了一些對 Impeller 上的背景濾鏡和模糊的良好效能改進。特別是，開源貢獻者 knopp 注意到，Impeller 錯誤地請求了從螢幕上紋理讀取的能力。移除此功能 提高了包含多個背景濾鏡的場景在我們的基準測試中的效能，提高了 20-70%，具體取決於複雜程度。

此外，Impeller 不再無條件地為每個背景濾鏡儲存模板緩衝區。相反，任何會影響操作的剪輯都會被記錄，並且在為背景濾鏡還原儲存層時會被重新播放到新的模板緩衝區中。

透過此項變更，我們在執行 Vulkan 後端且啟用 Impeller 的 Pixel 7 Pro 上運行的動畫進階混合模式的基準測試結果顯示，平均 GPU 畫面時間從 55ms 提高到 16ms，並且 90% 的柵格執行緒 CPU 時間從大約 110ms 降低到 22ms。

Android

深層連結網頁驗證器

我們從開發人員那裡了解到，深層連結（將使用者從網頁 URL 引導到行動應用程式中的特定頁面）一直以來都很難實現，而且也很容易出错。因此，我們首先創建了一個驗證工具，以幫助開發人員了解哪些連結設定不正確，並提供實現指南。我們很高兴地宣布，Flutter 深層連結驗證器的早期版本現已推出！

在此早期版本中，Flutter 深層連結驗證器支援 Android 上的網頁檢查，這意味著驗證 assetlinks.json 檔案的設定。您可以打開 DevTools，點擊 深层链接 標籤，並匯入包含深層連結的 Flutter 專案。深層連結驗證器會告訴您您的網頁文件是否設定正確。您可以參閱深層連結驗證工具的 測試說明 以獲取更多資訊。

我們希望此工具是簡化深層連結實現旅程的第一步。我們將繼續努力為 iOS 上的網頁檢查和 iOS 和 Android 上的應用程式檢查提供未來的支援！

支援 Share.invoke

文字欄位和視圖上的預設 Share 按鈕過去在 Android 中缺失，但我們已在這個版本中加入了它，這是我們持續努力確保所有預設內容選單按鈕在每個平台上都可以使用的一部分。您可以在 PR #107578 中追蹤這項持續進行的工作。

原生資產功能

如果您對 Flutter 與 Flutter 程式碼中來自其他語言的函數的互操作性感興趣，您現在可以在 Android 上透過原生資產執行 FFI 調用，這是我們對支援原生資產的 持續工作 的一部分。

紋理層混合合成 (TLHC) 模式

Flutter 3.19 包含的工作現在讓 Google Maps 和文字輸入放大鏡可以在 TLHC 模式下工作，這意味著您的應用程式能夠擁有更好的效能。如果您正在使用 Google Maps，我們鼓勵您測試這些更改並給我們提供您的回饋！

這項工作不包括 Framework 或 Engine 下的提交，但您可以在 PR 5408 中查看這項工作，以及測試 THLC 的步驟。

自訂系統範圍文字選取工具列按鈕

Android 應用程式可以加入出現在所有文字選取選單中的自訂文字選取選單項目（當您長按文字時出現的選單）。Flutter 的 TextField 選取選單現在會將這些項目整合進去。

iOS

Flutter iOS 原生字體

Flutter 文字現在在 iOS 上看起來更加緊湊，也更加原生。根據 Apple 的設計指南，iOS 上的較小字體應該更加分散，以便在行動裝置上更容易閱讀，而較大的字體應該更加緊湊，以免占用太多空間。之前，我們在所有情況下都錯誤地使用了較小、更加分散的字體。現在，預設情況下，Flutter 將會為較大的文字使用緊湊字體。

DevTools

DevTools 更新

這個版本中 DevTools 的一些亮點是：

• 在 DevTools 中加入了一個新的功能和螢幕，用於驗證 Android 上深層連結的設定。
• 在 增強追蹤 選單中加入了一個用於追蹤平台通道活動的選項。這對包含 Plugin 的應用程式很有用。

• 效能和 CPU 分析工具螢幕現在可以在沒有連接的應用程式的情況下使用。先前從 DevTools 儲存的效能資料或 CPU 分析資料可以從這些螢幕中重新載入以供查看。
• VS Code 中的 Flutter 側邊欄現在具有在當前專案未啟用時啟用新平台的功能，側邊欄中的 DevTools 選單現在有一個選項，用於在外部瀏覽器視窗中打開 DevTools。

若要進一步了解，請查看 DevTools 的發行備註，2.29.0，2.30.0 和 2.31.0。

桌面

Windows Arm64 支援

感謝社群成員 pbo-linaro 的出色努力，Windows 上的 Flutter 現在開始支援 Arm64 架構。此項初始支援為在 Windows Arm64 設備上原生執行的 Flutter 應用程式鋪平了道路，讓這些應用程式能夠更加高效地運作。雖然仍處於開發階段，可以在 GitHub 議題 ＃62597 上追蹤進度，但這項舉措表明，對於想要優化其應用程式以支援更廣泛的 Windows 設備的 Flutter 開發人員來說，這是一項很有前景的增強功能。

生態系統

必要的理由隱私說明

Flutter 現在在 iOS 上包含一個隱私說明，以符合 即將生效的 Apple 要求。

Flutter 和 Dart 套件生態系統的進展

如果您錯過了，請查看 1 月份關於 Flutter 和 Dart 套件生態系統進展 部落格文章。

棄用和重大變更

停止支援 Windows 7 和 8

隨著 Flutter 的發展，我們很興奮能夠專注於最新的技術，因此在 Dart 3.3 和 Flutter 3.19 版本中停止對 Windows 7 和 8 的支援。這個調整符合 Microsoft 的策略，讓我們可以在現代作業系統上改進 Flutter。我們感謝開發人員做出的調整，並且致力於幫助您完成這個過渡。此舉為在支援的 Windows 版本上建立更安全、更高效且功能更豐富的開發環境鋪平了道路。感謝您在我們共同創新 Flutter 生態系統的過程中，對我們的理解和適應能力。

Impeller 抖動旗標

如 3.16 穩定版本發佈備註中所述，全域旗標 Paint.enableDithering 已被 移除。查看網站上的 重大變更公告 以獲取完整詳細資訊。

棄用 iOS 11

由於在調用某些網路 API 時發生 執行時間當機，Flutter 不再支援 iOS 11。這意味著針對 Flutter 3.16.6 和更高版本構建的應用程式將無法在這些設備上執行。

棄用自動渲染模式

此版本中的 重大變更 包含在 v3.16 發佈之後過期的棄用 API。若要查看所有受影響的 API，以及其他內容和遷移指南，請查看 此版本中的棄用指南。Flutter fix 支援許多這些棄用，包括 IDE 中的快速修復。可以使用 dart fix 命令列工具評估和應用批量修復。

與往常一樣，非常感謝社群為 貢獻測試 - 這些測試幫助我們識別出這些重大變更。若要進一步了解，請查看 Flutter 的重大變更政策。

這是第一個採用 flutter_driver 套件到棄用政策的版本，除了已經支援的套件 flutter 和 flutter_test 之外。

結語

正如我们在本公告开头所强调的贡献者数量之多，我们是有目的的。Flutter 发展成为一个强大的、高效的工具包，这完全得益于我们令人难以置信的社群的奉献和辛勤工作。衷心感谢每一个人。

若要深入了解此版本中所取得的成果，我們邀請您查看 發行備註和變更日誌，以獲取 Flutter 3.19 中加入的內容的完整列表。

Flutter 3.19 與 Dart 3.3 現在已在 stable channel 上提供。開始使用 Flutter 的最新旅程就像運行 flutter upgrade 一樣簡單。

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

強勢開啓 2024：Flutter 和 Dart 的新篇章

我們興奮地宣布今年首個季度 Flutter 和 Dart 的 SDK 版本更新——Flutter 3.19 和 Dart 3.3，以及一些令人興奮的人工智慧相關消息。

Flutter 和 Dart 的價值與未來

我最近加入了 Flutter 和 Dart 團隊，我很高興能在 AI 迅速發展以提升開發人員生產力並解鎖新型使用者體驗的時刻，與我們的開發人員社群合作。我看到了 Flutter 和 Dart 在幫助塑造未來方面發揮的無限潛力。我同樣受到 Flutter 的最初願景的啟發，即改進為任何設備構建漂亮、高效、多平台應用程式的體驗。

從數百萬支援 Flutter 的才華橫溢且富有創造力的開發人員（他們為框架做出貢獻，或構建令人驚嘆的體驗）來看，很明顯，其他人也看到了這個願景，並有動力去幫助實現它。核心使命仍然相同：提供強大的語言架構配對，讓富有創造力的開發人員能夠為任何設備構建漂亮、豐富且高效能的應用程式。讓我們一起完成吧！

將 Flutter 和 Dart 帶入 Gemini 時代

今天，我們推出了 [Google AI Dart SDK](https://medium.com/flutter/harness-gemini-in-your-dart-and-flutter-apps-00573e560381)，一個新的 pub.dev 套件，[google_generative_ai](https://pub.dev/packages/google_generative_ai)，以及 [支援資源](https://ai.google.dev/tutorials/dart_quickstart)；這些工具共同讓您可以使用 Gemini API 在 Dart 和 Flutter 應用程式中構建自己的基於生成式 AI 的功能，例如智慧聊天機器人、視覺搜尋引擎和圖片描述。Flutter 和 Dart 的跨平台功能以及這個新的 SDK 使您能夠更輕鬆地在不同平台上構建互動式體驗。

這僅僅是我們正在利用 AI 為 Flutter 和 Dart 開發帶來的創新浪潮的開始。例如，Flutter 和 Dart 開發人員很快就可以在 [Google 的 AI Studio](https://aistudio.google.com/?utm_source=flutter&utm_medium=referral&utm_campaign=blog_umbrella_announcement&utm_content=) 中完善您的用例提示後直接複製 Dart 程式碼。

在 [深入探討的部落格文章](https://medium.com/flutter/harness-gemini-in-your-dart-and-flutter-apps-00573e560381) 中了解更多關於 Google AI Dart SDK 的資訊。

許多開發人員已經開始以令人興奮的方式將 Flutter 和 AI 工具結合在一起：

• LeanCode 團隊已使用 Gemini 模型構建了 [arb_translate](https://leancode.co/arb_translate)，一個允許開發人員自動執行翻譯任務的套件。
• We Spot Turtles! 將 Flutter 和 AI 結合到他們的使命中，旨在拯救海龜免於滅絕。他們最近被 Google Play 的 [WeArePlay 活動](https://play.google.com/console/about/weareplay/) 報導。請查看下面的影片。
• AutoGPT，一個基於大型語言模型 (LLM) 的實驗性開源專案，擁有一個 [Flutter 客戶端](https://github.com/Significant-Gravitas/auto_gpt_flutter_client)，可以在 iOS、Android、網頁、macOS 和 Windows 上運行。

[#WeArePlay | Caitlin and Nicolas | We Spot Turtles! | Australia](https://youtu.be/CfzhLOiczDQ?si=Qgc4Yb4Q9xKI6byF)

在您探索 Gemini 模型的功能時，請務必使用 #BuildWithGemini 標籤與我們分享您正在構建的全新且創新的體驗。

兩個新的 SDK 版本

除了 AI 帶來的興奮之外，我們仍然專注於持續構建一個強大的 UI 架構，它能夠交付您想要在任何想要構建的螢幕上構建的任何體驗。您會在今天的 SDK 版本 Flutter 3.19 和 Dart 3.3 中看到朝著這個願景的進展。

這些版本重點關注完善和效能改進，這些改進建立在 Flutter 和 Dart 去年 [設定的軌跡](https://medium.com/flutter/whats-next-for-flutter-b94ce089f49c) 之上。在此 Flutter 版本中，您將發現：

• 對我們透過持續在 Impeller 上的工作來生成突破性圖形效能的努力進行更新。
• 透過 Flutter iOS 原生字體和深層連結網頁驗證器的早期版本，朝向提供平台之間的無縫整合邁出更多步驟。
• 持續關注開發人員體驗，包括對 DevTools 的更新和 [Flutter 套件生態系統進展報告](https://medium.com/flutter/progress-of-the-flutter-package-ecosystem-17cded9a0703?source=collection_home---4------1-----------------------)。
• 最後，我們很高興分享我們在幫助定義 Web 未來的 Wasm 任務上的進展。

反過來，Dart 3.3 引入了擴展類型，一種與 Web 上的 JavaScript 互動的新模型，並且更新了我們對支援存取更多、更好的 Web 函式庫的工作。您可以在 [Flutter 3.19](https://medium.com/flutter/whats-new-in-flutter-3-19-58b1aae242d2) 和 [Dart 3.3](https://medium.com/dartlang/dart-3-3-325bf2bf6c13) 的部落格文章中分別了解更多關於每個版本的資訊。

2024 年策略與路線圖

這些功能中的每一個都是我們今年正在進行的一個更大旅程中的小小一步，您可以在我們的 [2024 年路線圖](https://github.com/flutter/flutter/wiki/Roadmap) 中看到。與往常一樣，這些路線圖源於我們希望公開我們的計劃的願望，因為我們知道你們中的許多人將 Flutter 和 Dart 視為職業和業務中必不可少的組成部分。話雖如此，即使制定了計劃，進展也很難預測。

雖然我們將盡最大努力繼續保持透明度，因為不可避免的變化會迫使我們轉移重點並做出取捨，但我們想強調，在 Google 之外，Flutter 和 Dart 的貢獻者比我們在這裡工作的員工還要多，這意味著我們的路線圖中提到的內容僅僅是今年 Dart 和 Flutter 將發生的數千次變更中的一小部分。

將所有內容整合在一起

我在 Google 和 YouTube 的 17 年多的時間裡參與過許多有趣且創新的專案，但這是對新的機會感到最熱情的時刻。我從軟體工程師開始我的職業生涯，我在 Google 的第一份工作是地圖 API 和地理開發者工具的產品經理，因此能夠回到我的開發人員根源真是太好了。

推動我熱情的一部分是，嗯，您的熱情。僅僅在 2024 年，我看到了這個社群取得了如此令人驚嘆的成就，包括：

• 超過 2,700 位開發人員加入了我們的 [全球遊戲挑戰](http://flutter.dev/global-gamers)，這是我們與國際倡導機構 Global Citizen 合作舉辦的，旨在挑戰您利用自己的技能構建 Flutter 遊戲，激勵世界以更可持續的方式生活。
• [Superlist](https://youtu.be/37qvcjmE51w)，在昨天宣布了 1.0 版本，正在使用 Flutter 重塑任務管理、筆記記錄以及介於兩者之間的一切。

最後，我的孩子們正在學習電腦科學，我致力於幫助創造軟體開發體驗，幫助下一代為更美好的世界做出改變。

今年對於創造這樣的未來來說至關重要，我迫不及待地想看看 Flutter 和 Dart 如何支援它。與往常一樣，我們非常感謝您持續的支持，我們迫不及待地想看看我們將共同創造的成果。下次再見！

強勢開啓 2024：Flutter 和 Dart 的新篇章 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

分享 Flutter 2024 年的路線圖

作為一個擁有蓬勃發展的社群的開源專案，我們致力於對我們的計畫保持透明，從問題到設計規格，所有內容都在公開場合分享。我們聽到了許多人對 Flutter 功能路線圖的興趣。這些路線圖在可預測性方面可能會很困難，因為這些計畫往往會在全年調整和適應，但我們仍然認為分享我們的整體計畫很重要，並帶有以下聲明：計畫可能會改變。

我們一直在發佈我們的路線圖，從 2020 年開始，而今天我們將分享我們的 2024 年路線圖。這是對前幾年工作的自然延續，我們仍然致力於我們的長期目標，即打造 *最受歡迎、成長最迅速、生產力最高的跨平台 UI 架構，用於建立豐富的應用程式體驗*。

請注意，我們在此列出的内容主要來自那些作為 Google 員工在 Flutter 上工作的我們。到目前為止，非 Google 貢獻者的數量已超過 Google 員工，因此這並不是我們希望今年在 Flutter 中出現的所有新事物和令人興奮事物的詳盡清單！

我們對社群和您的持續支持表示衷心的感謝。我們迫不及待地想看看您將建立什麼！

分享 Flutter 的 2024 年路線圖 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

Dart 3.3 來了，帶來效能和跨平台開發的重大變革！

Dart 3.3 已經推出，它將徹底改變效能和跨平台開發！ 準備好使用 擴展類型 為您的應用程式增強能量，徹底改變效能優化，以及您與原生程式碼互動的方式。此外，我們改版後的 JavaScript 互操作 模型引入了強大的類型安全性，以及一種開發人員友好的方式來利用 Web 平台的強大功能。所有這些都為 WebAssembly 支援鋪平了道路。哦，還有 在您的 Dart 應用程式中使用 Google AI？當然可以！這一切都在 Dart 3.3 中。讓我們深入了解！

介紹擴展類型

擴展類型為類型引入了零成本封裝。使用它們來優化效能敏感的程式碼，特別是在與主機平台進行互操作時。擴展類型提供了自訂類型的便利性，這些自訂類型具有特定的成員，同時消除了典型的封裝分配開銷。

1
2
3
4
5
6
7
8
9
10

extension type Wrapper(int i) {
  void showValue() {
    print('my value is $i');
  }
}

void main() {
  final wrapper = Wrapper(42);
  wrapper.showValue(); // Prints 'my value is 42'
}

以上範例將 Wrapper 定義為擴展類型，但將其用於像一個簡單的 Dart 類型。您可以實例化它並呼叫函數。Dart 將其編譯為一個正常的 Dart int，這才是關鍵的差別。擴展類型允許您在不產生分配典型封裝類型的間接成本的情況下，建立一個具有獨特成員的類型。因此，雖然 擴展成員 功能（自 Dart 2.7 以來可用）允許您為現有類型新增函數和屬性，但擴展類型功能可以做同樣的事情，而且還可以 定義一個隱藏底層表示的新 API。

這對於與主機平台的互操作性特別有用。原生類型可以直接使用，而無需建立封裝器和相關的間接成本，同時仍然提供乾淨的生產 Dart API。在 新的擴展類型文件 中了解更多資訊。

改進 JavaScript 互操作

Dart 3.3 引入了一個新的模型，用於與 JavaScript 函式庫和 Web 進行互操作。它從一組與 JavaScript 互動的新 API 開始：dart:js_interop 函式庫。現在 Dart 開發人員可以使用類型化的 API 與 JavaScript 進行交互。此 API 清晰地定義了兩種語言之間的界限，並進行了靜態強制。這消除了 在 編譯時間之前的一整類問題。除了存取 JavaScript 程式碼的新 API 之外，Dart 現在還包括一個使用擴展類型在 Dart 中表示 JavaScript 類型的模型。

1
2
3
4
5
6
7
8
9

import 'dart:js_interop';

/// Represents the `console` browser API.
extension type MyConsole(JSObject _) implements JSObject {
  external void log(JSAny? value);
  external void debug(JSAny? value);
  external void info(JSAny? value);
  external void warn(JSAny? value);
}

基於擴展類型的語法允許比擴展成員更具表現力和健全性。這簡化了從 Dart 利用 JavaScript API。在 新的 JS 互操作文件 中了解更多資訊。

改進瀏覽器函式庫

自 1.0 版本以來，Dart SDK 已包含一組全面的瀏覽器函式庫。其中包括核心 dart:html 函式庫，以及用於 SVG、WebGL 和其他功能的函式庫。

改進的 JavaScript 互操作模型提供了重新構想這些函式庫的機會。展望未來，我們的瀏覽器函式庫支援將專注於 package:web。這簡化了版本控制，加速了更新，並與 MDN 資源保持一致。

這條改進鏈引導我們走向下一件大事：將 Dart 編譯為 WebAssembly。

立即開始，為 WebAssembly 的未來做好準備

有了 Dart 3.3，套件和應用程式作者可以為編譯為 WebAssembly 的 Web 應用程式奠定基礎。雖然 Flutter Web 中的 WebAssembly 支援仍然是實驗性的，但團隊正在努力穩定實作。若要使用 WebAssembly 在 Web 上運行 Flutter 應用程式，您需要遷移所有程式碼——從應用程式和所有相依項——以使用新的 JavaScript 互操作機制和 package:web。傳統的 JavaScript 和瀏覽器函式庫保持不變，並支援編譯為 JavaScript 程式碼。但是，編譯為 WebAssembly 需要遷移。

我們創建了一個 遷移指南 來幫助作者開始包含 Wasm。我們希望在將其納入穩定版本時，最受歡迎的套件都支援 Wasm。

另外一件事：介紹 Google AI Dart SDK

Google 已將 Google AI Dart SDK 發佈到測試版。您可以將生成式 AI 功能構建到您的 Dart 或 Flutter 應用程式中。這些應用程式使用 Gemini，這是 Google 最新一代的 AI 模型。查看 package:google_generative_ai。在 這篇部落格文章 中了解如何使用 Google AI Dart SDK 進行構建，或者直接跳到 快速入門。

Dart 3.3 的新功能：擴展類型、JavaScript 互操作等等 最初發佈在 Dart 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

undefined

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

介紹 Google AI Dart SDK

我們很興奮地宣布推出 Google AI Dart SDK，用於 Gemini API。新的 pub.dev 套件，google_generative_ai，以及 支援資源 讓您可以透過與 Gemini API 的慣用 Dart 整合，將您自己的基於生成式 AI 的功能建立到 Dart 和 Flutter 應用程式中。它為從單一程式碼庫為 Android、iOS、網頁、macOS、Windows 和 Linux 建立智慧、高效能的應用程式開闢了廣泛的可能性。

使用 Google AI Dart SDK，您可以：

• 輕鬆整合生成式 AI 功能：透過最少的設定，將進階文字生成、摘要、聊天等功能添加到您的 Dart 或 Flutter 應用程式中。
• 利用 Google 目前最具能力和通用性的模型：Gemini 模型汲取了 Google 在機器學習方面的廣泛研究和開發成果，讓您可以使用持續改進的生成式 AI 功能。
• 加速您的 AI 驅動應用程式開發：專注於您的應用程式邏輯和使用者體驗，而 SDK 則處理與 AI 模型互動的複雜細節。
• 建立跨平台的 AI 驅動應用程式：使用 Flutter，輕鬆地在桌面、網頁和行動應用程式中建立生成式 AI 功能。
• 在 180 多個國家和地區使用 Gemini API：查看 可用區域 以獲取 Gemini API 和 Google AI Studio（以下將進一步說明）目前可用的國家和地區清單。

您可以建立什麼？

我們相信生成式 AI 具有巨大潛力，可以幫助您實現應用程式和業務目標。由於 Gemini 模型是多模態的（它能夠處理來自多種方式的資訊，包括圖片和文字），因此它讓您發揮極大的創造力。然而，我們經常從應用程式開發人員那裡（甚至從我們自己的團隊內部）得到的第一个問題是「我實際上可以使用 Gemini API 做些什麼？」以下是一些您可能為您的 Dart 或 Flutter 應用程式建立的功能範例：

• 文字摘要：從文字輸入中生成長文章、研究論文或網站內容的簡潔摘要。
• 智慧聊天機器人：建立更具吸引力且更像人類的對話介面，增強您的應用程式中的使用者體驗。
• 視覺搜尋引擎：使用者可以上傳圖片，應用程式使用 Gemini API 傳回圖片中內容、樣式，甚至如何製作圖片中內容的描述。
• 為無障礙使用生成圖片描述：生成上傳圖片的詳細文字描述，以幫助視障使用者。
• 圖表和圖表解析：使用者可以上傳圖表、圖表或圖形的圖片，Gemini API 可以提供資料的文字分析和說明。

這個清單可以一直列下去，因為可能性幾乎是無限的！

入門

查看 Dart 快速入門 以獲取有關如何建立設定的詳細分步指南。總體而言，以下是您將執行的操作：

1. 從 Google AI Studio 獲取 Gemini API 金鑰。確保此金鑰安全。我們強烈建議您不要將金鑰直接包含在您的程式碼中，也不要將包含金鑰的文件检入版本控制系統。在開發過程中，我們建議使用 flutter run -d [DEVICE NAME] — dart-define=API_KEY=[YOUR API KEY] 在模擬器/模擬器中運行應用程式，使用您的 API 金鑰作為環境變數。
2. 透過分別運行 dart pub add google_generative_ai 或 flutter pub add google_generative_ai，將 Google AI Dart SDK 添加到您的 Dart 或 Flutter 應用程式中。這會將 google_generative_ai 添加為 pubspec.yaml 檔案中的相依性。
3. 在您的程式碼中初始化生成式模型：

1
2
3
4
5
6
7
8
9
10

import 'package:google_generative_ai/google_generative_ai.dart';

// 將您的 API 金鑰作為環境變數存取（見上述第一步）
final apiKey = Platform.environment['API_KEY'];
if (apiKey == null) {
  print('No $API_KEY environment variable');
  exit(1);
}

final model = GenerativeModel(model: 'MODEL_NAME', apiKey: apiKey);

4. 現在您可以開始探索使用 Gemini API 實作不同的用例。例如，當提示輸入包含文字和圖片時，使用 gemini-pro-vision 模型和 generateContent 方法，以生成文字輸出：

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

import 'dart:io';

import 'package:google_generative_ai/google_generative_ai.dart';

void main() async {
  // 將您的 API 金鑰作為環境變數存取（見上述第一步）
  final apiKey = Platform.environment['API_KEY'];
  if (apiKey == null) {
    print('No $API_KEY environment variable');
    exit(1);
  }
  // 對於文字和圖片輸入（多模態），使用 gemini-pro-vision 模型
  final model = GenerativeModel(model: 'gemini-pro-vision', apiKey: apiKey);
  final (firstImage, secondImage) = await (
    File('image0.jpg').readAsBytes(),
    File('image1.jpg').readAsBytes()
  ).wait;
  final prompt = TextPart("What's different between these pictures?");
  final imageParts = [
    DataPart('image/jpeg', firstImage),
    DataPart('image/jpeg', secondImage),
  ];
  final response = await model.generateContent([
    Content.multi([prompt, ...imageParts])
  ]);
  print(response.text);
}

探索 Gemini API 文檔，並查看 GitHub 儲存庫中的 Dart 和 Flutter 範例應用程式，以獲取有關如何為各種用例使用 SDK 的詳細指南和範例，或者在 DartPad 中的此範例應用程式 中查看，DartPad 是用於 Dart 和 Flutter 片段的免費開源線上編輯器，現在使用 Flutter 建立。請在 generative-ai-dart GitHub 儲存庫 中報告任何問題，或告訴我們有關功能要求。

Google AI Studio

除了 SDK 之外，Google AI Studio 是一個基於瀏覽器的 IDE，用於使用生成式模型進行原型設計。它讓您可以快速迭代以開發用例的提示，然後獲取 API 金鑰以在您的應用程式開發中使用。您可以使用您的 Google 帳戶登入 Google AI Studio，並利用免費配額，允許每分鐘 60 次請求。為了幫助我們提高產品品質，當您使用免費配額時，您的 Google AI Studio 輸入和輸出可能會被訓練有素的審閱者存取。這些資料會與您的 Google 帳戶和 API 金鑰脱钩。

我們將很快將 Dart 添加到 Google AI Studio，請密切關注我們的公告！這將讓您可以簡單地點擊「取得程式碼」，選擇新的 Dart 標籤（它將與現有支援的語言並列），然後「複製」Dart 程式碼以將您的工作傳輸到您選擇的 IDE。

分享您的成果！

我們期待看到您使用 Gemini 建立的成果，例如 LeanCode 團隊使用 Gemini API 建立的 arb_translate。它是一個套件，可以幫助開發人員自動執行語言翻譯，簡化 Flutter 應用程式中的本地化。

在 Twitter/X 上使用標籤 #BuildWithGemini 告訴我們您正在建立什麼！

在您的 Dart 和 Flutter 應用程式中利用 Gemini API 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

Flutter極致UI適應性：Google Earth如何支援地球上所有用例

當Google Earth準備以Flutter重寫其行動和網頁客戶端時，他們知道他們希望讓所有使用者都能以他們喜歡的方式探索地球，無論他們使用的是哪種設備。這在一定程度上一直是他們的目標；畢竟Google Earth已經擁有現有的網頁、桌面、Android和iOS客戶端。但這次重寫，將涵蓋除了桌面之外的所有目標，需要支援現有用例的超集；再加上Earth團隊渴望探索的一些新的適應性想法。

Google Earth未來技術堆栈的搜尋，受到了他們現有客戶端發展速度緩慢的摩擦來源的嚴重影響。也就是說，Google Earth很早就被迫在開發新功能的速度，以及在三個獨特的程式碼庫（網頁、Android和iOS）中維持功能一致性之間做出選擇。幸運的是，UI的中心——螢幕中央的整個淡藍色點——是由一個C++引擎驅動的，該引擎已經為Google Earth的一些功能提供了統一的體驗。然而，其餘的UI邊框和選單是在每個程式碼庫中單獨實現的。這意味著任何跨平台的選擇，不僅需要徹底改革UI開發流程，還需要與Android、iOS和網頁中的一個大型遺留引擎整合。

選擇使用Flutter的決定因素是雙重的。首先，使用方法通道與現有的Google Earth引擎整合證明是一項簡單的任務。其次，Google Earth不僅希望簡化他們的程式碼庫，還希望徹底重新設計他們的UI。任何重大的UI改版本身就是一種重寫，Google Earth選擇寫一個新的Flutter應用程式，而不是對三個現有應用程式進行手術。這使任務更加複雜，但團隊承諾要徹底改變，並專注於適應性。最後，Google Earth團隊使用Flutter來為三個平台提供UI。

定義適應性

於是，Google Earth團隊踏上了一段旅程，致力於突破UI適應性的極限。在創造符合不同使用者流程的UI方面，先前的經驗比比皆是——回溯到智慧型手機的黎明時期，以及整個網路集體意識到大多數網站都需要針對小螢幕重新設計。瀏覽器API和CSS模式出現了，以構建能夠感知螢幕解析度的網站；這些想法從那以後一直很突出。甚至在Flutter的最早期，開發人員都知道手機螢幕會有所不同，並讓他們應用程式的UI依賴於螢幕的解析度。如果解析度發生變化——無論是使用者旋轉手機還是調整瀏覽器視窗的大小，應用程式的UI都會做出反應。在Flutter中，就像在它之前的網頁中一樣，響應式UI 改善了使用者體驗。

那麼，您可能會好奇，響應式UI和適應性UI之間有什麼區別？簡而言之，響應式UI會根據可用像素的數量和長寬比調整；而適應性UI則會根據所有其他因素進行調整。響應式UI可以根據螢幕空間詳細資訊調整個別UI元素的大小，但適應性UI會回答更根本的問題，例如在哪裡渲染應用程式的導航、列表視圖是否應該導航到單獨的詳細視圖，還是與列表本身並排顯示，以及使用者連接的周邊設備如何影響點擊目標和懸停狀態等因素（稍後將詳細介紹此概念）。

若要進一步了解，請觀看 [Decoding Flutter 的第 15 集](https://youtu.be/HD5gYnspYzk?si=8AvuBRGXNRNET9dR) 關於適應性與響應式UI，並查看來自 [Flutter](https://docs.flutter.dev/ui/layout/responsive/building-adaptive-apps) 和 [Android 文件](https://developer.android.com/develop/ui/views/layout/responsive-adaptive-design-with-views)的這些指南。

任何曾經為網站撰寫響應式CSS的人都會告訴您，即使是最簡單的UI也可能帶有棘手的邊緣情況。明確地說，這不是CSS的錯；問題空間的許多狀態都非常細緻，幾乎感覺像模擬的。那麼，在考慮幾個額外的變數（例如設備形式因素和連接的周邊設備）時，UI開發人員應該期待什麼？當然，他們應該期待複雜性適當增加。

當一個早期原型表現出意外的行為時，這一切就都集中起來了。在玩那個早期版本時，一位Google Earth工程師將他們的桌面網頁瀏覽器縮小到一個非常窄的寬度。突然之間，常見的桌面功能（例如側邊導航欄和較小的點擊目標）被行動功能所取代，例如底部導航欄和更大、更適合手指的按鈕。他們的驚訝是短暫的——畢竟，這正是他們告訴他們的應用程式要做的。Google Earth團隊現在面臨一個深刻的問題——這是一個使用者想要的嗎？

這正是Google Earth團隊即將探索的未知領域。

為什麼要適應性？

對某些人來說，以下內容提出了一個元問題：為什麼要費盡心思做這些事情？當響應式UI肯定能滿足大多數使用者時，投資報酬率是否足夠？

這些都是好問題，但它們不應該導致對Flutter猶豫不決。使用像Flutter這樣的跨平台UI框架並不會引入適應性UI問題；它解鎖了適應性UI解決方案。除此之外，以下兩個因素表明適應性UI確實非常重要：

• 螢幕解析度不再像以前那樣有意義。桌面瀏覽器可能具有低DPI設定，而基本的斷點檢查會將其與行動環境混淆；橫向模式下的高DPI手機可能會被誤認為是舊的平板電腦（甚至桌面！）斷點；而可摺疊設備可以交替顯示您的應用程式全螢幕，以及在多個應用程式之間分割螢幕空間，如果這導致使用者在某些斷點之間來回切換，就會導致令人不快的差異。
• 帶有明顯創建與使用模式的應用程式（想想任何具有閱讀和編輯體驗的文字編寫應用程式）在行動裝置上可能會嚴重受到影響——特別是在平板電腦上。將以行動裝置為中心的體驗（可能以使用為中心）發佈到智慧型手機和平板電腦上，極大地限制了具有平板電腦、藍牙鍵盤和滑鼠的強大使用者。

實現適應性

Google Earth團隊經歷了漫長的實驗、使用者研究和迭代過程，才完成了最終發佈的應用程式。但最終，他們的問題空間歸結為三個高級問題：

1. 應用程式如何確定其初始UI策略？
2. 應用程式如何以及何時應更改其UI策略？
3. Google Earth團隊如何清晰地實作此邏輯？

確定初始UI策略

Earth團隊的早期假設之一是「具有觸控螢幕的Chromebook與具有連接藍牙鍵盤的平板電腦之間沒有區別」，並且他們的UI不應該區分這兩種設備。雖然這個想法最初是有道理的，但它在測試中沒有存活下來；隨著時間的推移，Earth團隊越來越意識到這種方法的不足之處。以橫向模式啟動應用程式的使用者，可能會發現自己處於桌面UI的像素解析度範圍內（遵循舊的響應式UI規則）。如果同一位使用者隨後將他們的平板電腦旋轉成縱向模式，並因此轉移到分配給平板電腦的像素解析度範圍，Google Earth將面臨一個艱難的選擇。動態選項將是透過從桌面UI轉換到行動UI來大幅重組所有內容；而靜態選項將是除了將桌面UI壓縮和壓縮，直到它適合新的約束條件之外，什麼都不做。這兩種選項都不令人滿意，這意味著具有觸控螢幕的Chromebook和具有鍵盤的平板電腦之間確實有差異。

最終，Earth團隊設定了一個簡單的規則：為智慧型手機和平板電腦提供行動體驗，為桌面提供桌面體驗。如果這看起來很平淡無奇，那麼，它確實是；但這僅僅是因為它將一些有趣的部分推遲到了下一個問題——UI的初始策略何時應該 更改？

在使用者會話中更新UI策略

Earth團隊的UI更改的第一個策略，僅僅是已建立的響應式UI規則：在任何低於最低門檻值的解析度上顯示您的行動UI，在接下來的幾百種可能的寬度上顯示您的平板UI（如果您有），最後，在任何其他解析度上顯示您的桌面UI。而且，至關重要的是，當UI由於任何原因跨越了其中一個門檻值時，您會相應地重新渲染應用程式。當然，這個規則集的笨拙讓Google Earth開始了它的極致適應性之旅；因此，團隊放棄這種方法也就不足為奇了。

第二種可能性來自Stadia，一個具有成功的Flutter行動應用程式的Google團隊。（顯然，Stadia作為一種產品沒有存活下來；但这并非因为其行動應用程式缺乏功能！）Stadia的方法是根據最後觸摸的輸入來做出適應性UI決定。拖動電腦游標或按下鍵盤，Stadia就會切換到桌面UI模式。相反，如果您傾斜連接的主機控制器上的搖桿，Stadia就會切換到主機UI模式。但是，雖然這對Stadia來說有道理，但它被證明對Google Earth來說不太合適。一個簡單的案例排除了這種最後觸摸輸入策略：一個平板電腦使用者縮放地圖，然後回到藍牙鍵盤完成輸入內容。沒有使用者會希望在這種簡單的互動過程中發生兩次劇烈的UI轉換，因此使用者的最新輸入不能將Google Earth的UI從行動裝置切換到桌面或反之。

最終，Google Earth團隊設定了第二個非常簡單的規則：在一個會話中保持一致，並且在沒有使用者明確許可的情況下，絕不離開初始UI風格。如前所述，Google Earth會在智慧型手機和平板電腦上顯示其以行動裝置為中心的UI，在桌面電腦上顯示其以桌面為中心的UI；並且它絕不會自作聰明地更改此設定，除非使用者在設定面板中請求更改。

混合式UI狀態

在會話中保持UI一致對Google Earth很有幫助，但這並不是全部。桌面體驗中的UI功能（例如游標懸停效果）在行動裝置上沒有任何對應部分，必須重新設計。將觸控螢幕筆電當作平板電腦使用的使用者，可能會因應用程式未能將重要的懸停效果替換為適合行動裝置的替代方案而完全被阻擋。這種認識表明了一個兩層次的問題和解決方案。Google Earth的UI不僅需要在使用者請求時在行動和桌面體驗之間平滑地切換，而且個別控制項需要同時具有觸控友好的形式和滑鼠友好的形式，無論整體策略如何。

最後，Google Earth知道他們在建立什麼。他們的所有研究和迭代只留下實作問題，這些問題歸結為：

1. 如何管理兩個根本不同的UI之間的轉換，以及
2. 如何建立支援非典型周邊設備的個別控制項

管理多個UI

簡單來說，建立任何可以在兩個不同體驗之間無縫切換的Flutter應用程式，就像在Widget的build方法中的某處放置以下程式碼一樣簡單：

1

child: mode == Mode.desktop ? DesktopUI() : MobileUI()

但是，這種策略（Google Earth使用的策略）意味著在其他地方需要做一些額外的工作才能完全實現。問題——最初是隱藏的——當任何應用程式狀態儲存在Stateful Widget中時就會浮出水面，因為切換mode變數會完全替換Widget樹，破壞所有狀態物件及其所持有的任何資訊。這個問題分為兩個層次。

要想像第一層，請考慮一個在桌面電腦上有多個面板的螢幕，但在行動裝置上將這些面板重新組織成一個標籤欄體驗。行動裝置使用者將有一個活動標籤，但這個概念在桌面電腦上沒有對應部分。將活動標籤索引儲存在StatefulWidget中（這是Flutter中的慣用方式！），會在透過桌面UI來回切換後，始終將行動裝置使用者的位置重置為預設標籤。解決這個問題的方法是將任何原始應用程式狀態——字串、整數等等——從StatefulWidget中移到您的狀態管理類別中。這樣一來，Widget樹中的任何惡作劇都不能重置關鍵的數值。

問題的第二層來自應用程式狀態，這些狀態很難從Widget樹中提取出來，例如TextEditingController或ScrollController。情況看起來像這樣：您有一個帶有TextField的ListTile，但每次使用者觸摸他們的滑鼠或觸控螢幕時，您都會重新建立該ListTile以適應使用者的最新周邊設備。如果沒有干預，這會導致Flutter破壞包含舊TextField的Widget和Element樹的整個部分，並將任何持有使用者工作的控制器一起帶走。您可能會想將這些視為原始資料（TextEditingController作為字串和ScrollController作為雙精度數），並重複上述解決方案；但控制器太豐富了，無法以這種方式輕鬆序列化（游標位置和文字選擇，誰知道呢？）。

為了解決這個問題，Google Earth使用GlobalKeys來讓框架在重新佈局後「重新為高度限定範圍的Widget指定父元素」。下面的AdaptableTextInput Widget嚴格限定在它的TextField和TextEditingController中。在UI更改重新建立過程中為AdaptableTextInput Widget提供相同的GlobalKey，將使TextEditingController保持有效，從而儲存使用者的工作。

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

class AdaptableTextInput extends StatefulWidget {

  // 在這裡提供一個一致的 GlobalKey！
  const AdaptableTextInput({super.key, required this.mode});

  final Mode mode;

  @override
  State<AdaptableTextInput> createState() => _AdaptableTextInputState();
}

class _AdaptableTextInputState extends State<AdaptableTextInput> {

  final _controller = TextEditingController();
  final String helpText = '我說明這個文字輸入！';

  @override
  Widget build(BuildContext context) {
    if (widget.mode == Mode.desktop) {
      return Tooltip(
        showOnHover: helpText,
        child: TextField(controller: _controller),
      );
    } else if (widget.mode == Mode.mobile) {
      return Column(
        children: <Widget>[
          TextField(controller: _controller),
          Text(helpText);
        ],
      );
    } 
  }
}

導航

導航堆栈和應用程式的返回按鈕也需要特別注意。繼續以上面的桌面UI的例子來說，該UI一次顯示多個面板，現在想像一個互補的行動UI，它以堆栈式UI呈現這些面板，並具有向前和向後導航。允許桌面使用行動UI，以及手機使用桌面UI，是Google Earth想要追求的重要適應性理念之一。

如果桌面UI使用者在切換到行動UI時位於紅色面板上，返回按鈕將不會自動連接，因為導航堆栈將被重置。這意味著您的桌面UI需要考慮額外的技術資訊，這些資訊僅供行動UI使用，因為行動UI隨時可能被要求接管。

幸運的是，GoRouter 的宣告式路由 API 可以提供幫助。建立兩個單獨的路由宣告，並在使用者切換UI模式時切換到適當的路由。在這種情況下，如果桌面UI在收到啟動行動UI的請求時，已將使用者的最後活動追蹤到紅色面板，則呼叫mobileRouter.go('home/blue/red')將建立一個帶有合成歷史的導航堆栈，允許使用者按下返回按鈕退出紅色螢幕。

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

final desktopRouter = GoRouter(
  routes: [
    GoRoute(
      path: '/home',
      builder: (context, state) => FourPanels(),
    ),
  ],
);

final mobileRouter = GoRouter(
  routes: [
    // 每个面板一个路由，配置为连接返回按钮
    // 如果用户到达其中一个嵌  入面板
    GoRoute(
      path: '/home/blue',
      builder: (context, state) => BluePanel(),
      routes: [
        GoRoute(
          path: 'red',
          builder: (context, state) => RedPanel(),
          routes: [
            GoRoute(
              path: 'green',
              builder: (context, state) => GreenPanel(),
              routes: [
                GoRoute(
                  path: 'yellow',
                  builder: (context, state) => YellowPanel(),
                ),
              ],
            ),
          ],
        ),
      ],
    ),
  ],
);

像Google Earth這樣的適應性很強的UI需要一種實作，將所有可能的情況視為始終處於活動狀態，即使只渲染了特定的UI。這意味著應用程式必須始終能夠從您完全控制的資源中完全重建其狀態——無論是您是否有GlobalKeys來保留持有重要資訊的狀態物件，還是您已將所有相關詳細資訊儲存在狀態管理類別中。

適應使用者輸入

這只留下了一個棘手的適應性問題：確保UI中的控制項能够适应使用者的最后使用的外围设备，而不仅仅是当前有效的UI策略。毕竟，如果一个平板电脑用户开始点击蓝牙鼠标; Google Earth不会将UI整体切换到桌面模式，但他们确实想要稍微调整一些元素，以利用键盘和鼠标的优势。

仅仅使用Flutter意味着Google Earth在这方面已经取得了良好的开端。想象一下另一种情况：一个应用程序跨越三个代码库（JavaScript用于通过网页访问桌面，Swift和Kotlin用于移动设备），当Swift和Kotlin团队意识到如果在某些情况下，他们可以从JavaScript应用程序的UI中借用元素，那就太好了。也许他们需要的可以被简单地重新实现; 也许不行。无论哪种方式; 在一个Flutter应用程序中，您想要借用的现有工具始终位于同一个代码库中。

但是代码共享不是代码组织，如何连贯地实现这个问题仍然存在。在这里，Google Earth团队转向了一个老的Flutter主打工具：构建器模式。

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

/// 用户输入的高级类别。
enum InputType { gamepad, keyboardAndMouse, touch }

/// 构建一个依赖于用户当前[InputType]的widget树。
class InputTypeBuilder extends StatelessWidget {
  /// 当[InputType]数据更新时调用。
  final Function(BuildContext, InputTypeModel, Widget?) builder;

  /// 构建一个包装widget，只要[InputType]
  /// 改变就会调用[builder]。
  ///
  /// 有关如何更改[InputType]的详细信息，请参见[InputTypeModel]。
  const InputTypeBuilder({
    Key? key,
    required this.builder,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Consumer<InputTypeModel>(
      builder: (context, inputTypeModel, _) {
        return builder(
          context,
          inputTypeModel.inputType,
        );
      },
    );
  }
}

像InputTypeBuilder这样的Widget会监听一个顶层机制，即InputTypeModel，它本身会订阅Flutter引擎以接收有关最后使用的输入的更新。InputTypeModel.inputType是InputType枚举的属性。有了它，子Widget就可以根据用户当前与应用程序的交互方式做出本地化决策，决定如何渲染自身。例如，如果您一直在使用鼠标，但随后用手指点击了触摸屏，以前只有在鼠标悬停时才会出现的可视提示现在会在整个应用程序中显示。同样地，如果您切换回使用鼠标，这个InputTypeBuilder将允许他们撤销更改。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@override
Widget build(BuildContext context) {
  return InputTypeBuilder(
    builder: (context, inputTypeModel, child) {
      final bool isHoveredOrTouchInput = isHovered || inputTypeModel.inputType == InputType.touch;
      return Row(
        children: <Widget>[
          isHoveredOrTouchInput ? DragIndicator() : Container(),
          RestOfRow(),
        ],
      );
    },
  );
}

以下GIF显示了Google Earth 的桌面UI（在Chrome中运行），巧妙地适应了用户在触摸屏和鼠标操作之间切换的操作。

结论

使用Flutter重新构建Google Earth带来的最大的意外收获，来自平板电脑和网页等中间环境的使用者。这些设备夹在手机和平板电脑之间，可以在物理上支持两种类型的体验，但很少享有与之匹配的软件灵活性。同样地，网页体验可以在任何设备上加载；在桌面电脑上，浏览器可以任意调整大小。根据应用程序的不同，所有这些都可能意味着截然不同的UI。对于大多数将每个构建目标的代码库分开的开发团队来说，完全支持身处这些中间状态的使用者是不可能的。（想象一下说服你的老板花时间在行动装置上重建你的整个桌面UI，仅仅因为平板电脑使用者想要它！）

但是，正如Google Earth团队所发现的，虽然在一个代码库中构建完全適應性的 UI确实意味着額外的複雜性，但它被满足所有使用者需求所獲得的使用者體驗改進所抵消。

您今天就可以嘗試Google Earth的新Flutter實作，方法是在Android或iOS上下载應用程式，或访问 https://earth.google.com。

Flutter極致UI適應性：Google Earth如何支援地球上所有用例 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

Flutter 和 Dart 套件生態系統的進展

Flutter 和 Dart 套件生態系統仍然是開發人員從單一程式碼庫為任何螢幕構建美麗、高效能應用程式的關鍵推動因素。該生態系統在 2023 年成長了 26%，從 1 月份的 38,000 個套件增加到 12 月份的 48,000 個。

截至 2024 年 1 月，Pub.dev 擁有超過 700,000 名月活躍使用者。Flutter 團隊仍然熱衷並致力於支持這種未來發展，並使開發人員能夠使用和貢獻 Flutter 和 Dart。在此更新中，我們將回顧最新的 Flutter Favorites、套件生態系統虛擬峰會的結果，並分享一些值得注意的更新和需要了解的事項。

新的 Flutter Favorites

Flutter Favorites 程式表彰並幫助開發人員發現最高品質的套件，供他們在應用程式中考慮使用。我們很高興宣布七個新的 Flutter Favorite 套件，它們已證明了卓越的品質、人氣和社群參與度，使它們成為 Flutter 開發人員的無價工具。讓我們深入了解每個套件：

1. flame：一個適用於 Flutter 的高性能 2D 遊戲引擎。其直觀的 API 和豐富的功能集使其成為構建視覺上令人驚嘆且引人入勝的遊戲的理想選擇。查看 這個 Codelab 以嘗試使用 flame 構建遊戲。
2. flutter_animate：使用這個強大的動畫函式庫讓您的 UI 動起來，它可以簡化複雜的動畫，並使所有 Flutter 開發人員都能使用它。其宣告式語法和豐富的文檔使建立流暢且富表現力的動畫變得輕而易舉。
3. riverpod：一個優雅的套件，提供一種功能強大且直觀的方法來管理應用程式狀態。其簡化的 API、性能、可擴展性和可測試性使其成為現代 Flutter 應用程式的引人注目的選擇。
4. video_player：對於任何希望在其 Flutter 應用程式中整合影片播放的人來說，這都是必不可少的。它提供了一個 Widget 來顯示影片內容。它支援各種格式和來源，包括網路資源和基於檔案的影片。這使其成為構建富含多媒體的 Flutter 應用程式的多功能工具。
5. macos_ui：對於以 macOS 為目標的開發人員來說，這個套件可以在該平台上創造出設計感覺恰如其分的應用程式。它提供了一套豐富的 Widget 和组件，這些 Widget 和组件的樣式符合 macOS 設計語言，確保您的 Flutter 應用程式不僅在 macOS 上運行良好，而且看起來和感覺都像原生應用程式。
6. fpdart：這個套件在 Dart 中啟用函數式編程。它非常適合實現商業邏輯，例如，在函數式編程範式（如不可變性、純函數和高階函數）以及 fpdart 對 Dart 類型系統的使用方面，它有助於構建更易於維護和可預測的程式碼。
7. flutter_rust_bridge：對於希望在應用程式中利用 Rust 和 Flutter 最佳功能的開發人員來說，flutter_rust_bridge 在兩個世界之間提供了一個無縫的橋樑。它使原生 Rust 程式碼能夠與 Flutter 無縫交互，解鎖 Rust 性能和記憶體安全性在 Flutter 應用程式中的潛力。

終止 Happy Paths 程式

我們決定終止 Happy Paths 程式，以便專注於 Flutter Favorites。Happy Paths 建議的願景是幫助您做出明智的決定，以便找到和使用套件來為您的應用程式添加功能。我們很幸運有像 Flutter Gems 這樣的社群倡議，它們是導航分類良好的套件選項的綜合資源。隨著我們專注於 Flutter Favorites 程式，我們將繼續在 Flutter 和 Dart 社群的意見和回饋的基礎上對其進行改進。

套件生態系統虛擬峰會

在 2023 年 8 月底，我們為 Flutter 和 Dart 套件生態系統舉辦了首次 虛擬峰會，超過 50 位非 Google 和 Google 貢獻者參加了 pub.dev。我們最初的邀請名單相對較小，以適合 unconference-style 的格式，並在弄清楚未來可能呈現的樣子之前，從這次首次活動中學習。目的是將貢獻者聚集在一起，進行 unconference-style 的討論，以便在社群中進行規劃、教育、學習和分享。我們進行了三個討論會，每個討論的主題都是由註冊參加者在峰會開始前的幾週中投票決定的。三個討論主題是：1）構建高品質套件——最佳實踐和挑戰，2）長期維護套件——可持續模式，以及 3）Flutter 和 Dart DevTools 擴展。對活動後調查的回覆為我們提供了寶貴的回饋，我們將在未來的活動規劃中將這些回饋納入其中。謝謝您！總體而言，我們認為這次首次峰會取得了成功。展望未來，我們渴望與社群合作舉辦類似的獨立活動，或者將焦點放在 Flutter 和 Dart 生態系統上的議程，並將其設定在更通用的活動中。

對 Pigeon 套件的更新

Pigeon 套件 是一個程式碼生成工具，它簡化了 Flutter 應用程式與平台特定程式碼之間通信的設定過程。這使得 Pigeon 在以下兩種情況下都很有用：1）在直接撰寫 Flutter 應用程式與平台原生 API 之間的自定義整合時，例如在 add-to-app 情況下，以及 2）在撰寫 Flutter Plugin 以為平台原生 API 提供 Dart API 表面時。它由 Flutter 團隊維護，該團隊在今年對該套件進行了以下值得注意的改進：

• 加入對 Swift、Kotlin 和 C++ 的支援（C++ 解鎖 Windows 支援）。
• 現在強制執行空安全。
• 擴展對原始數據類型支持的支持。例如，枚舉被加入為支援的類型。
• 加入可空參數。
• 在主機和 Flutter API 上加入錯誤處理。
• 改進了工具的人體工程學，使其更易於使用和更直觀。例如，我們加入了對預設參數和命名參數的支持。

在 1 月份的 v5.0.0 和 12 月份的 v15.0.2 之間，還有很多我們無法在此處列出的開發工作，因此請查看 變更日誌 中的所有變更！

DartPad 中的套件

DartPad 支援一組固定的套件，您可以透過點擊螢幕右下角的資訊圖示來查看這些套件。Google 的 Flutter 和 Dart 團隊會持續審查和優先處理套件請求。如果您希望將套件加入到 DartPad，請為 現有套件建議 點擊赞成（如果有），或者 開啟一個新的議題 提出您的建議。

建議在 pub.dev 上使用規範主題

在 2023 年，我們推出了讓套件作者能夠在 pubspec 檔案中使用 1-5 個自由文本主題為其套件加標籤的功能。目標是透過加入一種套件分類方式來改善潛在使用者發現套件的體驗。我們看到這個功能取得了良好的效果，許多套件都進行了標籤化。我們正在探討一個提案，透過合併實際上相同的主题來改進這個功能（例如，widget 和 widgets）。我們邀請社群對此 規範主题議題 分享回饋或貢獻 PR。

目前就這些了！若要與優秀的套件作者社群互動，請查看 Discord 頻道 #package-authors（您首先需要加入 Flutter Discord 伺服器）。

Flutter 套件生態系統的進展 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。