企业官网建设流程全解析

• 跨平台
• 前端
• 移动开发
• OpenHarmony

本文以仓库内 docs/roadmap/Roadmap.md 为主体骨架，结合本仓库（CPF-Flutter 维护的 Flutter SDK 与 Engine 的 OpenHarmony 适配版）中的引擎渲染源码、Flutter 工具链配置与模板实现，对官方 2025 年路线图逐项解读。读完本文，你将系统掌握 Flutter 官方在无障碍、Impeller 渲染、Swift Package Manager、Web/Wasm、桌面多窗口、Dart 编译工具链、发布节奏等方向的优先级与落地方式，并能在当前仓库源码中定位到对应的实现证据，为评估上游特性合入 OpenHarmony 适配版提供参考。

一、路线图的定位：一份「意图声明」而非交付承诺

Roadmap.md开篇即强调透明度原则：Flutter 官方希望通过公开高层级路线图，让社区看清项目优先级，并据此制定自身计划。需要特别留意的是原文中的三处限定：

• 路线图会随反馈演进：计划将根据客户反馈与新的市场机会不断调整，社区反馈（GitHub Issue）和调查问卷是排序优先级的主要依据；
• 清单既不穷尽也不构成承诺：列出的工作不保证全部完成，未列出的方向也不代表官方不做；
• 欢迎外部贡献：作为开源项目，Flutter 欢迎围绕下述主题及其他领域的贡献。

对于有意长期参与贡献的个人或团队，原文提供了联系渠道：可通过邮箱roadmap-input@flutter.dev提交长期计划，以便反映到路线图中；贡献规范可参考仓库根目录的 CONTRIBUTING.md。历年路线图统一归档在 docs/roadmap/[Archive]-Old-Roadmaps.md，便于回溯各年份优先级变迁。

需要客观看待的是：原文明确声明内容主要来自 Google 员工，而当时非 Google 贡献者数量已超过 Google 员工，因此该清单并非社区全部创新方向的完整汇总。软件工程的工期预测本身就充满不确定性，开源项目尤甚——这份文档是方向性陈述，而非合同式保证。

值得对照的是，本仓库还维护着一份独立的 docs/roadmap/Flutter-OH Roadmap.md，对应 Flutter-OH（OpenHarmony 适配版）2026 年的版本同步、内存/负载优化、可定位能力、平行视界、广色域与三方库适配等规划。两者互为补充：前者看上游方向，后者看鸿蒙侧的落地节奏。

二、无障碍（Accessibility）：移动端收尾，Web 端攻坚

原文指出，2024 年 Flutter 已在移动平台（iOS 与 Android）完成多个关键无障碍用例的验证；2025 年的重点转向 Web 平台的无障碍支持。

在本仓库中可以找到与移动端无障碍验证配套的工程资产：dev/a11y_assessments/是一个专门用于内部无障碍评估测试的应用（见 dev/a11y_assessments/README.md），其测试目录覆盖app_bar、dialog、drawer、navigation_bar、slider、snack_bar、tab_bar_view、text_field等数十个常见组件场景（见 dev/a11y_assessments/test/），对应官方在移动端验证过的「关键用例」范畴。这类资产在新平台上同样可作为无障碍回归基线——在鸿蒙适配过程中，为这些组件补齐语义树与屏幕阅读器支持即是对齐上游路线图的直接工作。

从引擎侧看，无障碍能力最终由 shell 层的辅助功能桥接实现，例如 engine/src/flutter/shell/platform/common/accessibility_bridge_unittests.cc 中出现了「In a multi-view world, each view has its own accessibility root」的注释，说明引擎在视图模型演进时同步处理了多视图场景下的无障碍根节点归属——这与路线图中「Web 无障碍」以及下文「桌面多视图」的推进是同一条技术主线上的问题。

三、渲染性能与 Impeller：iOS 去 Skia、Android 全面默认化

路线图的性能部分聚焦于 Impeller：

• iOS：2025 年计划移除 Skia 后端，完成 iOS 全面迁移到 Impeller；
• Android：聚焦支持 Android API 29 及以上的现代设备，在这些设备上让 Impeller 成为默认渲染器；由于 2024 年在较旧设备上观察到的问题，旧设备仍保留 Skia 支持。

当前仓库的引擎侧实现与这一方向高度吻合。engine/src/flutter/impeller/是完整的 Impeller 渲染运行时源码，其 README 明确列出四大目标：可预测的性能（着色器编译与反射全部离线完成、管线状态对象预构建、缓存显式受控）、可插桩（纹理/缓冲/管线对象全部打标，动画可离线捕获且不影响逐帧性能）、可移植（不绑定特定客户端渲染 API，着色器一次编写按需转换）、充分利用现代图形 API（重度依赖但不依赖 Metal/Vulkan 特性）、有效利用并发。

该 README 还给出了 Impeller 的工程组织：//impeller/compiler是离线着色器编译器（产出impellerc可执行文件，仅构建期使用、不随二进制发布）；//impeller/renderer提供后端无关的最底层渲染抽象；//impeller/entity在其上构建 2D 渲染器并承载渲染 pass 优化；//impeller/display_list实现flutter::DisplayListDispatcher接口，让 Flow 子系统可以无缝切换渲染器。其离线着色编译管线可用如下流程图概括：

从引擎配置层可以进一步印证默认化策略。在 engine/src/flutter/common/settings.h 中：

• enable_impeller字段在 iOS 上默认true且无退出选项（「On iOS devices, Impeller is the default with no opt-out」），与路线图「移除 iOS Skia 后端」一致；
• 另有impeller_enable_lazy_shader_mode、impeller_antialiased_lines、warn_on_impeller_opt_out（Impeller 未启用时在 shell 初始化阶段打印警告）等细分开关；
• 图形 API 目标枚举包含kImpellerVulkan（见 settings.h），对应 Android 上 Vulkan 优先、OpenGL 回退的策略。

Impeller README 中说明了各平台的使用方式：

• iOS：Impeller 是唯一可用的渲染引擎，旧渲染器已被移除；
• Android：Impeller 为默认，先尝试 Vulkan、再按设备能力回退到 OpenGL。如需显式关闭可在AndroidManifest.xml的<application>标签下加入<meta-data android:name="io.flutter.embedding.android.EnableImpeller" android:value="false"/>（官方警告该退出能力将在未来版本移除）；开发期强制 OpenGL 后端可设置io.flutter.embedding.android.ImpellerBackend为opengles（仅 debug/profile 模式生效）；
• macOS 桌面：预览状态，在Info.plist顶层<dict>中加入<key>FLTEnableImpeller</key><true/>；
• 自定义嵌入器：预览状态且默认关闭，初始化时向FlutterProjectArgs.command_line_argv传入--enable-impeller=true即可启用，无需其他改动。

对于本仓库（OpenHarmony 适配版）而言，Impeller 源码完整存在，路线图中「质量与性能优先」的方向同样适用于评估鸿蒙侧渲染后端的选择。

四、移动平台：iOS 19 / Xcode 17、SwiftPM 默认化与 Android 16

iOS 侧：系统更新适配与 SwiftPM 落地

路线图明确两个 iOS 方向：一是持续跟进即将到来的 iOS 19 与 Xcode 17 版本；二是完成 Swift Package Manager（SwiftPM）支持，并预期在 2025 年下半年使其成为默认依赖管理选项；同时继续打磨 Cupertino 组件（对齐 Apple Human Interface Guidelines 的 Widget 套件）。

SwiftPM 支持在本仓库的 Flutter 工具链中已经具备完整的可配置实现：

• 特性定义位于 packages/flutter_tools/lib/src/features.dart：swiftPackageManager特性名为「support for Swift Package Manager for iOS and macOS」，配置项为enable-swift-package-manager，并支持FLUTTER_SWIFT_PACKAGE_MANAGER环境变量覆盖，master/beta/stable 三个渠道均已开放；
• 启用方式为flutter config --enable-swift-package-manager，其底层正是遍历所有可配置 Feature 并把configSetting注册为命令行 flag（见 packages/flutter_tools/lib/src/commands/config.dart）；
• 插件模板已内置 SwiftPM 形态：packages/flutter_tools/templates/plugin_swift_package_manager/下提供了 iOS ObjC/Swift 与 macOS 的Package.swift.tmpl模板，flutter create时可据此生成纯 SwiftPM 插件工程；
• 工具还包含迁移辅助：swift_package_manager_integration_migration.dart 与swift_package_manager_gitignore_migration.dart，负责工程迁移与.gitignore的配套调整；
• 依赖冲突诊断也已覆盖：在 packages/flutter_tools/lib/src/ios/mac.dart 中，当工程同时使用 CocoaPods 与 SwiftPM 导致重复模块、或插件仅支持 SwiftPM 而工程仍用 CocoaPods 时，工具会给出明确提示——前者建议在pubspec.yaml的flutter.config下写入enable-swift-package-manager: false关闭 SwiftPM，后者提示运行flutter config --enable-swift-package-manager。

Android 侧：Android 16 特性调研与构建脚本 Kotlin 化

路线图指出，Android 方向将调研即将发布的 Android 16 的主要特性，并期望把 Gradle 构建逻辑从 Groovy 迁移到 Kotlin，同时提升构建工具链的单元测试覆盖率。本仓库的packages/flutter_tools/gradle/下已存在大量*.kt/*.kts文件（见 packages/flutter_tools/gradle/），是构建逻辑 Kotlin 化的既有成果，后续演进可在其基础上继续推进。

平台互操作：Dart 直调原生代码

对 iOS 与 Android 双方，互操作都是对接平台原生代码的关键。路线图预期继续推进实验性工作：在 iOS 上支持从 Dart 直接调用 Objective-C/Swift 代码，在 Android 上支持调用 Java/Kotlin 代码，并且包括那些只能在操作系统主线程调用的 API。这对应 Dart 语言层的 FFI/Native Assets 方向的持续投入。

五、Web 平台：Wasm 编译、JS 互操作与热重载

路线图对 Web 的评价与规划：

• 2024 年成果：应用体积缩减、多线程利用更好、加载时间改善等性能与质量进步；
• 2025 年计划：深化 Flutter Web 核心改进，覆盖无障碍、文本输入、国际文本渲染、体积、性能与平台集成；继续通过编译到 Wasm/WebAssembly 提升 Web 性能；
• JS 互操作：同时支持 JS 与 Wasm 编译的 Dart 新 JS interop 机制已完成，下一步计划在 2025 年移除 legacy 的 HTML 与 JS 库（伴随 breaking change 公告）；
• 热重载：Web 热重载已有良好进展，希望 2025 年推出。

本仓库工具链中，Wasm 编译路径已有完整实现。packages/flutter_tools/lib/src/build_system/targets/web.dart 中的Dart2WasmTarget负责以dart compile wasm编译 Web 入口点，产出main.dart.wasm，并针对 debug/profile/release 三种模式注入不同的dart.vm.profile/dart.vm.product定义；在渲染器为skwasm时还会附加对应编译参数。而 Web 运行时的热重载挂载逻辑位于 packages/flutter_tools/lib/src/web/bootstrap.dart，其注释明确说明该文件包含 hot reload hooks；web_device.dart 则通过声明supportsHotReload与supportsHotRestart支持热重启，并在注释中说明「该设备实际不支持热重载，但 resident runner 的现有实现要求两者为 true 才能允许热重启」——这也解释了为何「推出 Web 热重载」被列为 2025 年的正式目标而非既成事实。

六、桌面平台：多窗口与窗口 API

路线图在桌面部分做了明确分工：2025 年 Google 的 Flutter 团队聚焦移动与 Web，桌面平台（Windows/macOS/Linux）的持续投入由 Canonical 的 Flutter 团队承担。

• 2024 年成果：桌面端落地了多视图渲染（multi-view rendering）；
• 2025 年计划：Canonical 计划进一步改进多窗口支持，覆盖无障碍、键盘、文本输入与焦点；同时推进窗口 API（windowing APIs）。

引擎侧的多视图支持同样有据可查：前文提到的 accessibility_bridge_unittests.cc 中「多视图世界中每个视图拥有自己的无障碍根」即是从渲染视图模型到无障碍语义树的联动实现。桌面多窗口涉及的是同一引擎进程内多 View 的生命周期、输入路由与焦点管理，与 Web/移动端的视图模型演进共享底层抽象。

七、核心框架：降低 Widget 代码冗余度

路线图的 Core framework 部分保持简洁：官方正在调研一系列改动，目标是减少 Flutter Widget 代码中不必要的冗余表达。这与社区长期讨论的声明式 API 简化（如减少显式BuildContext传递、简化嵌套结构）属于同一方向，原文未给出具体 API 清单，属于典型的「调研中」状态。

八、工具链与 AI：DevTools、编辑器与编辑-刷新循环

工具链与 AI 方向包含两条主线：

1. AI 集成：继续与 AI 解决方案集成，为核心编程任务提供 AI 辅助；
2. 既有工具矩阵持续投入：Flutter DevTools、VS Code、Android Studio/IntelliJ 与 IDX，并持续改进编辑-刷新循环（edit-refresh cycle）与整体开发者体验。

这条主线在本仓库中以flutter_tools包为承载（见 packages/flutter_tools/lib/），包含设备发现、构建系统（前述Dart2WasmTarget即其一环）、IDE 集成等能力的 375 个 Dart 源文件，是后续 AI 辅助与开发体验改进的直接落点。

九、Dart 语言与编译工具链

Dart 方向有两个关键结论与计划：

• 宏（Macros）：2024 年官方得出结论，支持宏在 Dart 中不可行。作为替代，2025 年将改进build_runner的代码生成能力，并调研提升 Dart 序列化/反序列化支持的其他途径；
• 语言特性：预期发布一个或多个正在 Dart 语言设计漏斗（language design funnel）中的语言特性。

编译工具链方向同样有两项计划：

• 重构共享实现：重构 Dart analyzer 与前端编译器（front-end compiler），使两者共享更多实现，以加速未来语言特性开发、提升性能与稳定性；
• AOT 交叉编译：调研 Dart AOT 可执行文件的交叉编译支持（例如在 macOS 开发机上编译出 Linux AOT 可执行文件）。

这两项直接影响 Flutter 的编译链路与发布产物形态，也是上游合入评估时需要重点跟踪的「地基」性改动。

十、发布节奏：4 个稳定版 + 12 个 Beta 版

路线图给出 2025 年的发布计划：4 个稳定版（stable）与 12 个 Beta 版，与 2024 年节奏类似。为提升发布的可预测性与规律性、并减少稳定版回归，官方将加大测试覆盖投入；同时提升热修复/补丁（hotfix/patch）版本的快速发布能力。

发布节奏直接关系到本仓库这类适配版的同步窗口。仓库的 release-notes/ 目录维护着各版本（如 Flutter 3.35.7-ohos 0.0.1 至 1.0.5）的发布说明与 Breaking Changes 归档，可在适配新版本时对照评估破坏性变更。

十一、非目标（Non-goals）：明确不做什么

路线图特意列出了「非目标」，帮助社区合理规划预期：

• 代码推送与热更新：官方仍不计划投入内置的 code push 或 hot update 支持。对 code push 需求，可关注 shorebird.dev 的同类产品；对 UI push（即 server-driven UI，服务端驱动 UI），官方推荐使用rfw包；
• 新增平台：官方不计划增加任何额外的受支持平台。

需要强调的是，这两条「非目标」均以官方 Flutter 上游为准，并不排斥本仓库的 Flutter-OH 生态针对 OpenHarmony 平台特性（如平行视界、广色域、密码自动填充等，见 docs/roadmap/Flutter-OH Roadmap.md）做差异化投入。

结语：如何在本仓库中跟踪路线图落地

总结本文涉及的关键源码锚点，便于按图索骥跟踪各条线在上游与本仓库的落地情况：

需要再次提醒的是：路线图是意图声明而非交付承诺，实际交付可能因技术挑战、社区反馈与资源情况调整。阅读本仓库或参与 Flutter-OH 生态时，建议同时跟踪上游 Roadmap 与本仓库的 Flutter-OH Roadmap，以官方公告与仓库实际合入的代码为准，谨慎规划依赖上游新特性的时间表。

• 跨平台
• 前端
• 移动开发
• OpenHarmony