- 项目负责人：dworsham@google.com
- 领域：Flutter
问题陈述
Fuchsia 的 Flutter 集成目前因技术债务和具有尖锐边缘的树外工作流而陷入困境。这两个因素导致现有或新工程师很难以有意义的方式为 Flutter-on-Fuchsia 做贡献。他们还领导了 Flutter 团队在很大程度上放弃对 Flutter-on-Fuchsia 的维护，并将这项任务的所有权移交给 Fuchsia 团队。
Fuchsia-Flutter 代码（称为 flutter_runner）的树外位置以及上游代码库和 GI 之间的滚轮序列意味着对 Dart 虚拟机或 Flutter 引擎的更改通常在引入上游后的几周内不会显示在 GI 中。
最终，目前很难更改 flutter_runner，并且由于滚动时间的原因，如果出错，代价非常高。由于多个产品都使用 Flutter 作为主 shell，因此任何 bug 都会给用户带来很高的成本，并且有时在数周内无法修复。
解决方案声明
Fuchsia 上的 Flutter 将改用由 Flutter 团队创建的明确定义的 Embedder API（和 ABI），成为自定义 Flutter Engine 嵌入器。在此过程中，我们将移除 dart:zircon 和 dart:fuchsia 的原生虚拟机钩子，并使用 dart:ffi 重新实现这些软件包（因为嵌入器 API 不支持自定义原生钩子）。
这种重构可让 Fuchsia 专属代码独立于核心 Flutter 引擎代码进行维护，其中两个代码由明确定义的 ABI 分隔。在将 Fuchsia 专用代码与代码 Flutter 工程师代码分离的过程中，也消除了大量技术债务（计划删除大约 8kLOC 的旧版代码）。
依赖项
将 Flutter 嵌入器代码迁移到 //sdk 对开发 Flutter 的 Fuchsia 工程师而言将是一项巨大的工作流变化。这些工程师不再提交对 Flutter 引擎树中的 //flutter/shell/platform/fuchsia 的更改，而是将这些更改提交到紫红色树。
flutter_runner_unittests 也会在树内移动，因此它们改为在 Fuchsia CI 上运行。这些测试规模较小且是独立的，因此移动它们应该不会出现问题。
最后，从事 Flutter 嵌入器代码的工程师将只能使用 Flutter 团队在 embedder.h 中公开的 API
风险和缓解措施
- 风险：将
dart:zircon和dart:fuchsia迁移到 FFI 可能会遇到意外障碍 风险：为此任务转换的代码缺乏测试覆盖范围
缓解措施：对基于 FFI 的
dart:zirconAPI 进行原型设计并验证其能否正常运行缓解措施：扩大测试覆盖范围
缓解措施：可以（并且确实）可以（并且确实）迁移了（在
flow/中）旧版渲染代码，而无需迁移dart:zircon和dart:fuchsia