Flutter 3.44 发布：一篇看懂所有重点变化

Simi 收录于 App

2026-05-24 约 12343 字预计阅读 25 分钟

Flutter 3.44 已经发布。这是 Google I/O 2026 前后 Flutter 最重要的一次版本更新，不是简单的 maintenance release，也不只是“新增几个组件、修几个 bug”。

这次版本真正重要的地方在于：Flutter 同时在多个方向调整自己的定位。

开发工作流开始面向 coding agent，核心能力包括 MCP、Agentic Hot Reload、Dart/Flutter Agent Skills。
iOS 和 macOS 依赖管理开始从 CocoaPods 迁移到 Swift Package Manager。
Android 原生 View 嵌入迎来新的渲染路径 Hybrid Composition++。
Flutter Desktop 由 Canonical 承担更明确的维护和路线图角色。
Material 和 Cupertino 从核心框架中冻结，准备迁移为独立版本化包。
Impeller、Web、可访问性、Widget Previews、DevTools、构建工具链都有实际改进。
Toyota RAV4 和 LG webOS 让 Flutter 的嵌入式场景变得更具体。

如果只用一句话总结 Flutter 3.44：Flutter 正在从一个 mobile-first 的跨平台 UI framework，变成一个面向 AI 辅助开发、嵌入式设备、桌面、Web 和原生平台集成的应用平台。

发布背景

Flutter 3.44 是 Google I/O 2026 期间发布的版本。Google I/O 官方 “What’s new in Flutter” 专场安排在 2026 年 5 月 20 日，官方 Flutter 博客给这次发布定的主题是：

Flutter is everywhere, everyday, built by everyone, for everyone.

官方文章里给出了一组很关键的数据：

pub.dev 在过去 30 天内有超过 13 亿次 package 下载。
Flutter 是两大主流应用商店里 第二受欢迎的移动开发 SDK。
Flutter 有超过 150 万月活开发者，一年增长 50%。
Flutter 生态有 1700+ contributors。
过去一年 Flutter core repository 合入了 5800 次变更。
3.44 这个 release cycle 中有 178 位 contributors 提交了 972 个 commits，其中 61 位是首次贡献者。

这些数据不是宣传口号。这组数据解释了为什么 Flutter 3.44 的重点不是“再做一个漂亮控件”，而是围绕生态、工具链、平台支持、治理和长期可维护性展开。

过去几年 Flutter 最大的问题并不是“能不能画 UI”。真正的问题是：这个生态是否足够稳定、工具是否足够成熟、平台支持是否足够深入、长期产品是否可以放心押注。Flutter 3.44 明显是在回应这些问题。

快速总览

先把重点压缩成一版。

对日常 Flutter 开发者来说，最直接的变化是 Agentic Hot Reload、Widget Previews 改进、DevTools 变快、Apple Silicon 不再需要 Rosetta、SwiftPM 成为 iOS/macOS 默认依赖管理方式，以及 Material、Cupertino、可访问性、文本选择、布局稳定性等细节优化。

对移动团队来说，最重要的是 SwiftPM、UIScene 迁移压力、iOS predictive text、Android Hybrid Composition++、Android 17 准备、AGP 9/Kotlin 构建变化、Android display corner radii、ABI filtering 行为变化。

对 Web 团队来说，重点是可访问性、Safari autofill、滚动、键盘事件合成、Skwasm/CanvasKit 稳定性，以及 flutter run --base-href。

对桌面团队来说，Canonical 成为 Flutter Desktop lead maintainer 和 Strategic Steward，比单个 API 更重要。实验性的 windowing APIs、tooltip windows、popup windows、dialog windows、Linux content-sized views、Windows stylus support 都说明桌面路线在继续推进。

对框架架构来说，Material 和 Cupertino 在核心框架中冻结，是这次最重要的长期变化。后续会迁移为独立包：material_ui 和 cupertino_ui。

对图形密集型应用来说，需要关注 Impeller Vulkan、SDF 圆形渲染、perspective/shadow 修复、FragmentShader 按名称绑定 uniform、shader compiler 诊断改进。

对关注 AI 的产品团队来说，Flutter 3.44 释放了非常强的信号：Agentic Hot Reload、Dart/Flutter Agent Skills、Firebase AI Logic、Server Prompt Templates、Firebase Agent Skills、Genkit Dart preview、LiteRT-LM for Flutter、GenUI、A2UI。

1. Agentic Hot Reload：Flutter 开始适配 Coding Agent

Flutter 3.44 最重要的开发体验功能是 Agentic Hot Reload。

传统 Flutter Hot Reload 已经是 Flutter 最强的生产力特性之一：修改 Dart 代码，不重启应用，直接刷新运行中的界面。3.44 的新变化是：coding agent 可以更直接地参与这个循环。

Flutter MCP server 现在可以自动发现并连接到正在运行的 Dart / Flutter 应用。coding agent 修改 UI 代码后，可以自动触发 hot reload。官方文章里提到了 Antigravity、Gemini CLI、Claude Code、Cursor 等 agent 工具，这说明 Flutter 团队已经明确把 agent-based development 当成现实开发方式来支持。

以前的工作流通常是这样：

        
        
        
    
让 agent 修改 UI 代码。
审查或应用 patch。
切到终端或 IDE。
手动触发 hot reload。
查看效果。
继续改。

Agentic Hot Reload 之后，工作流变成：

        
让 agent 修改 UI 代码。
agent 改代码。
agent 自动触发 hot reload。
运行中的应用立即呈现结果。

这不是一个“省一次按键”的功能。UI 开发的瓶颈就是反馈回路。如果 agent 改完代码之后能马上把结果刷到运行中的应用里，AI 辅助 UI iteration 的可用性会明显提升。

Flutter 3.44 还补了两个配套能力：

Hardened dependency search：agent 可以安全读取和搜索 package dependencies 里的文件，不需要完整访问本地 pub cache。
Consolidated MCP tool definitions：合并 MCP tool definitions，减少 agent workflow 的 token 成本。

第二点很工程化。agent 工具如果 schema 太多、太碎、太重复，长会话里很容易浪费上下文。Flutter 现在开始优化这类细节，说明这不是一次演示型功能，而是在认真补齐工具链。

2. Dart 和 Flutter Agent Skills

Flutter 3.44 不只是让 agent 能操作运行中的应用，还发布了 Dart and Flutter Agent Skills。

这些 skills 本质上是给 coding agent 的任务级指导。官方举的例子包括：添加 integration tests、配置 localization，同时遵循 Flutter 推荐实践。

这点很重要，因为通用 coding agent 往往“会写 Flutter 语法”，但未必知道项目级规范：

integration tests 应该放在哪里，
localization 应该怎么接，
platform folders 哪些文件能改、哪些要谨慎，
generated files 如何处理，
哪些重构是低价值甚至危险的。

Agent Skills 的目标是把这些任务知识结构化，让 agent 行为更可预测，而不是完全依赖模型记忆。

对团队来说，这意味着：未来一个严肃的 Flutter 开发环境，可能不只包括 SDK 版本、IDE 插件、CI、lint rules，还会包括 agent skills。

3. AI 原生应用：Firebase AI Logic、Genkit Dart、Gemma、LiteRT-LM、GenUI

Flutter 3.44 用了很大篇幅讲 AI-native apps。这不是一个单点功能，而是生态方向。

Firebase AI Logic

Firebase AI Logic 让 Flutter 应用可以从客户端调用 Gemini API。官方例子是 MacroFactor：一个用 Flutter 构建的营养追踪应用，通过 Firebase AI Logic 连接 Gemini 模型，用多模态能力辅助记录饮食。

这次值得注意的新点是 Server Prompt Templates。这项能力可以避免把 prompt 直接写进应用代码里。

这对生产应用很关键：

prompt 可以迭代，不必每次都发版；
多端 prompt 逻辑更容易统一；
减少 prompt 暴露在客户端二进制里的风险；
产品逻辑更容易治理和审计。

Firebase Agent Skills for Flutter 也已经可用，用来指导 agent 更有效地构建 Flutter + Firebase 全栈应用。

Genkit Dart Preview

Genkit Dart 进入 preview。这个开源框架面向 full-stack AI 和 agentic apps。

关键能力包括：

model-agnostic API；
支持 Google、Anthropic、OpenAI 等 provider；
type-safe structured output；
tool calling；
multi-turn conversations；
built-in observability；
可以 server-side 使用，也可以在 Flutter apps 中 client-side 使用。

对 Flutter 团队来说，重点不是“Dart 也能调用 LLM”这么简单。重点是 Genkit 把 agentic application patterns 带进 Dart 生态，而且包含 observability、structured output 这类生产化能力。

Gemma、LiteRT-LM 和端侧 AI

官方文章也强调了 Gemma 相关工作。Flutter 开发者在 Gemma 3n Impact Challenge 中拿到第一和第二：

Gemma Vision 帮助视觉障碍用户感知世界；
Vite Vere 帮助认知障碍用户完成日常任务。

两者都用 Flutter 构建 AI 辅助体验。

官方还提到了 Gemma 4 和 LiteRT-LM for Flutter。LiteRT-LM 是 Google 的 production-ready、高性能、开源推理框架。Flutter 侧会通过 flutter_gemma package 提供完整支持。

目标很清楚：让 Flutter 在六个 stable platforms 上运行端侧 AI 模型，并尽可能利用 GPU / NPU 加速：

Android；
iOS；
Web；
Windows；
Linux；
macOS。

这对隐私、延迟、成本、离线能力敏感的应用非常重要。不是所有 AI 功能都适合云端推理，Flutter 需要一条可信的本地推理路径。

GenUI 和 A2UI

Flutter 3.44 还重点讲了 Generative UI，也就是 GenUI。

核心思想是：AI 不应该永远只返回纯文本或 Markdown。在某些体验里，agent 应该能够动态构造交互式 UI。Flutter 正在参与 A2UI protocol 的建设，这是 Google 推出的开源协议，用来定义 agent 和 client 如何协作完成 UI composition 和 state 管理。

官方提到的例子包括：

Hatcha：社交活动规划 demo，通过对话输入生成主题邀请函和规划模块；
Gemini app 的 Visual Layout experiment：用户通过动态生成的信息布局进行探索；
Finnish it：根据学习内容动态组合课程 UI 的语言学习应用。

Visual Layout experiment 给出的三条经验也很实用：

使用 opinionated frameworks 保持 AI 输出一致性；
使用 AI critic loop 提高可靠性；
用 templates 在速度和控制之间找平衡。

第三点尤其重要。生产环境不太可能让 AI 每次都完全自由生成 UI。更现实的路径是：AI 选择、配置、组合受控 UI primitives，而不是随意生成不可控界面。

4. DevTools 和 Analysis：大型项目里的日常摩擦变少

Flutter 3.44 改进了开发环境，尤其是大型项目会感受到的地方。

DevTools 现在默认使用 WASM，官方说这会让 DevTools 更快、更顺滑。同时，DevTools 和 analysis workflow 也有性能和稳定性改进。

release notes 里还可以看到 flutter analyze 迁移到 LSP 的工作。这类变化不适合做发布会 headline，但对大型代码库非常重要。analysis 是编辑循环的一部分，分析慢、卡、误报，都会直接拖慢开发效率。

这次 tooling 里还包括：

修复 web application 启动时的 DartDevelopmentServiceException 处理；
确保升级时重新生成 flutter.version.json；
修复 flutter run -d all 崩溃；
修复 flutter build web 忽略 --web-define；
改善多个命令行细节。

整体看，Flutter 3.44 在减少日常工具摩擦，而不只是做可见功能。

Widget Previews 仍然是 experimental，但 Flutter 3.44 让这项能力更接近真实项目可用。

最大变化是 preview detection 改为使用 Dart Analysis Server。官方说这可以让 IDE 用户整体内存占用最多减少 50%。

这很关键，因为 preview 工具在实践里经常不是因为功能不对而失败，而是因为：

占用太多内存；
扫描太多代码；
大项目里变慢；
preview 太多，不好找。

Flutter 3.44 还支持按以下维度过滤 preview：

group；
name；
script URI；
package URI。

release notes 里还提到一些 preview 修复，例如：

@Preview annotations 出现在 lib/ 之外时不再崩溃；
custom preview annotations 支持 collections 和 records；
widget preview scaffold 增加搜索和过滤。

对 design system 团队来说，这是一个值得持续关注的方向。如果 Widget Previews 最终稳定且轻量，Flutter 会更接近 Web 团队熟悉的 Storybook 式组件开发体验。

6. Apple Silicon：不再需要 Rosetta

Flutter 3.44 清理了 Mac 开发环境里的一个历史包袱：所有 macOS command-line tools，包括 iOS device communication binaries，现在都可以原生运行在 Apple Silicon 上。

这意味着 Apple Silicon 开发者不再需要为了 Flutter tooling 安装 Rosetta。

这不只是方便。Apple 本身也在逐步把 Rosetta 当作过渡方案，而不是长期兼容层。Flutter 官方文章还明确提醒：未来某个 Flutter release 会完全结束对 Intel x86 Macs 的支持。

仍在使用 Intel Mac 开发机或 CI host 的团队，现在就应该开始规划迁移。

7. Android：Hybrid Composition++ 是 Platform Views 的大升级

Flutter 3.44 在 Android 上最大的 runtime feature 是 Hybrid Composition++，简称 HCPP。

HCPP 解决的是 Flutter 长期存在的一个难题：在 Flutter 应用里嵌入原生 Android Views。

典型场景包括：

WebView；
地图；
视频 view；
相机 preview；
广告 view；
支付 SDK view；
私有 Android 原生 UI 组件。

过去 Android platform views 经常需要在性能和保真度之间做取舍。旧方案可能遇到：

滚动时 screen tearing；
text input 不稳定；
CPU 开销高；
SurfaceView 支持麻烦；
Flutter layer 和 native view 之间视觉不同步。

HCPP 改变了 composition model。新方案不再依赖 offscreen buffers，也不强迫 Flutter engine 自己处理 native views，而是把 layer compositing 更直接地交给 Android OS。底层利用 Vulkan、hardware buffer swapchains、SurfaceControl transactions 来同步 Flutter UI 和原生 Android views。

预期收益包括：

更高性能的滚动；
更准确的 touch input；
更可靠的 SurfaceView 支持；
更少 composition artifacts。

在 Flutter 3.44 中，HCPP 是 opt-in。可以这样测试：

flutter run --enable-hcpp

也可以在 AndroidManifest.xml 中开启：

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

注意：HCPP 有 Android API 和硬件要求，不是所有设备都能使用。生产团队应该在真实设备上测试，尤其是依赖 WebView、地图、广告、视频、相机、支付 SDK 的应用。

官方还提到，HCPP 可以在未来成为默认渲染模式之前提前测试。这是很明确的迁移信号：今天不用全量打开，但现在就应该开始验证。

8. Android 17、Googlebook、Display Corner Radii、AGP 9、ABI Filtering

Flutter 3.44 还有一组 Android 平台和构建系统变化。

Googlebook 和大屏 Android

官方文章说 Flutter 已经可以适配新的 Googlebook laptop。重点不是某个 Flutter API，而是平台定位：只要 Flutter app 遵循 Android large-screen guidelines，就可以更自然地处理 trackpad scrolling、mouse hover、right-click menus、keyboard shortcuts 等输入模式。

这提醒了一个关键事实：Android 不再只是手机 UI。Flutter 团队已经在考虑 Android tablets、foldables、类 laptop 设备，以及桌面化输入。

Android 17

Flutter 团队正在针对 Android 17 betas 做测试。官方特别提到：

Local Network Protections；
safe Dynamic Code Loading；
与即将到来的 Android 变更保持兼容。

发布 Android 应用的团队，现在就应该把 Android 17 beta 纳入测试，而不是等正式版出来再处理。

Display Corner Radii

Flutter 现在可以查询 Android 设备屏幕的 physical 和 logical corner radii，并通过 MediaQuery 暴露出来。

这对全屏布局很重要，可以避免内容被圆角屏幕裁掉。对游戏、相机、媒体、kiosk、自定义 shell、沉浸式 UI 都有实际意义。

Android Gradle Plugin 9 和 Built-In Kotlin

AGP 9 改变了 Kotlin 处理方式。AGP 9 之前，Android app 和 plugin 常常需要手动添加 Kotlin Gradle plugin。AGP 9 开始 Android build system 原生理解 Kotlin，继续手动添加独立 KGP 可能会冲突并导致构建失败。

Flutter 3.44 加了临时 backwards compatibility，但方向很明确：

app developers 应该更新 Android build files，移除不再需要的独立 KGP；
plugin authors 也要做类似 Gradle 调整；
plugin authors 采用新行为时，pubspec.yaml 里的最低 Flutter version constraint 应设为 3.44；
手动应用 KGP 的兼容支持未来会移除。

这是最容易影响真实项目升级的部分之一，尤其是依赖老插件的应用。

ABI Filtering

Flutter 以前会针对每个 build type 程序化设置 ABI filters。3.44 改为在 base defaultConfig block 中统一配置。

AGP 9 会把 default config 和 build types/flavors 合并，而不是简单覆盖。所以如果 app 在 build types 或 product flavors 里自定义了 abiFilters，可能需要在构建或运行时传：

-Pdisable-abi-filtering=true

这是一个看起来很边缘、但很容易让 CI 挂掉的细节。使用 product flavors、自定义 CPU 架构目标、或 release/debug ABI 行为不同的项目，都要重点测试。

9. iOS 和 macOS：Swift Package Manager 成为默认方案

Flutter 3.44 在 Apple 平台上最大的变化是：Swift Package Manager 成为 iOS 和 macOS apps 的默认依赖管理器。

这是本次发布最实用的变化之一。

过去 Flutter iOS 生态长期依赖 CocoaPods。CocoaPods 能用，但也把 Ruby 环境、gem 版本、本机配置、CI 镜像、pod install 失败等问题带进了很多本来不使用 Ruby 的项目。

从 Flutter 3.44 开始：

Flutter CLI 在 build 或 run 时会自动更新 Xcode project 使用 SwiftPM；
常规路径下不再需要管理 Ruby 或 CocoaPods；
add-to-app 项目新增 flutter build swift-package；
Flutter app 或 add-to-app module 可以打包成 Swift Package，供原生 iOS 项目使用。

如果应用依赖仍然需要 CocoaPods 的插件，Flutter CLI 会打印 warning，并临时 fallback 到 CocoaPods。这很重要，但不能当作长期方案。官方明确说 CocoaPods support 最终会完全移除。

plugin authors 需要为 package 增加 SwiftPM support。支持 SwiftPM 的 package 现在还会获得额外 pub.dev scoring points，这会推动生态迁移。

临时 opt-out 可以这样写：

        
flutter:
  config:
    enable-swift-package-manager: false

但官方已经说这个 opt-out 也会在未来移除。如果 SwiftPM 让项目出现 breaking issue，建议提交 bug 并附上 Xcode project files。

生产团队升级时应该检查：

所有 iOS/macOS plugins 是否支持 SwiftPM；
clean checkout build 是否成功；
CI 是否还隐含依赖 CocoaPods；
add-to-app 流程是否受影响；
哪些 plugin 会触发 CocoaPods fallback；
是否需要临时 opt-out；
upstream plugin issue 是否需要提前报。

10. UIScene 和 iOS Predictive Text

Flutter 3.44 没有引入一个全新的 UIScene API，但官方再次强调：Apple 正在要求使用最新 SDK 构建的应用迁移到 UIScene lifecycle。

如果 AppDelegate 没有被自定义，Flutter CLI 可以自动迁移。改过生命周期、deep links、push notifications、external displays、scene/window 行为的应用，需要手动按 migration guide 检查。

这类事情很容易被忽略，因为这不是新功能。但未来可能变成 App Store 发布阻塞点。

Flutter 3.44 还加入了 experimental native iOS inline predictive text support。默认关闭，可以通过：

        
TextField.enableInlinePrediction

开启后，输入框可以接受 iOS 预测文本。官方也说明视觉样式还在 polish，所以该能力适合先在真实输入场景里测试，不适合盲目全局开启。

11. Web：可访问性、Safari Autofill、键盘事件、Skwasm、`--base-href`

Flutter Web 在 3.44 里没有一个单独的大 headline，但有多项生产应用会关心的改进。

可访问性

Flutter Web 对浏览器用户偏好和可访问性行为的支持更好：

支持浏览器 prefers-reduced-motion，自动禁用动画；
表单校验错误可以通过 aria-description 立即反馈给 screen reader；
non-interactive leaf semantics nodes 处理更合理；
accessibility features 内部逻辑更清晰。

Flutter Web 经常被批评“不够像普通 Web 平台公民”。这些可访问性改进就是在补这类短板。

浏览器和平台行为

engine 改进了 iOS 26 Safari autofill，通过在 focus shifts 之间复用 DOM forms 提升稳定性。Web scrolling 和 keyboard event synthesis 也有改进。

release notes 里还包括：

修复 key-up events 过早合成；
修复偶发找不到 Chrome tab；
修复 Skwasm 处理 non-transferable texture sources 时崩溃；
处理 asynchronously disposed platform views；
统一 CanvasKit 和 Skwasm garbage collection；
提升 web rendering concurrency 和 stability。

Tooling

flutter run 现在支持 web 的 --base-href。这让本地运行可以更接近生产环境里部署到子路径的场景。

release notes 还提到修复 flutter build web 忽略 --web-define 的问题。

Flutter Web 团队升级时不要只打开首页看一眼。应该测试：

reduced-motion；
表单错误的 screen reader 反馈；
Safari autofill；
键盘输入；
生产路径下的 deep links 和 base href；
platform views；
CanvasKit/Skwasm；
文本选择和多行复制。

12. Desktop：Canonical 承担更明确角色

Flutter 3.44 在 Desktop 上最重要的不是某个单独 API，而是治理结构变化：Canonical 成为 Flutter Desktop 的 lead maintainer 和 Strategic Steward。

Canonical 将负责 Flutter Desktop roadmap，并维护 Linux、Windows、macOS embedders。

这很重要，因为 desktop support 不是“能跑起来”就够了。真正成熟的桌面支持需要长期投入：

embedders；
windowing；
input；
accessibility；
packaging；
平台约定；
native integration。

有明确的 strategic steward，会让桌面路线更可信。

Experimental Windowing APIs

Flutter 的 experimental windowing APIs 继续推进，但官方说明很清楚：目前只在 main channel 可用，不适合生产。

新增能力包括：

Linux、macOS、Windows 上的 tooltip windows；
macOS popup windows，Linux 和 Windows 后续支持；
支持 windowing 的平台上，Material showDialog 创建独立 child dialog window；
Linux content-sized views。

这对桌面应用很重要。成熟桌面应用不能永远只有一个全屏 canvas。此类应用需要 menus、popups、tooltips、child dialogs、floating panels 和更原生的 window behavior。

Windows Stylus Support

Flutter Windows 现在支持 stylus input，包括 stylus rotation 和 pressure sensitivity。

这对以下应用有价值：

绘图；
笔记；
白板；
设计工具；
教育软件；
签名采集；
Windows tablet 上的 field workflows。

这也是 Flutter Desktop 从“能启动”走向“更深入平台输入能力”的信号。

13. Embedded：Toyota RAV4 和 LG webOS

Flutter 3.44 让 Flutter embedded story 更具体了。

Toyota RAV4

官方文章说 2026 Toyota RAV4 使用 Flutter 驱动 multimedia system。这个案例很重要，因为汽车系统和手机 app 的约束完全不同：

硬件生命周期长；
性能要求稳定；
UX 接近安全相关场景；
更新周期慢；
车厂集成复杂；
多屏幕尺寸和多输入方式。

Flutter 出现在高销量车型的多媒体系统里，是一个很强的 embedded credibility 信号。

LG webOS

LG 即将推出 webOS SDK，让开发者可以用 Flutter 构建 webOS 设备应用。SDK 预计会包括 Firebase、video players、gamepads 等 plugin support，并保留 Flutter 熟悉的 stateful hot reload 和 Riverpod 状态管理能力。

这很关键，因为 TV 和 living-room devices 不是“放大版 Web 页面”。此类设备需要 remote input、media playback、focus handling、性能约束、平台插件支持。

Toyota 和 LG 放在一起看，说明 Flutter 正在进入更多原本 UI 技术栈高度碎片化的设备类型。

14. Graphics 和 Engine：Impeller、Vulkan、SDF、Fragment Shaders

Flutter 3.44 包含一组有针对性的渲染和性能改进，重点围绕 Impeller。

Vulkan 改进

这次包括更好的 cache memory management，以及在丢帧场景下更高效的 GPU/CPU synchronization。

这对以下应用很重要：

地图；
图表；
游戏；
动画密集界面；
视频周边 UI；
custom painting；
embedded displays。

丢帧不仅是视觉问题。如果同步机制不好，恢复过程也会变差，造成连续 jank。

使用 SDF 渲染更干净的圆形

Flutter 更新了圆形渲染数学，使用 signed-distance functions 得到更干净的 anti-aliased circles。以前某些情况下圆形边缘可能 aliasing，现在修复了。

听起来很小，但 UI framework 的视觉质感经常就是这些小细节堆出来的。按钮、头像、指示器、图表、遮罩、装饰元素都依赖干净的几何渲染。

Shadow 和 Perspective 修复

Impeller 改进了 perspective matrices、shadows、perspective projection transforms 的处理。

使用 transforms、类 3D 效果、重 shadow surface、自定义渲染的应用，需要重点回归测试这部分。

FragmentShader 改进

Fragment shader setup 现在更直观，可以按名称绑定 uniform，而不是手动记 offset：

        
void setUp(ui.FragmentShader shader) {
  shader.getUniformFloat('foobar').set(1.234);
}

这能减少一类很烦的 shader bug：Dart 侧 offset 和 shader 侧 uniform declaration 不一致。

shader compiler 现在还会在 shader 不兼容 Skia 时给出 warning，帮助团队在发布前发现跨平台渲染问题。

15. Framework：Material 和 Cupertino 开始解耦

Flutter 3.44 最大的长期 framework 变化，是核心框架中的 Material 和 Cupertino 已经冻结。

官方文章说，这是 Material 和 Cupertino 在 core framework 中的最后一批更新。接下来会迁移为独立包：

material_ui；
cupertino_ui。

到下一个 stable release，当前 framework 内的版本会进入 deprecation 路径，团队可以迁移到独立版本化 packages。

这件事的战略意义很大。

现在 Flutter framework upgrade 和 design-system-library upgrade 绑定得很紧。Material 和 Cupertino 独立之后，可以按各自节奏演进。Flutter core 可以更小，耦合更低，UI libraries 也可以更灵活地发布。

对大多数 app 来说，这不是今天就要立刻迁移的事情，但现在应该开始准备：

搜索 package:flutter/material.dart 和 package:flutter/cupertino.dart 的直接依赖；
识别内部 design-system wrappers；
避免依赖实现细节；
跟踪 package migration guidance；
deprecation warning 出现时尽早处理。

最后一批 Core Framework 内更新

虽然 Material 和 Cupertino 在 core framework 中冻结，但 3.44 仍包含不少 refinement：

基于 RawMenuAnchor 的 CupertinoMenuAnchor；
MenuAnchor 支持 Material 3 animations；
SubmenuButton.hoverOpenDelay；
CupertinoSheetRoute 中 scrollable content 和 dragging animation 更好协同；
scrollableBuilder 支持自定义 sheet scroll behavior；
CarouselView 支持 infinite scrolling；
CarouselView.onIndexChanged；
carousel controller 的 leadingItem；
ShapedInputBorder；
ThemeMode.isDark、ThemeMode.isLight、ThemeMode.isSystem；
NavigationRail.mainAxisAlignment；
DropdownMenu.scrollPadding；
Material widgets 的 assertions 和 semantics 修复。

对普通应用来说，这些是渐进式 API 和 polish。对框架架构来说，package split 才是大事。

16. 可访问性和布局稳定性

Flutter 3.44 在 accessibility 和 layout resilience 上做了大量细节工作。

iOS Motion 和用户偏好

Flutter 通过 AccessibilityFeatures 暴露更多 iOS accessibility preferences，包括：

reduced motion；
cross-fade preference；
禁止 animated image auto-play；
禁止 video preview auto-play；
prefer non-blinking cursor。

这些能力让 app 可以尊重用户偏好，而不是强制播放动画或闪烁光标。

Progress 和 Slider Semantics

ProgressIndicator 的 SemanticsValue 现在可以使用 "50%" 这类百分比字符串，让 screen reader 读出更自然的人类可读进度。

Slider 的 semantics node 也被改进，更准确反映 size 和 position，对依赖 touch exploration 或辅助设备的用户更友好。

Scroll 和 Invisible Semantics 修复

Flutter 修复了 invisible accessibility elements 在 scrollable content 之前错误出现的问题。辅助技术导航会更可预测。

这次 release 对零宽或零高环境下的 widget 稳定性做了大量修复。以前某些 widget 在 0x0 约束下可能崩溃或触发布局错误。

release notes 里可以看到涉及的 widget 很多，包括：

EditableText；
Container；
Expansible；
CupertinoTabScaffold；
FlutterLogo；
LongPressDraggable；
DisplayFeatureSubScreen；
DragTarget；
FormField；
Banner；
ErrorWidget；
FocusScope；
Hero；
Icon；
AnimatedPadding；
GridPaper。

这对复杂布局、转场、测试、preview、自适应 UI、临时 measurement 场景都很重要。

SelectableRegion 修复

SelectableRegion 有两个关键修复：

Web 上不再让 children 意外 shrink，会原样传递 layout constraints；
多行文本选择复制时保留 line breaks。

文本选择是基础交互。文档应用、后台系统、编辑器、聊天应用、数据密集型界面都会受益。

17. Breaking Changes 和 Deprecations

Flutter 3.44 有几类需要放进升级 checklist 的变化。

RawMenuAnchor Callback Order

RawMenuAnchor 的部分 callback 调用顺序调整了，目的是让 close 行为更灵活、更可预测。

有自定义 menu behavior 的 app，尤其是 nested menus 或基于 open/close callbacks 做 analytics 的场景，需要重点测试。

CupertinoSheetRoute Deprecations

showCupertinoSheet 和 CupertinoSheetRoute 中的 builder、pageBuilder 参数被弃用，推荐改用 scrollableBuilder。

原因是让 scrollable content 和 sheet dragging animations 更好集成。

ReorderableListView Callback Deprecation

ReorderableListView.onReorder 被弃用，推荐使用 onReorderItem。

新 callback 提供更可预测的 newIndex，因为计算会考虑 item 先被移除再插入的过程。

会持久化列表顺序、同步到后端、或用 reorder events 做统计的 app，需要认真测试这部分。

Tooling Deprecations

--web-hot-reload flag 被弃用，因为 Flutter Web hot reload 已经由更新机制处理。

plugin_ffi template 被弃用，推荐使用更完整、支持 FFI 的 plugin template。

SwiftPM 和 CocoaPods 迁移

SwiftPM 默认化严格来说有 fallback，不算直接 breaking change，但对生产项目是实际迁移事件。任何有 Apple native plugins 的 app 都应该重点处理。

AGP 9 和 Kotlin

AGP 9 built-in Kotlin 行为可能让仍然手动应用 KGP 的 app 或 plugin 构建失败。Flutter 目前有临时兼容，但不要长期依赖。

18. 社区报道真正关注什么

这次社区报道的重点相当一致。

Very Good Ventures 的 Google I/O 现场文章重点提到 Agentic Hot Reload、Flutter 在 I/O 的平台定位、Chrome APIs 对 Flutter Web 的意义、GenUI，以及 Flutter 已经成为两大应用商店第二受欢迎 SDK 这个生态信号。

Sagnik Bhattacharya 的 deep dive 把 Flutter 3.44 定义为“如果只找一个大 headline 会被低估”的版本。真正变化分散在 SwiftPM、Android build/runtime、Web、tooling、framework fixes 和 migration risks 里。

daily.dev 等摘要重点强调 Hybrid Composition++、SwiftPM、Impeller/Vulkan、Agentic Hot Reload、Agent Skills、Genkit Dart。

Reddit 讨论里反复出现两类声音：

开发者对 SwiftPM 替代 CocoaPods 默认路径非常关注，也明显松了一口气；
Google I/O 这次 Flutter 展示一定程度上回应了“Google 会不会放弃 Flutter”的长期担忧。

社区反应有参考价值，因为这能把官方叙事和真实开发者痛点区分开。开发者第一时间注意到的不是装饰性组件，而是工具链、平台集成、原生依赖管理，以及 Google 是否继续投入。

19. 生产项目升级 Checklist

严肃生产项目升级 Flutter 3.44 前，可以按这个清单检查。

通用检查

跑完整测试套件。
运行 flutter analyze，对比新增 warning。
检查大型 workspace 下 IDE 和 analysis 性能。
从 clean checkout 重建开发环境。
执行 flutter clean 后重新构建。
检查 generated files 和 lockfiles 是否有预期外变化。

iOS 和 macOS

确认 SwiftPM migration 成功。
找出仍触发 CocoaPods fallback 的 plugins。
检查 CI 是否还假设 CocoaPods 是唯一构建路径。
如果使用 add-to-app，测试 flutter build swift-package。
验证 code signing 和 Xcode project 变化。
判断是否临时需要 SwiftPM opt-out。
如果 AppDelegate 被自定义，验证 UIScene 迁移。
如果启用 inline prediction，测试真实输入场景。

Android

分别测试开启和关闭 HCPP。
测试 WebView、地图、广告、相机、视频、支付 SDK。
在真实设备上验证 touch input 和 scrolling。
如果面向新 Android 版本，测试 Android 17 beta。
检查 AGP 9 和 Kotlin Gradle plugin 使用方式。
审计仍手动应用 KGP 的 plugins。
检查 custom ABI filters 和 flavors。
全屏布局测试 display corner radii。

Web

测试 reduced-motion。
测试表单错误 screen reader 反馈。
测试 Safari autofill。
测试键盘输入和 key-up 行为。
测试生产 base href 下的 deep links。
测试 CanvasKit 和 Skwasm 渲染路径。
测试文本选择和多行复制。

Desktop

跟踪 Canonical-led desktop roadmap。
不要在生产里依赖 main-channel-only windowing APIs。
如果试验 windowing，测试 tooltips、popups、dialogs。
Windows 应用如涉及手写笔，测试 pressure 和 rotation。
在所有 desktop targets 上测试 accessibility 和 keyboard navigation。

UI Framework

搜索 Material/Cupertino imports 和 wrapper layers。
跟踪 material_ui、cupertino_ui migration guidance。
测试 menus、sheets、carousels、navigation rails、dropdowns、reorderable lists。
更新使用 deprecated CupertinoSheetRoute 参数的代码。
规划从 onReorder 到 onReorderItem 的迁移。

Graphics

测试 Impeller-heavy screens。
测试 shader-heavy screens。
检查 transformed shadows 和 perspective effects。
测试 charts、avatars、circular clipping、自定义绘制几何。
关注 shader compiler 的跨 backend compatibility warning。

20. 结论

Flutter 3.44 是一个重要版本，但重要性不在于某个适合截图传播的新组件。

关键在于 Flutter 3.44 同时推动了多条战略线：

从手工开发工作流走向 agent-assisted workflows；
从 CocoaPods 走向 SwiftPM；
从旧 Android platform-view 取舍走向 HCPP；
从 mobile-only 印象走向 desktop、embedded、TV、automotive；
从 core framework 内置 UI libraries 走向独立版本化 packages；
从 cloud-only AI 假设走向端侧和跨平台 AI infrastructure；
从“Flutter Web 能跑”走向更认真处理浏览器行为和可访问性；
从 desktop availability 走向 desktop stewardship。

这次升级值得认真对待。尤其是依赖 iOS/macOS plugins、Android platform views、自定义 Gradle、Flutter Web、复杂 Material/Cupertino wrapper 的项目，不应该盲目升级。

但方向是强的。Flutter 3.44 不只是一次 framework update，而是一个平台信号：Flutter 想成为现代应用在多屏、多设备、多 agent、多嵌入式环境里的 UI 层。

目录