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

原文：https://flutter.dev/blog/ai-makes-it-easy-to-migrate-flutter-makes-it-easy-to-scale

AI 讓遷移變得容易。Flutter 讓擴展變得容易。

為什麼驗證速度，而不是程式碼生成，是代理開發的真正瓶頸，以及單一事實來源如何為多平台擴展提供動力。

過去幾個月，行動工程討論一直圍繞著遷移故事。現在，AI 程式碼工具可以在一個下午內搭建立新原型，工程主管提出了一個公平的問題：

「如果現代 AI 模型可以幾乎即時地生成 Swift 和 Kotlin，為什麼不直接用原生程式碼建立兩次呢？」

在 Google，我們過去一年一直在研究這種動態，跨越我們的內部團隊、企業合作夥伴和更廣泛的開源社群。正如我們今年早些時候在 Dart 和 Flutter 如何思考 2026 年的 AI 中分享的：AI 讓遷移到新框架變得容易。Flutter 讓擴展變得容易。 將第一天的遷移速度與第 2000 天的生產維護混淆，可能會讓工程組織付出多年的速度代價。

以下是統一程式碼庫在 AI 時代比以往任何時候都更重要的第一原理、代理工具和企業數據。

為什麼「寫兩遍」會在大規模上崩潰

要點 1：程式碼庫是累積的記憶（「爭論一次，建立一次」）

當工程團隊在第一天使用 AI 代理重寫應用程式時，模型擅長於初始的順利路徑：語法轉換、REST 端點、UI 佈局和樣板數據模型。從頭開始開發感覺毫不費力，因為它沒有任何歷史。

然而，到了第 2000 天，生產程式碼庫不再僅僅是 UI 語法，而是組織累積的記憶。它包含多年來已解決的產品爭論、生產事後分析、合規規則和邊緣案例修復。正如 Shorebird 的創始人兼 Flutter 共同創作者 Eric Seidel 最近在 AI 時代的可攜式軟體 中所寫：

「應用程式不僅僅是 UI 螢幕的捆綁包。應用程式是意圖交付和意圖捕獲的產物。」

在統一的多平台程式碼庫中，團隊爭論一次並建立一次。當組織要求 AI 用原生 Swift 和 Kotlin「寫兩遍」時，它並沒有消除複雜性；它將其分岔了。 每個新要求和邊緣案例都必須在多個堆疊中獨立浮現、解決和維護。

要點 2：平行代理引入非確定性漂移

在系統工程中，N 個離散介面之間的協調開銷呈組合式增長：

$$ \frac{N(N-1)}{2} $$

一個常見的假設是 AI 代理可以消除這種協調稅：「我們將讓代理 A 撰寫 Swift，代理 B 撰寫 Kotlin。」實際上，每個 LLM 生成都是機率性的。即使使用相同的提示和規範，兩個在不同語言範式中工作的代理也會做出不同的假設：

• 在 iOS 上： 代理 A 使用非同步流實現結帳狀態機，該流會丟棄過時的事件。
• 在 Android 上： 代理 B 使用反應式流實現相同的狀態機，該流會將事件排入佇列。

這兩種實作在第 1 天都通過了本地單元測試。幾週後在生產中，Android 結帳轉換率下降了 3%，例如，因為在間歇性網路中斷期間，重試時機的行為不同。資深工程師必須花費數天（或許多權杖）深入研究兩個不同的技術堆疊才能診斷根本原因。Flutter 從源頭消除了漂移。只有一個狀態機、一個數據序列化層和一個規範的業務邏輯來源。

要點 3：驗證而非生成才是真正的瓶頸

程式碼生成不再是軟體開發的瓶頸，驗證才是。雖然 73% 的開發人員表示使用 AI 開始任務時感覺更有效率，但 46% 的開發人員不信任 AI 在關鍵除錯方面的準確性，除非經過手動檢查。

代理的輸出品質受其回饋迴圈的速度和精確度所限制：

Flutter 旨在為人類開發人員提供即時回饋。正是這種架構使其在高速代理驗證方面獨樹一幟。

建構線束和運行時畫布

Flutter 的宣告式 UI、反應式 Widget 樹、受管理的運行時和有狀態熱重新載入，現在支援兩種不同的 AI 領域：建構時的 AI 輔助開發 和運行時的 生成式 UI。

要點 4：更好的線束勝過更好的提示

在沒有引導的情況下，代理對 Flutter 的了解僅限於其訓練截止日期：通常會使用已棄用的 API，誤讀第三方套件，或在驗證更改之前停止。提示工程無法可靠地解決這個問題；線束工程 可以。

我們在內部透過 Project One Shot 測試了這一點，Flutter 工程師 Reid Baker 和 Camille Simon 指派一名代理程式自主解決 camera_android_camerax 中的生產錯誤，這是我們最複雜的 Plugin 之一，涉及原生 Android CameraX 生命週期和表面紋理綁定。諸如「避免記憶體洩漏」之類的通用指令失敗了。代理程式僅在與確定性線束配對時才成功：透過 MCP 進行 AST 分析、特定套件的領域技能以及強制性的測試驅動防護（透過失敗的測試重現 → 撰寫最小修復 → 通過套件和洩漏檢查器）。

為了讓每個 Flutter 團隊都能擁有相同的線束，我們推出了三項核心功能：

• 官方 Dart 和 Flutter 代理 Plugin： 捆綁我們專用的模型上下文協定 (MCP) 伺服器以及 10 個 Flutter 和 14 個 Dart 技能。它們讓代理程式直接存取 Dart 分析器和 Widget Inspector，以強制執行框架最佳實踐。
• 專業的反重力代理程式： 嵌入式代理程式，可自動審核正在運行的 Flutter 應用程式是否存在輔助功能問題並提交慣用修復。
• 代理技能 CLI： 與我們在 Serverpod 的朋友一起開發，Skills CLI 使套件作者能夠在其套件中提供領域特定的代理技能。運行一個指令即可為代理程式配備庫特定的規則：

1
2

# Scans immediate dependencies and discovers available skills
dart run skills@ get

我們針對實際的評估套件（涵蓋佈局溢出解決、響應式設計、REST API 連線、主題設定和許多其他日常開發人員任務）對線束中的每個工具和技能進行基準測試：

要點 5：生成式 UI 是下一代通用畫布

在執行時，應用程式正從靜態的、預先渲染的畫面演變為即時適應使用者意圖的動態介面。Google 和業界合作夥伴正在 a2ui.org 開發 A2UI（代理到使用者介面），這是一種用於生成式介面的開放標準，為 Flutter 的 GenUI SDK 提供動力。

今年早些時候，我們將此投入生產，推出了 GenLatte，這是一個基於 Flutter、Firebase Functions 和 Genkit 的 AI 原生點餐系統，已實際供應超過 3,000 杯咖啡。其運作方式如下：客戶描述他們喜歡的地方，Gemini 設計自訂的拿鐵藝術，Flutter 的 GenUI 引擎動態水合互動式 UI 控制項，以便使用者可以完善結果。

如果 AI 代理必須在五種不同的作業系統上協商五種不同的原生佈局引擎，它就無法輕鬆地在執行時合成動態介面。然而，Flutter 是 GenUI 的理想基礎，因為它提供了將 UI 串流和渲染到任何地方所需的可移植、宣告式畫布，並且具有完全的一致性。

大規模證明：多表面覆蓋範圍和企業實況

數位產品不再僅限於手機。在 iOS、Android、WebAssembly 網頁、桌面（Windows、macOS、Linux）、車載顯示器和嵌入式資訊亭上維護獨立的原生程式碼庫，會使您的測試矩陣和代幣成本增加六倍。透過 Impeller 提供動力—它預先編譯 Metal、Vulkan 和 OpenGL 的著色器以提供無卡頓的 120fps 渲染—單一 Flutter 程式碼庫可部署到六個或更多目標。

這種架構優勢是全球工程團隊將任務關鍵型生產系統標準化為 Flutter 的原因：

• 小米 (SU7 電動車 & HyperOS 4)： 使用 Flutter 建立了 SU7 電動車配套應用程式，並使用 Flutter 重新編寫了核心 HyperOS 4 系統應用程式（圖庫、啟動器、天氣）的 UI，以及使用 Rust 處理數億部手機的後端邏輯。
• Universal Destinations & Experiences： 統一行動點餐、互動式公園地圖、數位錢包和 Epic Universe 公園資訊亭，將程式碼庫大小減少 45%，且幾乎沒有當機。
• 汽車： 豐田和 Lexus 在 RAV4 等車型中為車載資訊娛樂系統提供動力，而 BMW 則將全球 My BMW 應用程式標準化為 Flutter。
• 金融科技： Nubank 為超過 1 億客戶提供服務，每週部署數百次。

使用者會注意到框架嗎？

在編寫獨立原生應用程式的論點之下，有一個不言而喻的前提：跨平台 UI 會給終端使用者在應用程式商店中注意到的體驗帶來負擔。

為了驗證這項主張，我們審查了從 Apple App Store 和 Google Play Store 中 201,000 個熱門行動應用程式獨立收集的 Apptopia 數據：

使用者不會評估底層框架；他們評估回應能力、視覺精美度和可靠性。

給團隊的 8 個討論點

下次您的組織討論是否要用 AI 維護多個原生程式碼庫時，請將這八個討論點帶入對話中：

接下來會是什麼？

加速在第一天很容易推銷。架構規模是讓您的軟體在第 2000 天保持可靠的關鍵。若要在您的工作流程中開始搭配 Flutter 和 AI：

• 在您的 IDE 中安裝 官方 Dart 和 Flutter 代理 Plugin。
• 查看 Flutter 的 GenUI SDK。
• 在我們的 社群討論 中分享您的團隊如何搭配 Flutter 和 AI。
• 重溫我們在 FlutterCon Berlin 的主題演講。

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

原文：https://dart.dev/blog/announcing-genkit-dart-1-0

宣布 Genkit Dart 1.0：使用 Dart 和 Flutter 建構生產就緒的智能應用程式

發布 Genkit Dart 的穩定 1.0 版本，這是一個用於使用 Dart 建構生產就緒的智能應用程式和 AI 功能的開源框架。

Dart 和 Flutter 讓您可以從單一程式碼庫為行動、網頁和桌面建構高品質的應用程式。藉助 Genkit Dart，您可以將同樣的生產力帶到全端、智能應用程式中。

今天，我們宣布 Genkit Dart 1.0，這是 Google 開源框架的第一個穩定、生產就緒版本，用於使用 Dart 建構 AI 驅動的功能和代理程式。自從我們今年稍早的 預覽發布 以來，來自 Dart 和 Flutter 社群的回饋幫助我們改進了核心 API 並擴展了用於生產工作負載的工具包。

我們已在 Flutter 部落格上發布了 完整的教學和程式碼深入探討。

若要立即開始，請將 genkit 加入您的 Dart 或 Flutter 專案：

1

dart pub add genkit

您還可以安裝代理程式技能，讓 Antigravity、Claude Code 和 Codex 等 AI 程式碼助理具備最新的 Genkit Dart API 知識：

1

npx skills add genkit-ai/skills

Genkit Dart 1.0 的亮點

Genkit Dart 1.0 將統一的模型介面、端到端類型安全和代理程式基本功能帶到任何 Dart 環境中，無論您是建構後端服務、CLI 工具還是全端 Flutter 應用程式：

• 跨模型提供者的一個 API： 在 Google Gemini、Anthropic Claude、OpenAI 和與 OpenAI 相容的模型之間切換，而無需重寫應用程式邏輯。
• 使用 schemantic 實現端到端類型安全： 使用 schemantic 在 Dart 中定義資料模式一次，以生成結構化模型輸出，將 AI 邏輯包裝在可觀察的 流程 中，並在 Dart 伺服器和客戶端之間共享類型。
• 跨客戶端和伺服器的靈活部署： 使用 GenkitRouter 在 Dart 伺服器上運行流程，使用 defineRemoteAction 從客戶端調用它們，或者在將模型請求透過安全後端路由的同時將 AI 邏輯保留在客戶端上，使用 defineRemoteModel。
• 人機互動工具中斷： 當某個動作需要使用者確認時，透過返回 .interrupt(...) 暫停 defineTool 內的工具執行，然後從中斷處恢復生成。
• 可組合的生成中介軟體： 附加來自 genkit_middleware 的預打包中介軟體（包括自動重試、動態 SKILL.md 加載和工具批准規則），或使用 defineGenerateMiddleware 編寫自定義中介軟體。
• 使用 Dotprompt 進行提示管理： 使用 Dotprompt 將提示模板、模型設定和模式儲存在 .prompt 檔案中。
• 本機開發者 UI 和 OpenTelemetry： 使用 genkit start 在本機測試流程並檢查執行追蹤，並使用 genkit_otel 匯出生產追蹤和指標。
• 實驗性有狀態代理程式和 A2UI： 試用多回合持久性代理程式（package:genkit/experimental.dart 中的 defineAgent 和 remoteAgent）並使用 genkit_a2ui 串流互動式原生 UI 介面。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@Schema()
abstract class $TripRequest {
  String get destination;
  int get days;
}
// ...plus an Itinerary schema for the result.
final ai = Genkit(plugins: [googleAI()]);

final planTrip = ai.defineFlow(
  name: 'planTrip',
  inputSchema: TripRequest.$schema,
  outputSchema: Itinerary.$schema,
  fn: (request, _) async {
    final response = await ai.generate(
      model: googleAI.gemini('gemini-flash-latest'),
      prompt: 'Plan a ${request.days}-day trip to ${request.destination}.',
      outputSchema: Itinerary.$schema,
    );
    return response.output!;
  },
);

await (GenkitRouter()..addAction(planTrip)).serve(port: 8080); // POST /planTrip

閱讀完整公告

若要獲取涵蓋多模型生成、遠端動作和模型、工具中斷、中介軟體、Dotprompt、OpenTelemetry、有狀態代理程式以及使用 A2UI 進行生成式 UI 的完整程式碼範例，請閱讀 Flutter 部落格上的 Genkit Dart 1.0 完整公告。

• 開始使用： 遵循 快速入門指南 並查看 pub.dev 上的 genkit。
• 探索範例： 瀏覽 GitHub 上的範例應用程式。
• 加入社群： 在 Discord 上與團隊聊天，並在 genkit-dart GitHub 儲存庫 中開啟議題。

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

原文：https://flutter.dev/blog/announcing-genkit-dart-1-0

宣布 Genkit Dart 1.0：使用 Dart 和 Flutter 建構正式發行的代理應用程式

宣布 Genkit Dart 的穩定 1.0 版本發佈，這是一個用於使用 Dart 和 Flutter 建構由 AI 驅動的功能和代理工作流程的開源框架。

Dart 和 Flutter 讓您可以從單一程式碼庫為行動裝置、網頁和桌面建構高品質的應用程式。藉助 Genkit Dart，您可以將同樣的生產力帶到全端代理應用程式中。

今天，我們宣布 Genkit Dart 1.0，這是 Google 的開源框架的第一個穩定、可正式發行的版本，用於使用 Dart 建構由 AI 驅動的功能和代理。自今年稍早發佈 預覽版 以來，Dart 和 Flutter 社群的回饋幫助我們改進了 API 並擴展了用於正式發行工作負載的工具套件。

若要開始使用，請將 genkit 加入您的專案：

1

dart pub add genkit

您也可以安裝代理技能，為 Antigravity、Claude Code 和 Codex 等 AI 程式碼助理提供最新的 Genkit Dart API 和最佳實踐知識：

1

npx skills add genkit-ai/skills

為什麼選擇 Genkit Dart

Genkit 提供跨模型供應商的統一 API、伺服器和用戶端之間的端對端型別安全，以及用於測試和偵錯 AI 工作流程的本機工具。

使用一個 API 使用任何模型

Genkit 透過單一介面支援 Google Gemini、Anthropic Claude、OpenAI 和與 OpenAI 相容的模型。您可以將模型供應商註冊為 Plugin，並且可以在不重寫應用程式邏輯的情況下切換模型：

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

final ai = Genkit(plugins: [googleAI(), anthropic()]);
final prompt = 'Suggest a weekend getaway from San Francisco.';

final fromGemini = await ai.generate(
  model: googleAI.gemini('gemini-flash-latest'),
  prompt: prompt,
);

final fromClaude = await ai.generate(
  model: anthropic.model('claude-sonnet-5-5'),
  prompt: prompt,
);

使用流程實現端對端型別安全

Genkit 讓您可以將 AI 邏輯包裝到流程中：強型別、可觀察的函數，易於測試並部署為 HTTP 端點。使用 schemantic 套件，您可以一次在 Dart 中定義資料模式，從模型生成結構化輸出，並在後端和 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
30
31
32
33

// shared/lib/models.dart (used by both server and app)
@Schema()
abstract class $TripRequest {
  String get destination;
  int get days;
}
// ...plus an Itinerary schema for the result.

// server/bin/server.dart
final planTrip = ai.defineFlow(
  name: 'planTrip',
  inputSchema: TripRequest.$schema,
  outputSchema: Itinerary.$schema,
  fn: (request, _) async {
    final response = await ai.generate(
      model: googleAI.gemini('gemini-flash-latest'),
      prompt: 'Plan a ${request.days}-day trip to ${request.destination}.',
      outputSchema: Itinerary.$schema,
    );
    return response.output!;
  },
);
await (GenkitRouter()..addAction(planTrip)).serve(port: 8080); // POST /planTrip

// app/lib/main.dart
final planTrip = defineRemoteAction(
  url: 'https://api.example.com/planTrip', // Your Genkit endpoint
  inputSchema: TripRequest.$schema,
  outputSchema: Itinerary.$schema,
);
final itinerary = await planTrip(
  input: TripRequest(destination: 'Kyoto', days: 5),
);

Dart 執行到哪裡，程式碼就執行到哪裡

因為您的 AI 邏輯是用標準 Dart 撰寫的，所以您可以透過熱重載快速疊代，並靈活地在適合您架構的任何地方執行程式碼：

• 直接在 Flutter 中：直接從您的應用程式呼叫模型，進行快速原型開發或自帶金鑰體驗（切勿在已發佈的用戶端應用程式中嵌入私有 API 金鑰）。
• 在 Dart 伺服器上：執行複雜的流程並將敏感的提示保留在後端，然後使用 defineRemoteAction 從 Flutter 呼叫它們，如上所示。
• 在 Flutter 中使用遠端模型：將您的 AI 邏輯保留在 Flutter 應用程式中，同時透過輕量級 Genkit 後端路由模型請求，該後端保護您的 API 金鑰並強制執行授權：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// server/bin/server.dart
final genkit = GenkitRouter()
  ..addAction(
    googleAI().model('gemini-flash-latest'),
    path: '/gemini',
    // Runs before the model; throw a GenkitException to reject the request.
    contextProvider: (request) async =>
        {'user': await verifyUser(request.headers['authorization'])},
  );
await genkit.serve(port: 8080);

// app/lib/main.dart
final ai = Genkit();
final gemini = ai.defineRemoteModel(
  name: 'gemini',
  url: 'https://api.example.com/gemini',
  headers: (context) async =>
      {'Authorization': 'Bearer ${await getIdToken()}'},
);
final response = await ai.generate(
  model: gemini,
  prompt: 'Suggest a packing list for Kyoto in April.',
);

使用開發人員 UI 進行測試和偵錯

Genkit 包含一個本機開發人員 UI，用於測試流程、嘗試提示以及逐步檢查執行追蹤。使用 Genkit CLI 與您的 Dart 程序一起啟動它：

1

genkit start -- dart run bin/server.dart

專為代理工作流程而建構

自預覽版發佈以來，我們已擴展 Genkit Dart，使其具備為多步驟代理工作流程設計的功能，包括人工介入中斷、生成中介軟體、提示管理和正式發行遙測。

為模型提供人工介入工具

工具讓模型可以呼叫您的 Dart 函數來獲取資料或觸發動作，例如搜尋航班或預訂飯店。當動作需要使用者確認時，工具可以透過回傳 .interrupt(...) 而不是 .response(...) 來暫停生成循環：

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

final bookHotel = ai.defineTool(
  name: 'bookHotel',
  description: 'Books a hotel room for the user.',
  inputSchema: HotelBooking.$schema,
  fn: (input, ctx) async {
    // Ask the user to confirm before charging their card.
    if (ctx.resumed == null) {
      return .interrupt({'hotel': input.hotelName, 'total': input.totalPrice});
    }
    final confirmation = await hotels.book(input);
    return .response(confirmation.id);
  },
);

將核准檢查放在工具內部可確保模型無法繞過它。當 generate 回傳 FinishReason.interrupted 時，您的 Flutter 應用程式可以提示使用者確認並從暫停的位置恢復執行。

使用中介軟體擴展生成

中介軟體直接掛鉤到 generate 循環中，以攔截模型呼叫、注入工具或修改請求和回應。使用 genkit 和 genkit_middleware，您可以將預先打包的功能（如自動重試、動態 SKILL.md 載入和工具核准規則）附加到任何 generate 呼叫：

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

final ai = Genkit(plugins: [googleAI(), SkillsPlugin(), ToolApprovalPlugin()]);

final response = await ai.generate(
  model: googleAI.gemini('gemini-flash-latest'),
  prompt: 'Move my Kyoto hotel check-in to Friday.',
  tools: [findBookings, updateBooking],
  use: [
    retry(maxRetries: 3),
    skills(skillPaths: ['./skills']),
    toolApproval(approved: ['findBookings', 'use_skill']),
  ],
);

您也可以使用 defineGenerateMiddleware 編寫自訂中介軟體，用於記錄、快取或模型備援等跨領域邏輯。

使用 Dotprompt 管理提示

Dotprompt 讓您可以將提示範本、模型設定和輸入/輸出模式一起管理在 .prompt 檔案中。Genkit 會自動從您的 prompts/ 目錄載入提示，因此您可以在 Dart 中將它們作為可呼叫函數來調用：

1
2
3
4
5
6
7

---
model: googleai/gemini-flash-latest
input:
 schema:
 destination: string
---
Write a friendly, two-sentence introduction to {{destination}} for a first-time visitor.

1
2

final introPrompt = await ai.prompt('destinationIntro');
final response = await introPrompt({'destination': 'Kyoto'});

監控您正式發行的應用程式

當您準備部署時，genkit_otel 套件會使用 OpenTelemetry GenAI 語義約定匯出追蹤、令牌使用量和延遲指標，並直接與您現有的可觀察性後端整合：

1
2
3
4
5
6

import 'package:dartastic_opentelemetry/dartastic_opentelemetry.dart';
import 'package:genkit/telemetry.dart';
import 'package:genkit_otel/genkit_otel.dart';

await OTel.initialize();
configureInstrumentation(GenAiInstrumentation());

接下來：有狀態代理和生成式 UI

除了穩定版 1.0 核心之外，我們正在 package:genkit/experimental.dart 導入下開發更進階的代理 API，以便您可以儘早試用並幫助設計它們。

有狀態代理將模型、工具、系統指令和狀態組合到一個 defineAgent 呼叫中。對話會使用會話儲存區在回合和應用程式重啟之間保持不變，您可以使用 remoteAgent 將任務委派給子代理，或透過 HTTP 公開代理以連接您的 Flutter 應用程式：

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

import 'package:genkit/experimental.dart';

final travelAgent = ai.defineAgent(
  name: 'travelAgent',
  model: googleAI.gemini('gemini-flash-latest'),
  system: 'You help users plan and book trips.',
  tools: [searchFlights, bookHotel],
  store: FirestoreSessionStore(collection: 'sessions'),
);

final chat = travelAgent.chat(sessionId: 'user-123');
final response = await chat.send(text: 'Find me a weekend in Lisbon.');

使用 A2UI 的生成式 UI 讓代理程式可以串流互動式 UI 介面，而不是純文字。藉助 genkit_a2ui，代理程式可以發出日期選擇器、表單和確認卡等組件，您的 Flutter 應用程式會將其逐步渲染為原生 Widget。請查看 A2UI 指南 以了解更多資訊。

開始使用

Genkit Dart 1.0 現已在 pub.dev 上提供。感謝 Dart 和 Flutter 社群中的每一個人，他們透過預覽版進行建構、報告問題並貢獻拉取請求，幫助 Genkit Dart 達到 1.0 版本。

• 開始使用：遵循快速入門指南。
• 探索範例：瀏覽 GitHub 上的範例應用程式。
• 加入社群：在 Discord 上與團隊聊天。
• 保持更新：在 X 和 LinkedIn 上關注 Genkit。
• 提供回饋：在 GitHub 儲存庫 上提出問題。

我們迫不及待想看到您使用 Genkit Dart 1.0 建立的成果！

更多來自 Flutter 的內容

材質和 Cupertino 解耦已實現

材質和 Cupertino 解耦已實現

為什麼將 Material 和 Cupertino 移出核心 Flutter 可以加速新功能的修復和開發

Craig Labenz

2026 年 9 月 9 日 · 閱讀 4 分鐘

嘗試 Flutter Web 與 WebAssembly 周

立即選擇 Wasm 編譯，將網頁效能提升 2 到 5 倍

Kevin Moore

2026 年 8 月 17 日 · 閱讀 4 分鐘

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

原文：https://flutter.dev/blog/converted-genlatte-fullstack-dart

我如何將 GenLatte 轉換為全端 Dart

並減少應用程式的伺服器費用

如果您曾追隨 Flutter 團隊進軍經營快閃咖啡攤的曲折故事，您會知道我們結合了 Flutter、Firebase 和 Gemini 來提供奇異的咖啡。您也知道，由於不收取任何費用，我們未能獲利。

此外，如果您查看了程式碼，您可能還注意到我們的 Flutter 前端是由用 Node.js 撰寫的 Firebase 函式所補充的。這是一個有點令人驚訝的歷史遺物，因為 Firebase 對 Dart 函式的支援幾乎與 GenLatte 首次在 Google Cloud Next 出現的同時進入公開預覽。

但這正是問題所在——由於 Firebase 對 Dart 的支援在最後一刻熱烈推出，我們根本無法承諾在生產應用程式中使用它，因為時間壓力很大。如果 Firebase 對 Dart 的支援因任何原因而延遲，我們可能就無法及時在 Cloud Next 部署。因此，當 GenLatte 在 4 月、5 月或 6 月出現時，它是以 Node.js 後端運行的。

我個人對此很不滿。

完全擁抱全端 Dart

Dart 和 JavaScript 是具有不同優勢的不同語言。從某種意義上說，這有點像一個不言而喻的說法，但它對伺服器端遷移也有更深層次的影響，因此一對一重寫可能不值得。畢竟，伺服器上的 Dart 可以享受與客戶端上的 Dart 的端到端類型安全，如果仍然堅持使用無類型 Map 那將會是一個真正的遺憾。

考慮到這一點，儘管我的目標可能比我的能力大，但我開始大幅重寫 GenLatte。我的許多目標包括：

• 在整個堆疊中共享模型（這是一個小小的提升，因為我最初決定將所有資料類別放在單獨的 genlatte_data 套件中）
• 將我們的 Firebase 函式足跡減少到單一可部署函式
• 移除所有客戶端寫入；改為專注於呼叫伺服器端函式
• 移除所有伺服器端觸發器，並明確地在從客戶端呼叫的伺服器端函式中執行任何資料變更
• 保留所有基於角色的 ACL 檢查
• 最終進行端到端測試！

這些目標很宏偉，而且不在我 2026 年的路線圖上，所以，我自然而然地保密了我的計畫並開始打字！

執行遷移

與我對原始 GenLatte 的工作不同，該專案主要是在沒有使用 AI 的情況下開發的，我知道我緊迫的時間表需要引入一個 Zoom zoom 打字助手。我選擇的模型是 Gemini 3.6 Flash，它結合了低延遲和通用的知識，這對我來說非常有用。

從高層次來看，我仍然閱讀 Gemini 撰寫的每一行程式碼，以保持對專案的認知所有權。從深入了解的角度開始，這讓事情變得更容易，如果沒有這個承諾，我不認為重寫會在我可用的幾天內成功。程式碼助手，儘管它們很棒，但仍然非常受益於人類的指導。

共享模型

全端類型安全意味著客戶端和伺服器共享程式碼。如前所述，這意味著將任何必須在伺服器上執行的程式碼拆分成自己的套件，並且，至關重要的是，不能依賴 Flutter SDK。這在很大程度上是簡單的，但確實需要對我自己的資料管理套件 pkg:data_layer 進行補充。它的其中一個補充套件 pkg:data_layer_firestore 依賴於客戶端 Firebase SDK（它依賴於 Flutter），因此我被迫添加了 pkg:data_layer_firestore_admin，它是純 Dart 並且因此對伺服器友好。

使用單一 Firebase 函式

預設情況下，您部署的每個 Firebase 函式都會變成自己的 Cloud Run 服務。（如果您是 Firebase Functions 使用者，而這對您來說是新聞，請導航到 Google Cloud 控制台中的 Cloud Run，看看 Firebase 香腸是如何製作的！）

然而，在 GenLatte 的 Node.js 時代，我依賴了超過 15 個獨立的 Cloud Run 服務，我知道我想要一個更精簡的設定，原因有很多。首先，部署會顯著加快，但更重要的是，它會大幅降低 GenLatte 的伺服器費用。

「但是 Craig！」您說，「Cloud Run 在不使用時會縮小到零，所以這實際上很重要嗎？」

好問題。我很高興您有注意。

是的，這非常重要！當 GenLatte 正在使用時，各種資料寫入和非同步任務會啟動所有 15 個服務，雖然每個服務在閒置時都會關閉，但這仍然對我們的伺服器費用產生可預測的影響。但是，更糟糕的是，我們將每個服務的最小節點計數設定為 1，以避免冷啟動，這當然會取消這個縮小到零的功能。最終結果是 GenLatte 的啟動成本出奇地高。

如何將所有內容塞入一個 Firebase 服務

為了省錢，我決定借鑑 Serverpod 的靈感，引入一個 BackendMessage DTO 來告訴我的單一 Firebase 函式我想要它實際呼叫的內部函式。在 Gemini 幫助我編寫的一些巧妙的 pkg:freezed 技巧下，我甚至能夠獲得類型化的回應。

最終的類別設定有點複雜，但如果您喜歡類型安全和省錢，那麼值得理解。

BackendMessage

這是我在實際函式簽章中使用的父 DTO 類別。

1
2
3
4

abstract interface class BackendMessage<R extends MessageResponse> {
  /// Json serializer.
  Json toJson();
}

MessageParameters

這實作了 BackendMessage 並使用 pkg:freezed 將個別訊息類型與預期的回應類別綁定。

@Implements.fromString 技巧產生滿足父類別要求以綁定 MessageResponse 類型的類別。雖然源類別使用原始字串感覺類型不安全，但任何拼寫錯誤都會導致產生類別中的錯誤，這意味著它在功能上是類型安全的。

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

@freezed
sealed class MessageParameters with _$MessageParameters {
  /// Creates a new latte order.
  @Implements.fromString('BackendMessage<SaveOrderResponse>')
  const factory MessageParameters.saveOrder({
    @LatteOrderConverter() required LatteOrder order,
  }) = SaveOrderParameters;

  /// Marks a latte order as completed.
  @Implements.fromString('BackendMessage<EmptyResponse>')
  const factory MessageParameters.completeOrder({
    required String orderId,
    required String baristaId,
  }) = CompleteOrderParameters;

  // Many more message types...
}

MessageResponse

這關閉了迴圈，宣告了每個方法呼叫預期的回應類別。它為需要即時回饋的方法提供了單獨的回應類型，並提供了空回應以表示 202 Accepted 或 204 No Content HTTP 回應。

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

@freezed
sealed class MessageResponse with _$MessageResponse {
  /// Return data for [SaveOrderParameters].
  const factory MessageResponse.saveOrder({required LatteOrder? latteOrder}) =
      SaveOrderResponse;

  // Many more response types...

  /// Placeholder for method calls which require no return value.
  ///
  /// This is typically because the client will pick up any state changes via
  /// watched Firestore collections.
  const factory MessageResponse.empty() = EmptyResponse;
}

我的 DTO 都準備好後，我需要一個單一的伺服器端函式來接收並相應地路由每個傳入的 BackendMessage。

1
2
3
4
5
6
7
8
9
10
11

firebase.https.onCallWithData<MessageParameters, Object>(
    (request) {
      final MessageResponse response = switch (request.data) {
        SaveOrderParameters msg => saveOrder(msg),
        CompleteOrderParameters msg => completeOrder(msg),
        ...
      };
      return response.toJson();
    },
    ...
);

最後，我需要滿足其契約的 saveOrder 和 completeOrder 方法。

1
2
3
4
5

// Other Dart files

Future<SaveOrderResponse> saveOrder(SaveOrderParameters message) {}
Future<EmptyResponse> completeOrder(CompleteOrderParameters message) {}
// Many more functions...

有了這些系統，我就可以將任意多的伺服器端操作塞進一個 Dart 函式中。太省錢了！

重構所有寫入

上述 BackendMessage 系統為立即實現我的另外三個子目標奠定了基礎：

1. 我透過在 firestore.rules 檔案中阻擋客戶端寫入來移除所有客戶端寫入。我也重構了我的資料管理層，以呼叫單一後端函式，而不是直接呼叫 docRef.set() 等 Firestore 函式。
2. 我同樣移除了所有 Firestore 觸發器，但將遺失的功能重新實例化為我可以從客戶端明確呼叫的函式。
3. 我透過在 Dart 程式碼中引入 ACL 檢查來維持 GenLatte 嚴格的權限模型，作為一個可測試的系統，這讓我晚上睡得安穩。

加入端對端測試

在我的最後一招中，我能夠命令 Gemini 撰寫伺服器端測試，並且非常令人興奮地，在客戶端測試中模擬後端行為，這些測試突然變成了端對端測試。鑒於我的類型安全回傳值，這帶來了我滿意的穩定性和應用程式可靠性！

全端語言的樂趣

無論您喜歡關聯式資料，因此使用 Serverpod 之類的工具，還是像 Cloud Firestore 這樣的非關聯式解決方案，在整個堆疊中以相同的語言撰寫程式碼都是一種夢想。如果該語言是 Dart，並且您發現自己沉浸在完全健全的 null-safe 類型安全的榮光中，那麼勝利將不斷降臨。它確實創造了電腦實際上是您朋友的錯覺！

我很享受將 GenLatte 轉換為處處使用 Dart 的過程，透過這樣做，我將其伺服器費用削減到 Node.js 時代的一小部分，並提高了可靠性和效能。我用於執行變更的 Gemini 代幣費用在短短幾分鐘的操作後就輕鬆收回了。現在，GenLatte 可以長期為活動參與者提供個人化咖啡，或者直到我們厭倦經營它為止。

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

原文：https://dart.dev/blog/google-summer-of-code-2026-results

Google Summer of Code 2026 成果

今天，我們將重點介紹由 Dart 和 Flutter 在 Google Summer of Code 2026 中指導的貢獻者所完成的專案和成果。

Google Summer of Code (GSoC) 計畫旨在吸引全球新開發者參與開源軟體開發。Google 贊助貢獻者在夏季與一個指導開源組織合作進行為期 12 週的程式設計專案。在過去的 20 年中，超過 20,000 名貢獻者參與了 Google Summer of Code。

今年，Dart 和 Flutter 連續第七年作為指導組織參與 Google Summer of Code。我們收到了來自世界各地近 100 份潛在參與者的專案提案。今天，我們將重點介紹今年夏天我們指導的一些專案。貢獻者在這篇文章中描述了他們的專案。

將 WebSocket 和 gRPC 支援加入 Flutter DevTools 網路面板

作者：Yash Hosalli

在開發即時系統時，我注意到開發者體驗中存在一個空白。Flutter DevTools 對 HTTP 請求提供了很好的可見性，但是一旦 WebSocket 連接建立起來，就很難看到實際發生了什麼。框架流、連接生命週期和長時間的活動可能會很快變成一個黑盒子，使即時調試變得令人沮喪。

許多現代應用程式都依賴 WebSocket，但幾乎沒有調試可見性。這個專案將這種缺失的可見性帶入現有的 Dart 和 Flutter 工具棧。我擴展了 dart:io、dart:developer 和 VM Service，以捕獲輕量級連接級別和框架級別的 WebSocket 資料，遵循為 HTTP 分析已建立的架構。目標是讓 WebSocket 調試感覺熟悉，而不是引入全新的分析工作流程。

收集到的資料隨後直接顯示在 DevTools 網路面板中，開發者可以在其中檢查連接、大小、時間戳和生命週期事件。這將 WebSocket 通信轉變為開發者可以實際觀察和理解的內容。

若要了解更多資訊，請查看我的 GSoC 進度追蹤頁面。

FFIgen 的 C++/C 相容性工具

作者：Hassnaa Mohamed Ahmed

本專案的主要目標是擴展 package:ffigen 以自動生成 C++ API 的 Dart FFI 綁定。Dart 可以透過 FFI 套件與 C 和 C 相容的 API 通信，而 FFIgen 可以自動生成這些 API 的 Dart 綁定。然而，C++ 引入了 Dart FFI 無法直接表示的概念，例如類別、建構子和解構子、繼承和原生物件所有權。因此，從 Dart 使用 C++ 函式庫需要額外的膠水程式碼並仔細處理 Dart 物件及其底層 C++ 物件之間的關係。

FFIgen 中的實驗性 C++ 支援透過為 C++ 類別生成 Dart 綁定以及所需的 C++ 膠水程式碼來解決這些挑戰。生成的綁定支援 C++ 類別指標和原生物件生命週期管理，允許 Dart 物件與其底層 C++ 物件互動，同時保留原生所有權語義。這使得從 Dart 使用 C++ 類別成為可能，而無需使用者手動編寫綁定和記憶體管理層。

範例 C++ 標頭：

1
2
3
4
5
6
7
8
9

class Animal {
public:
  int age;
  Animal(int age);
  ~Animal();
  void speak();
  int getAge() const;
  static int getCount();
};

生成的 C++ 膠水程式碼：

1
2
3
4
5
6
7
8
9
10
11

FFIGEN_EXPORT Animal* Animal_new(int age) {
  return new Animal(age);
}
​
FFIGEN_EXPORT int Animal_getAge(const Animal* self) {
  return self->getAge();
}
​
FFIGEN_EXPORT void Animal_delete(Animal* self) {
  delete self;
}

生成的 Dart 綁定用法：

1
2
3
4
5
6
7
8
9
10
11

// Instantiate the C++ class through the generated constructor wrapper.
final animal = Animal(10);
expect(animal.getAge(), 10);
​
animal.speak();
​
// Invoke a static C++ method.
expect(Animal.getCount(), 42);
​
// Deterministically release the native object.
animal.dispose();

這種方法在 C++ 物件導向 API 和 Dart 的 FFI 模型之間提供了橋樑，同時使生成的綁定盡可能接近原始 C++ API 的語義。

有關更多詳細資訊，請查看 GitHub 上的 GSoC 2026 專案報告。

將 IntelliJ Plugin 從 Weberknecht WebSocket 函式庫遷移出來

作者：Javad Asadi

IntelliJ 的 Dart 和 Flutter Plugin 使用 Weberknecht 函式庫與 Dart Tooling Daemon 和 VM 服務進行通信。Weberknecht 是一個老舊、未維護的函式庫，繼續依賴它不再是一個可行的選擇。

在 GSoC 2026 中，我們決定用 JDK 內建的 WebSocket 客戶端替換這個函式庫。它從 Java 11 開始提供，使我們能夠避免另一個外部依賴。

遷移一次一個服務地進行，首先在 Dart Plugin 中，然後在 Flutter Plugin 中。在每個階段，我嘗試編寫針對 WebSocket 的測試，包括正常路徑和邊緣案例。目標是讓測試在遷移之前和之後都通過。

遷移成功完成。Dart 和 Flutter Plugin 現在都使用 JDK 內建的 WebSocket 客戶端，同時保留了所有工作流程中的現有行為。在最終遷移階段之後，所有對 Weberknecht 的引用——包括其依賴項和捆綁的 JAR 檔案——都從兩個儲存庫中刪除。因此，這些 Plugin 不再依賴於過時的外部 WebSocket 函式庫。

有關此專案的更多資訊可以在我的 專案摘要 gist 中找到。

package:webcrypto 的 Android JCA 後端

作者：M. Fazri Nizar

package:webcrypto 目前隨 Android 應用程式一起提供額外的 BoringSSL 原生函式庫。在 GSoC 2026 期間，我探索了透過 Java Cryptography Architecture (JCA) 和 package:jni 使用 Android 自己的密碼學 API。由於 Android 已經提供了內建的密碼學，利用它可以最終減少應用程式隨附的額外原生程式碼。第一個里程碑是讓 SHA-256 原語正常工作。

在第一個原始功能合併後，我加入了 HMAC 和 AES，接著是 RSA、橢圓曲線操作、HKDF 和安全亂數生成。在整個開發過程中運行套件現有的測試，使我能夠將 JCA 實作與 BoringSSL 和瀏覽器後端進行比較。這些測試還發現了不同提供者之間的差異，特別是在較舊的 Android 版本上關於 AES-GCM 參數和 RSA 私鑰的差異。PBKDF2 仍未解決，因為 Web Crypto 接受原始密碼位元組，而 JCA 的標準 API 接受字元。

JCA 後端實作了現有的介面，這意味著公共 API 保持完全不變。因此，開發人員將能夠受益於減少的應用程式大小而無需更改任何程式碼。

若要了解有關實作和持續進行的工作的更多資訊，請查看我在 GitHub 上的 GSoC 2026 專案報告。

在 Dart DevTools 中檢查原生記憶體

作者：Nourhan H.

在調試涉及 Pointer<X> 的 Dart 程式碼時，調試器通常會顯示無用且模糊的資訊。這迫使開發人員依賴印出語句而不是直接檢查變數。

例如，給定以下程式碼：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import 'dart:ffi';
import 'package:ffi/ffi.dart';
​
final class MyStruct extends Struct {
  @Int32()
  external int a;
​
  @Double()
  external double b;
}
​
void main() {
  final pInt16 = malloc<Int16>()..value = -500;
  final ptr = malloc<MyStruct>();
​
  ptr.ref.a = 42;
  ptr.ref.b = 3.14;
​
  malloc.free(ptr);
  malloc.free(pInt16);
}

調試器以前顯示：

此外，嘗試檢查指向無效記憶體的指標以前會導致 segmentation fault，使得記憶體檢查不安全。這個問題影響了各種 Pointer<X> 類型，包括基本類型、結構體、聯合體等。

我們解決了這個問題，使記憶體檢查既安全又方便開發人員。

例如，考慮檢查一個包含多個指標類型的容器：

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

import 'dart:developer';
import 'dart:ffi';
import 'package:ffi/ffi.dart';
​
class MultiPointerContainer {
  final Pointer pInt16;
  final Pointer pInt32;
  final Pointer pDouble;
  final Pointer pNull;
  final Pointer pGarbage;
  final Pointer pBool;
​
  MultiPointerContainer({
    required this.pInt16,
    required this.pInt32,
    required this.pDouble,
    required this.pNull,
    required this.pGarbage,
    required this.pBool,
  });
}
​
void main() {
  final pInt16 = calloc()..value = -500;
  final pInt32 = calloc()..value = -100;
  final pDouble = calloc()..value = 1.5;
  final pGarbage = Pointer.fromAddress(0xDEADBEEF);
  final pBool = calloc()..value = true;
​
  final container = MultiPointerContainer(
    pInt16: pInt16,
    pInt32: pInt32,
    pDouble: pDouble,
    pNull: nullptr,
    pGarbage: pGarbage,
    pBool: pBool,
  );
​
  debugger();
​
  calloc.free(pInt16);
  calloc.free(pInt32);
  calloc.free(pDouble);
  calloc.free(pGarbage);
  calloc.free(pBool);
}

調試器現在顯示：

無效記憶體讀取和 null 指標現在已完全安全地處理。我們整合了低階核心 API，以防止在五個主要作業系統中進行任意記憶體讀取時發生分割錯誤：

• Linux 和 Android： pread64(/proc/self/mem)
• Windows： ReadProcessMemory
• macOS 和 iOS： mach_vm_read_overwrite

這個修正顯著增強了任何編寫 Dart 程式碼並需要清晰、可靠地了解指標內部發生情況的開發人員的體驗。

有關此專案的更多資訊，請查看 GitHub 上的 GSoC 2026 專案儲存庫。

更多來自 Dart

Dart in Google Summer of Code 2026

我們很高興地宣布，Dart 專案將在 Google Summer of Code 2026 中第七次指導貢獻者！

Jonas Finnemann Jensen

2026 年 3 月 5 日 · 2 分鐘閱讀

Google Summer of Code 2025 成果

Google Summer of Code (GSoC) 計畫旨在吸引全球新開發者參與開源軟體開發。Google...

Daco Harkes

2025 年 10 月 20 日 · 9 分鐘閱讀

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

原文：https://flutter.dev/blog/decoupling-material-cupertino

Material 和 Cupertino 的解耦終於實現了

長久以來，Flutter 都是一個「內建電池」的框架，擁有出色的工具、設計系統、動畫等。但電池並非永恆，因此在需要時能夠更換它們非常重要。回溯到 2017 年，當 Flutter 接近可行性時，提升 Material 和 Cupertino 的地位被普遍認為是正確的決定。快轉到 2020 年代，這種觀點發生了轉變，Material 和 Cupertino 這兩塊電池開始感覺更像是焊死的，而不是簡單地內建的。多年來，改進這個系統一直是 Flutter 開發人員最主要的需求。現在，到了 2026 年，一個漫長的過程終於讓這個開發人員的願望成真。

我們正在做什麼

從幾個月前開始，並於 2026 年 8 月完成，這項工作凍結了對 Flutter 框架內 Material 和 Cupertino 函式庫的貢獻，並在 pub.dev 上以 1.0.0 版本發布了完全相同的 pkg:material_ui 和 pkg:cupertino_ui 複本。 (這些外部函式庫並未凍結，並已準備好接受貢獻！) 然後，在未來某個日期，這項工作將完成，Material 和 Cupertino 函式庫將從 Flutter 框架本身中棄用並最終移除。

暫停其他工作以完成此舉的原因有很多，其中一些如下所述。

減少更新 Flutter 時的摩擦

多年來，升級 Flutter 以獲取安全補丁和其他修復，必然會包含任何 Material 或 Cupertino UI 更新。毋庸置疑，這是開發人員摩擦的主要來源，導致許多團隊停留在較舊的 Flutter 版本。這也意味著當團隊最終啟動升級時，這項任務可能會耗費開發人員數週的時間，並在團隊解決 UI 變更時瓶頸整個儲存庫。

現在，Material 和 Cupertino 函式庫已從核心框架中遷移出來，我們預計更新 Flutter 將恢復到它本來應該是一個簡單的任務——僅當底層平台變更需要 Flutter 開發人員注意時才會變得複雜。

加速 Material 和 Cupertino 的進程

Flutter 每 3 個月發布一個新的穩定版本，對於其範圍的專案來說，這個速度相當快。然而，儘管速度很快，它仍然意味著最壞的情況（在穩定版本截止後一分鐘提交程式碼）可能會導致 16 週的延遲，直到該變更在穩定版本中發布。這…不太好。

現在，pkg:material_ui 和 pkg:cupertino_ui 分別獨立成套件，可以按照自己的每週排程發布。這簡化了 CI 工作流程，並且更容易貢獻，特別是對於那些不熟悉 Flutter 內部結構的人來說。

基於這些原因，我們預計 Material 和 Cupertino 將加速開發進程，並更好地與 Google 和 Apple 的設計語言更新保持同步。例如，Liquid Glass 和 Material 3 Expressive 的官方實作已經在進行中。我們正在與我們的套件作者社群合作，以確保 Flutter 對這些函式庫的實作具有最佳的品質和相容性。

強化基礎 Widget

在 Flutter 框架中提升 Material 和 Cupertino 函式庫的地位所造成的意想不到的後果之一是，在這些設計函式庫中構建基礎功能太具誘惑力了。兩者在技術上都是在普通 widgets 函式庫之上構建的，但 widgets 函式庫本身充滿了基本 UI 概念中的漏洞和空白。

為了解決這個問題，解耦工作的一部分將填補 widgets 函式庫中的這些空白，以提供一個更堅實的基礎，開發人員可以在其之上構建其他設計語言。Flutter 生態系統已經支援許多設計語言，包括 macos_ui、fluent_ui、yaru、arna、chicago、VSP、shadcn 等。隨著時間的推移，我們希望透過用更多有用的構建塊來擴充 Flutter 的核心 Widget，從而簡化這項任務。

我們沒有做什麼

pub.dev 上的 material_ui 和 cupertino_ui 套件將繼續受到 Flutter 團隊本身的相同關注，並且自 2026 年 8 月 13 日起，開放給所有 Flutter 開發人員貢獻。雖然 Flutter 團隊的資源有限，我們偶爾必須做出艱難的選擇並降低某些計畫的優先順序；但這不是那回事。Flutter 團隊仍然致力於為 Material 和 Cupertino 提供出色的產品，讓您的 Flutter 應用程式在您所針對的所有平台上看起來現代且符合慣例。

展望未來

所有能夠存活到第十二年的專案都會有技術債。目標不是完全避免這些債務，而是識別它們並撥出時間和精力來償還它們。對於 Flutter 團隊來說，解決上述問題一直是我們願望清單上的項目，我們很高興最終能為所有開發人員提供更流暢的升級、更快的創新和更強大的核心 Widget 函式庫。

若要開始使用，如果您的應用程式使用 flutter/material.dart 或 flutter/cupertino.dart，請使用 dart fix 將新的獨立函式庫以 1.0.0 版本新增到您的 pubspec.yaml 檔案中，並替換您的導入以使用新的套件。我們的預期是這將是一個直接的變更，但如果您遇到任何問題，請 提交議題。

如果您是具有 Material 或 Cupertino 專業知識的 UI 開發人員，請考慮為獨立函式庫做出貢獻！一如既往，我們建議您要嘛尋找一個您感興趣的議題，要嘛為您想完成的工作提交一個功能請求。

下次再見，祝您 Fluttering 愉快！

1. 為了簡化您的遷移，我們特意選擇了版本 1.0.0 來標記獨立版本，該版本完美匹配每個函式庫在框架中的狀態。未來，這些函式庫將使用語義版本控制進行演進。 ↩

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

原文：https://dart.dev/blog/skills-cli-1-0-bundle-and-distribute-ai-agent-skills-for-your-packages

Skills CLI 1.0：為您的套件捆綁和分發 AI 代理技能

直接與您的套件一起發布官方 AI 代理技能，以提高可發現性。

作者：Jake Macdonald
2026 年 9 月 8 日 · 閱讀約 4 分鐘

自 2025 年末以來，Agent Skills 一直在改變使用者為其 AI 代理提供更好背景資訊的方式。它們易於建立，並透過漸進式披露有效利用 token。這些優點共同彌補了知識截止期的差距，使代理能夠更有效地處理不熟悉或更新的程式碼庫、依賴項和工具。

今天，技能通常透過 Git 儲存庫共享，要求開發人員手動複製和拷貝檔案，或依賴 npx skills 等工具。雖然 npx skills 運作良好，但對於像我這樣熱衷於 Dart 的人來說，僅僅為了運行一個命令列工具就需要 Node.js 感覺格格不入。Dart 始終採用「開箱即用」的方法，您所需的一切都內建於 SDK 中。管理 AI 技能也應該感覺同樣原生。

即使對於已經安裝 Node.js 和 npx 的開發人員來說，仍然缺乏可發現性和套件版本支援。您如何確保您使用的技能與專案中套件的確切版本匹配？

導入 skills CLI

為了解決這兩個問題，Serverpod 團隊建立了 skills CLI。我們很高興地宣布 1.0 版本，現在由 Dart 團隊直接維護和發布。

這個工具不僅僅是 npx skills 的替代品。真正的魔力在於它使套件作者能夠輕鬆地直接與其套件一起發布技能。他們所需要做的就是將它們放在頂層的 skills/ 目錄下：

1
2
3
4
5

my-project/
├── src/
├── skills/ <--- skills
├── pubspec.yaml
└── README.md

我們建議使用新的 dart run skills@ 語法運行此工具，它始終將 CLI 的最新版本作為全域工具運行。或者，您可以使用 dart install 安裝該工具（只需記住定期更新它！）。

對於套件消費者：安裝技能

若要直接從 pubspec.yaml 中的依賴項獲取技能，請運行 get 命令：

1
2

# Scans immediate dependencies and discovers available skills.
dart run skills@ get

skills CLI 掃描您的專案依賴項中的捆綁 skills/ 目錄。然後它會列出可用的技能，讓您選擇要安裝的技能。

隨後的運行是增量的——只顯示新的、更新的、已移除的或先前跳過的技能。您也可以傳遞 --all 標誌以一次安裝所有技能依賴項。

對於套件作者：發布技能

套件作者今天就可以開始與其程式碼一起發布技能。若要建立技能，請在 skills/ 中加入一個目錄，並以您的套件名稱作為前綴（以防止衝突），並包含一個 SKILL.md 指令檔。這遵循標準的 Agent Skills 佈局。

例如，一個名為 networking 的套件可以使用以下結構強制執行正確的 API 使用：

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

---
name: networking-error-handling
description: >-
  Use when the user is making network requests using the networking APIs
  to ensure safe patterns.
---

# Networking Error Handling

## Guidelines

- Operations must always be wrapped in a try/catch block.
- You must catch `NetworkException` specifically
  to handle retries and log diagnostics.
- Provide fallback UI state in the event of a timeout.

## Examples

```dart
try {
  final response = await NetworkingClient.fetchData();
} on NetworkException catch (e) {
  Logger.log(e.context);
  return FallbackData();
}

1
2
3
4
5
6
7
8

## 使用 `add` 命令從 Git 安裝

雖然直接從依賴項中提取技能很方便，但整個生態系統已經圍繞透過 GitHub 儲存庫共享技能而存在。這些甚至可能不直接與 Dart 或 Flutter 套件相關聯。`skills` CLI 還支援使用 `add` 命令從任何 Git 儲存庫明確安裝技能：

```bash
# Install universally applicable skills from a Git repository
dart run skills@ add https://github.com/my-org/custom-ai-skills.git

您可以安裝在 skills.sh 上找到的任何技能，這是一個流行的技能聚合網站，只需將 npx skills 命令替換為 dart run skills@。

這使團隊能夠從多個來源（包括 Dart 依賴項和外部儲存庫）組合他們的指令，所有這些都由單一工具管理。

今天就試試 skills

我們很高興看到 skills CLI 如何簡化 AI 驅動的 Dart 和 Flutter 開發！

以下是一個快速回顧：

• 套件作者： 在您的套件儲存庫中加入 skills/<package_name>-<skill-name>/SKILL.md 檔案。
• 套件消費者： 在您的專案根目錄中運行 dart run skills@ get 以發現並安裝來自您的依賴項的可用技能。

非常感謝 Serverpod 的初步實作，以及所有與我們一起塑造這些代理工作流程的早期採用者！如果您有任何回饋或遇到任何問題，請在 dart-lang/ai 儲存庫中提交問題告訴我們。

若要了解更多並探索實際操作中的技能：

• 文件：閱讀 套件技能指南 或 Flutter 套件技能文件。
• 套件作者：遵循我們的 如何與套件一起發布技能 指南。
• CLI 工具：在 pub.dev 上查看 package:skills。
• 範例：查看 Jaspr、Serverpod、Flutter Scene 和 GenUI 等套件中已發布的技能。

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

原文：https://flutter.dev/blog/a2ui-client-side-functions

使用 A2UI 的客戶端函數實現快速、可靠的計算

了解客戶端函數如何讓代理直接將本地操作委託給在使用者設備上執行的 Dart 程式碼。

Andrew Brogdon

Aug 28, 2026 · 5 min read

rss_feed

share

• content_copy複製連結

• 在 X 上分享
• 在 Bluesky 上分享
• 在 LinkedIn 上分享

生成式使用者介面 (GenUI) 正在改變我處理 Flutter UI 開發的方式。GenUI 不再為每個場景硬編碼固定畫面，而是讓 AI 代理在執行時動態生成和調整使用者介面元件。使用 Agent-to-User Interface (A2UI) JSON 訊息和 genui 套件，Flutter 應用程式可以即時渲染動態的 AI 驅動卡片和介面。

然而，當我開始建構真實世界的代理應用程式時，我發現自己正在尋找減少延遲並減少模型出錯機會的方法。當使用大型語言模型 (LLM) 進行建構時，很容易依賴模型來處理所有事情。但要求 LLM 承擔它不一定設計用於執行的任務（例如算術）會引入延遲並增加出錯的機會。

這就是 A2UI 的 **客戶端** 函數的用武之地。

在這篇文章中，我將介紹客戶端函數如何讓代理直接將本地操作委託給在使用者設備上執行的 Dart 程式碼，從而減少往返次數並在您的 Flutter GenUI 應用程式中提供更可預測的結果。

---

客戶端函數解決了什麼問題

為了純粹的數學運算，來回向 LLM 發送原始提示效率低下，增加了往返延遲並消耗了額外的令牌。相反，客戶端函數讓代理在設備上本地計算諸如成分成本、稅費總計或單位轉換之類的值。

客戶端函數透過創建清晰的分工來解決這個問題：

1. **Flutter 客戶端** 在 GenUI 目錄中宣告可用的客戶端函數，告知代理可以呼叫哪些本地操作、它們期望哪些參數以及它們返回什麼格式。
2. **LLM 代理** 決定何時以及何處顯示組件，並發出一個 A2UI 表達式，呼叫客戶端函數並提供必要的參數（例如項目 ID 和數量）。
3. **Flutter 客戶端** 在本地評估表達式並在 Dart 程式碼中同步執行數學運算，立即在螢幕上渲染清晰、格式化的結果。

透過將計算卸載到客戶端設備，您的應用程式避免了不必要的網路開銷，實現了一致的格式化，並降低了總體令牌使用量。

dart

sequenceDiagram 
 participant LLM as Gemini Agent 
 participant Client as Flutter App (genui) 
 participant Function as CalculateCost (Dart) 
 LLM->>Client: A2UI Payload with calculateCost(black_beans, 3) 
 Client->>Function: executeSync(args) 
 Function->>Client: "$2.97" 
 Client->>Client: Render Text widget ($2.97) 

content_copy

讓我們看看我如何在名為 **Commis** 的範例應用程式中實作這種模式，Commis 是一個為商業廚房和餐飲團隊建置的智慧助理。

---

CalculateCostFunction 類別的解剖

在準備即將到來的餐飲活動時，廚師可能會詢問菜單中使用的食材。為了可靠地計算和顯示食材成本，而無需等待伺服器往返，我創建了一個名為 CalculateCostFunction 的客戶端函數。

在 `genui` 套件中，同步客戶端函數擴展了 `SynchronousClientFunction`。這是 `client_functions.dart` 的完整實作：

dart

/// 一個客戶端函數，使用本地 Dart 邏輯直接在設備上計算食材成本。 
class CalculateCostFunction extends SynchronousClientFunction { 
 const CalculateCostFunction(); 
​ 
 // 1. LLM 在 A2UI 負載中引用的識別碼。 
 @override 
 String get name => 'calculateCost'; 
​ 
 // 2. 提供給 LLM 的清晰描述，以便它知道何時以及為何使用該函數。 
 @override 
 String get description => 
 'Calculates the cost for a certain quantity of an ingredient. ' 
 'Returns a formatted dollar string (for example, \$4.50).'; 
​ 
 // 3. 綁定的預期回傳類型。 
 @override 
 ClientFunctionReturnType get returnType => ClientFunctionReturnType.string; 
​ 
 // 4. 定義所需輸入參數的 JSON Schema。 
 @override 
 Schema get argumentSchema => S.object( 
 properties: { 
 'ingredient_id': S.string(description: 'The ID of the ingredient.'), 
 'quantity': S.number(description: 'The quantity of the ingredient.'), 
 }, 
 required: ['ingredient_id', 'quantity'], 
 ); 
​ 
 // 5. 客戶端上的同步 Dart 執行邏輯 
 @override 
 Object? executeSync(JsonMap args, ExecutionContext context) { 
 final ingredientId = args['ingredient_id'].toString(); 
 final quantity = num.tryParse(args['quantity'].toString())?.toDouble(); 
​ 
 if (quantity == null || quantity < 1) { 
 return '\$0.00'; 
 } 
​ 
 // 呼叫本地成本服務來獲取價格並格式化為貨幣 
 final cost = CostService().fetchPrice(ingredientId, quantity); 
 return '\$${cost.toStringAsFixed(2)}'; 
 } 
} 

content_copy

讓我們分解這個類別的關鍵部分：

1. `name`：AI 代理在 A2UI 負載中生成函數呼叫時使用的唯一識別碼（`calculateCost`）。
2. `description`：發送給 LLM 的簡潔說明，讓它知道何時以及為何呼叫此函數，以及預期什麼輸出格式。
3. `returnType`：指定函數返回的資料類型（在此範例中為字串）。
4. `argumentSchema`：使用 `json_schema_builder` 建立，此 Schema 會明確告知 LLM 需要哪些參數（`ingredient_id` 和 `quantity`）。
5. `executeSync`：當 UI 渲染時，在使用者設備上執行的核心 Dart 方法。它會解析傳入的參數，呼叫我的本地 `CostService`，並返回格式化的美元字串。

如果您剛剛注意到這種模式與用於 UI 元件的目錄條目的模式非常相似，那麼您是正確的！兩者都為代理提供了推理時使用的元數據，並搭配了執行有用操作的 Dart 邏輯：要嘛建立 Widget，要嘛在此範例中計算一個值。

---

目錄註冊和系統提示整合

為了讓代理了解 `calculateCost`，我在應用程式的 GenUI `Catalog` 中註冊了它。

在實例化 `Catalog` 時，我將 `CalculateCostFunction()` 傳遞到 `functions` 列表以及我的 UI 元件中：

dart

// lib/ui/catalog/catalog.dart 
​ 
final commisCatalog = Catalog( 
 [ 
 cateringJobItem, 
 recipeLineCatalogItem, 
 ingredientLineCatalogItem, 
 navigationCardCatalogItem, 
 simpleCardCatalogItem, 
 ], 
 functions: [ 
 CalculateCostFunction(), // 在這裡！ 
 ], 
 catalogId: 'commis_catalog', 
); 

content_copy

當初始化對話會話時，`genui` 的 `PromptBuilder` 會檢查目錄並自動提取所有客戶端函數宣告，將它們的名稱、描述和 Schema 整合到提供給 Gemini 的系統提示中。

有了這些，當廚師詢問食譜價格時，Gemini 不會嘗試猜測或計算美元總額。相反，它會發出一個 A2UI 訊息，其中包含對 `calculateCost` 的呼叫（在此範例中，用於三罐豆子的價格）：

json

{ 
 "id": "cost_val", 
 "component": "Text", 
 "text": { 
 "call": "calculateCost", 
 "args": { 
 "ingredient_id": "black_beans", 
 "quantity": 3 
 }, 
 "returnType": "string" 
 }, 
 "variant": "h2" 
} 

content_copy

請注意，A2UI 訊息中 `call` 屬性的值與目錄中註冊的函數名稱 (`calculateCost`) 相符。當 `SurfaceController` 收到此訊息時，它會在設備上使用 `executeSync` 本地評估 `calculateCost`，並立即在螢幕上渲染準確的美元字串（例如 `$2.97`）。

---

使用 Flutter 熱重載實現快速開發人員迭代

由於客戶端函數不會被後端微服務或雲端函數部署鎖定，因此使用它們仍然感覺像普通的 Dart。

如果我想更新貨幣格式（例如，添加批量折扣邏輯或從 `$4.50` 切換到 USD `4.50`），我只需在 Dart 中編輯 `executeSync`，保存檔案，然後觀察熱重載用新結果更新我的應用程式。

---

摘要與後續步驟

準備好在您的應用程式中嘗試 GenUI 和客戶端函數了嗎？

• 請查看官方的 GenUI 入門 Codelab，學習生成式 UI 的基礎知識。
• 瀏覽 pub.dev 上的 genui 套件，了解 API 詳細資訊和目錄定義。
• 瀏覽 GitHub 上的 flutter/demos 儲存庫，檢查 Commis 和其他 Dart GenUI 範例的完整原始程式碼。

祝您建構愉快！

更多 Flutter 內容

Flutter 如何領先 iOS 版本

了解 Flutter 團隊如何應對 WWDC、Beta 版本和主動工程，以提供 Day 0 iOS 支援。

Craig Labenz, Louise Hsu

Aug 25, 2026 · 7 min read

隆重推出 Flutter 的桌面視窗化 API

了解新桌面視窗化 API 背後的設計，並編寫您的第一個多視窗 Flutter 應用程式。

Matthew Kosarek

Aug 24, 2026 · 9 min read

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

原文：https://flutter.dev/blog/how-flutter-stays-ahead-of-ios-releases

Flutter 如何領先 iOS 版本

了解 Flutter 團隊如何應對 WWDC、Beta 版發布和主動工程，以實現 iOS 的 Day 0 支援。

Craig Labenz, Louise Hsu

2026 年 8 月 25 日 · 閱讀時間 7 分鐘

rss_feed

share

• content_copy複製連結

• 在 X 上分享
• 在 Bluesky 上分享
• 在 LinkedIn 上分享

每個特定於平台的子團隊的工作流程都根據該平台的演變方式量身定制，就 Apple 而言，這往往圍繞著 6 月份的一周，屆時科技界的目光都轉向了加州庫比蒂諾。

蘋果的旗艦活動，WWDC

每年 6 月，Apple 都會舉辦一場名為 WWDC 的活動，預覽他們的軟體在未來一年中將如何演變。這通常與硬體發布分開，硬體發布會在一年中的其他時間陸續推出。在 WWDC 上，Apple 的許多作業系統（iOS、macOS、watchOS 等）是主角。

如果您曾經關注過 WWDC，那麼您就知道其後 COVID 時代的通用格式：首先是主題演講，然後是「平台現狀」，最後是大量專題影片發布。2026 年，WWDC 包含了超過 145 場技術會議，幫助 Apple 的開發者社群了解預期會有哪些變化——這無疑是一個令人難以置信的資源，但內容也太多了，無法手動篩選。

您已經知道接下來會發生什麼。我們甚至不必寫出以下這句話，您就知道這是真的，但我們還是會寫：

2026 年，Flutter 團隊開始使用 AI 對每個技術會議進行分類。

從今年開始，一小段 Dart 程式碼首先從每個影片中提取了文字記錄。然後，Gemini 根據以下標準對每個會議進行排名和分類：

1. 對 Flutter 貢獻者（Google 內外）的重要性
2. 影響範圍
3. 建議採取的行動

影片發布當天日落時分，我們無需觀看 145 場（雖然質量非常高）技術會議，就得到了一份由 Gemini 生成的分類文件，其中包含每個會議的早期訊號。例如，我們的系統識別出我們可以大致忽略 SwiftData 會議，因為 Flutter 處理持久性的方式不同。另外，它將「現代化您的 UIKit 應用程式」演講標記為 Flutter 引擎團隊的關鍵 [1]，因為它描述了對 UIScene [2] 生命周期 API 的強制性更改。

[1] 為了查看對 Flutter 重要的所有內容，我們確實會親自爆一些爆米花並觀看 Gemini 以這種方式標記的每個會議。
[2] 稍後會詳細介紹 UIScene API！

第二天早上日出時，Flutter 的 iOS 團隊正式進入了緊張時期。從 6 月的 WWDC 到 9 月的最終穩定版本發布之間隔了三個月，因此這是一場與時間賽跑的競賽，充滿了衝刺和錯誤修復，以確保及時合規。這項工作量很大，但 Flutter 團隊致力於始終為每個主要的 iOS 版本提供 Day 0 支援。要追蹤我們對 iOS 27 支援的進度，請 查看其在 GitHub 上的專案。

Dart 程式碼和 Gemini 工作流的系統處理了所有 WWDC 的內容，這佔了 Apple 絕大多數的變更。然而，「絕大多數」與「全部」是不同的；有時，一個關鍵的重大變更可能來自於像一個小修補程式發行說明一樣無害的東西。

Flutter 團隊聽聞的 Beta 版發布

2024 年，iOS 18.2 開發者測試版剛剛發布，帶來了一系列更新，其中包含了手勢和指標事件處理。幾天後，我們收到了一份令人擔憂的錯誤報告：點擊 webview 上方的 Widget 後，對底層 webview 的後續手勢或點擊都不會觸發 onClick 事件。

這不僅僅是糟糕。不，這是一場紅色警戒、五級火警——因為廣告依賴 webview，剝奪開發者哪怕一美元的收入絕對是不可接受的。

這個錯誤的根本原因最初不清楚，但按照科技偵錯的傳統，團隊成員想到了嘗試「關閉再打開」的說法。我們發現，在每次點擊時，替換 webview 堆疊中的一個手勢識別器可以解決問題。沒有人對這個解決方案特別滿意，但這是一個解決方案，而且對終端使用者來說是不可見的。

快進到 2025 年 8 月的 iOS 26 Beta 版，看似不相關的變更與我們的手勢識別器切換技巧發生衝突，導致更嚴重的 regression，其中 Flutter 的觸控和手勢阻擋系統完全失效。在沒有其他選擇的情況下，我們還原了先前的權宜之計……並立即重新遇到了無回應的 webview 錯誤。

從 Flutter 端對此異常的調查毫無結果，因此我們必須簡化問題。團隊用純 Swift 建立了一個測試專案。在沒有 Flutter、沒有 Dart 的情況下，只是一個標準的 UIKit 父視圖、一個原生手勢識別器和一個獨立的 webview，我們看到了相同的錯誤行為。

這是一個巨大的勝利！憑藉清晰的重現步驟，我們向 Apple 發送了錯誤報告和建議的修復方案，Apple 很快就識別並修復了該問題。到 iOS 26.4，webview 點擊行為恢復正常，無論專案是否使用 Flutter。

多方面修復

這個圓滿的結局還有一個補充事實：與此同時，Flutter 團隊正忙於 將所有 Dart 程式碼從一個單獨的「UI 執行緒」遷移回主「平台執行緒」（用 Flutter 的術語來說）。這意味著 Dart 程式碼可以與平台程式碼（如 iOS 的 Swift 和 Objective-C）同步通訊，這為其他現代化提供了可能性，例如引入一個同步的命中測試系統。這些重構透過移除微任務延遲和其他混亂來源，進一步改善了 iOS 上的手勢行為。

這些變更結合在一起，為在 iOS 上運行的 Flutter 應用程式和原生 iOS 應用程式帶來了主要的穩定性改進。

有時我們甚至也採取主動行動

WWDC 公告和錯誤報告本質上是反應性措施，但有時 Flutter 團隊實際上是領先一步。在 2025 年春季，Apple 發布了 iOS 18.4，這在 Flutter 應用程式中產生了以下警告：

CLIENT OF UIKIT REQUIRES UPDATE: 此過程未採用 UIScene 生命週期。這將在未來版本中成為斷言。

「未來版本」是模棱兩可的，但 Flutter 團隊不會對您的應用程式拖延，因此我們提前進行了深入研究。不幸的是，暗示的變更將會是一個重大變更。

要理解原因，必須考慮自 Flutter 於 2014 年誕生以來，行動裝置格局發生了多大的變化。曾幾何時，Flutter 只有 iOS 和 Android，完全佔據了這些螢幕，並享有穩定的視窗大小。現在，在 2026 年，Flutter 運行在其他平台上，可以有多個視窗，嵌入到非 Flutter 應用程式中，並且其幾何形狀可以隨時折疊一半。這些變化使曾經簡單的問題（例如「視窗有多大？」「應用程式是否在後台？」）變得複雜，也使 UIScene 的採用變得複雜！

然後，在 2025 年的 WWDC 中，一個獨立的技術會議包含了以下這句至關重要的句子：

在 iOS 26 之後的版本中，任何使用最新 SDK 建置的 UIKit 應用程式都將被要求使用 UIScene 生命周期，否則將無法啟動。

感謝我們的輸入和我們（當時手動）的分類流程標記了該會議！

我們在 2025 年第三季度專注於設計和實施，並最終在第四季度開始測試我們的 UIScene 實施。一個實驗性標誌為喜歡冒險的 Flutter 開發人員解鎖了它，我們要非常感謝所有測試過的人，因為您們共同幫助我們找到了關鍵的邊緣情況、時間問題和其他怪癖。

到 2026 年 1 月，我們將重點轉移到幫助生態系統更新 iOS 外掛，因為它們的採用對於應用程式的健康也是必需的。在遷移了我們直接維護的每個外掛後，我們開始向社群外掛提交議題。值得慶幸的是，來自世界各地的外掛作者反應非常迅速，我們在更新所有內容方面得到了巨大的支持和團隊精神！

發佈此功能

Apple 的 UIScene API 的完整支援在 2026 年 2 月的 Flutter 3.41 穩定版本中推出。如果您從未聽過 UIScene，基本上不知道我們在說什麼——太好了！我們對成功的定義是，大多數 Flutter 開發人員將運行 flutter upgrade，繼續撰寫 Dart 程式碼，並且永遠不必考慮這個問題。（一些進階使用者，例如那些有「加入到應用程式」情境的人，確實有一個簡短但手動的遷移指南可以遵循。）

這項積極主動的工作帶來了巨大的回報，因為正如 Apple 所說，他們在 iOS 27 Beta 版中將該警告變成了斷言。但是，由於我們早期的努力，Flutter 在 iOS 27 甚至發布前幾個月就已準備就緒。

我們在沙漠中揮汗如雨；您享受甜蜜的甜點

Flutter 團隊的目標一如既往：找出應用程式開發中令人煩惱的部分，讓您可以專注於有趣的部分：建立功能、讓使用者滿意，以及發布出色的版本。無論是 iOS、Android，還是 Flutter 應用程式運行的許多其他平台，我們都希望您的建置目標仍然只是創造讓使用者愉悅的卓越體驗的另一個實作細節。

欲了解更多 Flutter 資訊，請觀看 本部落格文章的影片版本、我們的 文件、YouTube 頻道，或在社交媒體上找到我們。在此之前，我們迫不及待想看看您將建立什麼！

更多來自 Flutter

隆重推出 Flutter 桌面視窗化 API

了解新的桌面視窗化 API 背後的設計，並撰寫您的第一個多視窗 Flutter 應用程式。

Matthew Kosarek

2026 年 8 月 24 日 · 閱讀時間 9 分鐘

架構師、測試人員和程式設計師：建構多代理開發團隊

在 Antigravity 中運行的多代理開發團隊如何使用測試驅動開發將 Python 函式庫移植到慣用的 Dart 套件。

Andrew Brogdon

2026 年 8 月 20 日 · 閱讀時間 6 分鐘

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

原文：https://flutter.dev/blog/desktop-windowing-apis

介紹 Flutter 的桌面視窗化 API

了解新桌面視窗化 API 的設計，並編寫您的第一個多視窗 Flutter 應用程式。

Matthew Kosarek

Aug 24, 2026 · 9 min read

rss_feed

share

• content_copy複製連結

• 分享到 X
• 分享到 Bluesky
• 分享到 LinkedIn

Flutter 最初於 2018 年發布，支援兩個主要的行動平台：Android 和 iOS。從那時起，Flutter 的應用範圍已遠遠超出行動裝置，除了汽車中的資訊娛樂系統、智慧電視和嵌入式系統等自訂用例之外，還正式支援 Web、macOS、Linux 和 Windows。從行動應用程式工具包的卑微開端，Flutter 已成長為跨越廣泛裝置的第一流應用程式工具包。

但是，Flutter 作為行動工具包的一些遺留痕跡至今仍然存在。行動開發的一個特點是您不必繪製到多個視窗—視窗只佔據整個螢幕。與其獨立繪製特殊的「視窗」，例如彈出視窗和工具提示，不如將它們渲染為疊加在主視窗之上的圖層。對於行動用例，這是一個非常好的權衡。外形尺寸足夠小，以至於擁有多個獨立視窗對應用程式開發人員來說在可用性方面幾乎沒有任何好處。

然而，一旦 Flutter 發佈用於桌面，這種單視窗假設就成了一個問題。為了讓應用程式在桌面上感覺自在，它們必須利用大螢幕顯示器提供的螢幕空間。應用程式應該能夠根據需要繪製到任意數量的視窗中，更重要的是，甚至超出單個視窗的邊界進行繪製。當時，多視窗支援是 Flutter 中第六個最受歡迎的功能，這進一步證明了此功能的重要性。

當這一切發生時，我們 Canonical 正在忙於將 Flutter 整合到我們堆疊的關鍵任務部分，包括 Ubuntu 桌面安裝程式。此時我們已經承擔了 Flutter Linux Embedder 主要維護者的責任，並且我們越來越對 Flutter 中視窗化 API 的原生支援感興趣。因此，在 2024 年，我們決定與 Google 合作開發這個新的 API，由 Canonical 負責設計和實作，Google 則提供設計和程式碼審查支援。

視窗類型和階層

視窗化 API 的一個主要設計考量是如何使其跨平台。當應用程式開發人員可以自信地「一次編寫，隨處發布」時，Flutter 才能發揮最佳效能，我們希望設計一個能讓這件事盡可能容易的 API。這就是我們得出**視窗類型**概念的方式。

我們的設計圍繞五種視窗類型：常規、對話框、工具提示、彈出視窗和衛星。每種視窗類型都有特定的跨平台行為和用途。

**彈出**視窗提供下拉選單和文字自動完成框等功能。它們是其他視窗的子視窗，通常會根據其內容調整大小。重要的是，它們可以接收輸入焦點（例如，使用者可以使用箭頭鍵瀏覽下拉選單）。我們的實作還強制彈出視窗透過平移或縮小來保持在螢幕上可見，從而確保重要資訊永遠不會在螢幕外丟失。

**工具提示**視窗類似於彈出視窗，只是它們無法獲得輸入焦點。它們通常用於少量、轉瞬即逝的資訊。例如，信用卡資訊的輸入表單通常會包含一個 CVV 號碼輸入框，旁邊有一個小小的「資訊」圖示。當滑鼠懸停時，此圖示會彈出一個工具提示，解釋此資訊在您的卡片上的位置。此類小型的資訊視窗最適合實作為工具提示。

**對話框**視窗是子視窗，通常提示使用者採取行動。對話框視窗有兩種：模態和非模態。當對話框對另一個視窗是模態時，在對話框視窗關閉之前，該視窗無法獲得焦點。對話框視窗的一個常見範例是模態提示，要求使用者確認或取消刪除應用程式資源。

**衛星**視窗是輔助視窗，用於工具箱和其他輔助功能。它們的獨特之處在於，它們會隨著父視窗的移動和調整大小而保持相對於父視窗的位置。它們也可能同時是多個視窗的子視窗，而不僅僅是一個視窗，這樣工具欄就可以在多個主視窗之間共用。衛星通常也可以停靠，這意味著它們可以從浮動衛星視窗轉換為嵌入到主應用程式內容中。衛星視窗的一個範例是圖像編輯軟體（如 GIMP）中包含顏色選擇、工具選擇等的工具箱。

這些視窗類型存在於視窗階層中。例如，應用程式可以在其根目錄中包含一個主要、常規的視窗，該視窗具有作為子視窗的彈出視窗和對話框。然後，對話框可以在其內部嵌套一個工具提示。應用程式然後可以打開另一個根目錄中的常規視窗，並在該視窗內部嵌套另一個彈出視窗。透過這種方式，構建了一個視窗階層。實際上，這個階層應該相當淺，但是您不應因具有深層階層而產生任何效能成本。

這個設計並非武斷選擇。Canonical 在過去二十年大部分時間都在發布具有各種複雜應用程式的桌面。透過我們的研究，我們發現這五種主要類型在大多數應用程式中都是基礎，因此應該在此 API 中獲得一流的支援。最棒的是，作為開發人員，您可以放心地在所有主要桌面平台上發布這些視窗類型，因為您知道行為將始終一致。

然而，我們認識到確實會出現獨特的情況。因此，我們始終提供一個「逃生艙口」，您可以透過它為您的特定平台建構和修改自己的原生視窗。雖然這不是推薦的方法，但在需要時它可能是一個強大的工具。

探索 API

視窗化 API 目前可在 Flutter 「main」頻道上使用。請注意，這些 API 隱藏在一個實驗性功能標誌之後，因此可能會更改。

若要啟用視窗化 API，請運行以下命令：

flutter channel main
flutter upgrade
flutter config --enable-windowing

content_copy

建立和修改原生視窗

若要建立視窗，我們首先建立一個 `WindowController`。控制器與底層平台互動以建立和更新視窗。

dart

final controller = WindowController(
 title: 'My Application',
 size: const Size(800, 600),
);

content_copy

控制器提供了視窗的初始配置，在本例中包括大小和標題。請注意，這些引數可能不會被平台遵守。例如，如果螢幕不夠大以容納請求的大小，平台可以選擇較小的視窗大小。

每種視窗類型都有自己的視窗控制器，它接收不同的參數。例如，要建立一個對話框視窗而不是一個常規視窗，看起來像這樣：

dart

final dialogController = DialogWindowController(
 title: 'My Dialog',
 size: const Size)(400, 300),
 parent: parentController,
);

content_copy

與常規視窗不同，DialogWindowController 在其建構函式中接受一個可選的父視窗控制器。

一旦控制器建立，以後可以用它來修改視窗。例如，我們可以修改之前建立的常規視窗的標題或大小，甚至銷毀它：

dart

controller.setTitle('Hello, world!');
controller.setSize(const Size.square)(1000));
controller.destroy)();

content_copy

渲染到原生視窗中

現在我們知道如何建立和更新我們的原生視窗了，是時候在裡面渲染一些東西了。為此，我們將控制器和要渲染的內容傳遞給 `Window` Widget：

dart

Widget build(BuildContext context) {
 return Window(
 controller: controller,
 child: MyPage(),
);
}

content_copy

每種視窗類型都有其對應的 Widget。對於常規視窗，我們使用 Window Widget，但對於對話框視窗，我們將使用 DialogWindow Widget。

值得注意的是，所有視窗都在一個 Widget 樹中。這意味著您可以無需任何額外工作即可在視窗之間共享狀態。現有的狀態管理套件（如 Riverpod 或 Bloc）可以直接使用！

監聽原生視窗上的事件

現在我們知道如何建立原生視窗並在其中渲染內容了，還有一個難題需要解決：我們如何從系統接收關於視窗的通知？這可以透過兩種方式實現：透過視窗控制器委派和 WindowScope。

WindowControllerDelegate 會通知我們重要的生命週期事件，例如視窗被銷毀或系統要求我們銷毀視窗。我們透過覆蓋委派控制器來實現委派。例如：

dart

// Create the class first...
class MyWindowDelegate with WindowControllerDelegate {
 @override
 void onWindowDestroyed() {
 super.onWindowDestroyed)();
 ServicesBinding.instance.exitApplication)(AppExitType.required);
 }
}
​
// and then pass it to the controller constructor.
final controller = WindowController(
 title: 'My Application',
 size: const Size)(800, 600),
 delegate: MyWindowDelegate)(),
);

content_copy

此委派在視窗被銷毀時退出應用程式，這通常是應用程式主要視窗的適當實作。

我們可以借助 WindowScope 監聽有關視窗的不那麼關鍵的資訊，這是每個 Window Widget 建立的 InheritedModel。嵌套在視窗中的 Widget 可以使用 WindowScope.of 來存取範圍。或者，它們可以使用 WindowScope 上各種特定欄位的存取器來監聽視窗的特定欄位。例如，如果 Widget 對視窗的標題感興趣，它可以這樣做：

dart

class MyWidget extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 final title = WindowScope.titleOf)(context);
 // ... do something with the window title
 }
}

content_copy

每當視窗標題變更時，這個 Widget 現在都會重新渲染。

「Hello, Window」範例

現在我們了解了 API 及其背後的原理，以下這個獨立的「Hello, Window」範例應用程式應該完全可以理解。請隨意複製並貼上到您自己的 Flutter 專案中，自行嘗試：

dart

// ignore_for_file: invalid_use_of_internal_member
// ignore_for_file: implementation_imports
​
import 'dart:ui';
​
import 'package:flutter/services.dart';
import 'package:flutter/src/widgets/_window.dart';
import 'package:flutter/widgets.dart';
​
/// Exits the application when the user closes the window.
class ExitOnCloseDelegate with WindowControllerDelegate {
 @override
 void onWindowCloseRequested(WindowController controller) {
 ServicesBinding.instance.exitApplication)(AppExitType.required);
 }
}
​
void main() 下載 {
 WidgetsFlutterBinding.ensureInitialized)();
 runWidget)(const HelloWindow)();
}
​
/// Displays a window and owns its [WindowController].
class HelloWindow extends StatefulWidget {
 const HelloWindow({super.key});
​
 @override
 State<HelloWindow> createState() => _HelloWindowState)();
}
​
class _HelloWindowState extends State<HelloWindow> {
 final WindowController _controller = WindowController(
 size: const Size)(600, 400),
 title: 'MyApp',
 delegate: ExitOnCloseDelegate)(),
);
​
 @override
 void dispose() >{
 _controller.dispose)();
 super.dispose)();
 }
​
 @override
 Widget build(BuildContext context) >{
 return Window(
 controller: _controller,
 child: const Directionality(
 textDirection: TextDirection.ltr,
 child: ColoredBox(
 color: Color(0xFFFFFFFF),
 child: Center(
 child: Text(
 'Hello, Window下載,
 style: TextStyle(color: Color(0xFF000000), fontSize: 24),
 ),
 ),
 ),
 );
 }
}

content_copy

這個範例最棒的地方在於，它無需您額外的工作，即可在所有主要的桌面平台開箱即用。

關於上述範例，需要注意的一件重要事情是，我們不再使用 runApp 函數來渲染我們的根 Widget，因為該函數會將 Widget 附加到由平台隱式建立的視圖。相反，我們使用 runWidget 並向其提供我們自己的視圖，即我們的 Window。

設計系統整合

需要注意的一個重要點是，從長遠來看，大多數視窗化 API 的使用者不會明確地與其互動。相反，它將由現有的設計系統在幕後整合。透過選擇設計系統，您將開箱即用地獲得所有精美的視窗功能。

具體來說，團隊目前正努力將新的視窗化 API 整合到 Material 設計系統中。我們計劃整合的項目有：

• showDialog
• showMenu
• Tooltip

當平台提供這些方法時，它們都將使用真正的原生視窗。當平台上無法使用視窗化 API 時（例如行動裝置），我們將回溯到現有的實作。該 API 還將提供在需要時完全退出視窗化的方法。

結論

視窗化 API 是 Canonical 和 Google 多年設計和工程的成果，我們非常興奮最終能將其交到您的手中。如果您有興趣查看更複雜的多視窗應用程式是什麼樣子，請查看https://flutter.dev/to/windowing-example。

我們期待看到您的作品！

更多 Flutter 資訊

架構師、測試人員和程式設計師：建立多代理開發團隊

在 Antigravity 中運行的多代理開發團隊如何使用測試驅動開發將 Python 函式庫移植到慣用的 Dart 套件。

Andrew Brogdon

Aug 20, 2026 · 6 分鐘閱讀

使用非同步 A2UI 加速生成式 UI

了解如何預先生成和快取 A2UI 訊息，以消除啟動延遲並在 Flutter 中建立即時、回應式的生成式 UI。

Andrew Brogdon

Aug 13, 2026 · 7 分鐘閱讀