- 專案負責人：dworsham@google.com
- 區域：Flutter
問題陳述
Fuchsia 的 Flutter 整合目前在技術債和樹狀結構外工作流程中，出現銳利的銳利化。這兩個因素會使現有工程師或新進工程師難以透過有意義的方式為 Flutter-on-Fuchsia 做出貢獻。此外，他們也領導 Flutter 團隊捨棄 Flutter-on-Fuchsia 的維護工作，並將工作的擁有權轉移給 Fuchsia 團隊。
Fuchsia-Flutter 程式碼的樹狀結構外位置 (稱為 flutter_runner) 加上上游存放區與 GI 之間的滾動器順序，代表 Dart VM 或 Flutter 引擎的變動通常在導入上游後數週才會顯示在 GI 中。
歸根究底來說，要立即變更 flutter_runner 並不容易，且會因執行時間而造成非常大的代價。由於數個產品為主要殼層使用 Flutter，因此任何錯誤都會耗用大量使用者成本，有時無法修正數週。
解決方案陳述
Flutter 中的 Flutter 將採用 Flutter 團隊打造的明確定義 Embedder API (和 ABI)，然後遷移至自訂 Flutter Engine 嵌入程式。同時，我們將移除 dart:zircon 和 dart:fuchsia 的原生 VM 掛鉤，並使用 dart:ffi 重新實作這些套件 (因為嵌入器 API 不允許自訂原生掛鉤)。
這項重構將允許 Fuchsia 專用程式碼獨立維護，與核心拖拉引擎程式碼無關，其中 2 則由明確定義的 ABI 分隔。在將 Fuchsia 專用程式碼與程式碼鬆散工程程式碼區隔的過程中，也會移除許多技術債 (約 8kLOC 組已排定刪除的舊版程式碼)。
依附元件
將 flutter 嵌入器程式碼移至 //sdk，會對使用 Flutter 的 Fuchsia 工程師進行大型工作流程變更。這些工程師不會再提交 Flutter Engine 樹狀結構中的 //flutter/shell/platform/fuchsia 變更，而是將這些變更提交到 Fuchsia 樹狀結構。
flutter_runner_unittests 也會在樹狀結構內移動，因此會改為在簡單的 CI 上執行。這些測試規模較小且獨立，因此移動不會造成問題。
最後，在 flutter 嵌入器程式碼中工作的工程師將僅限於 embedder.h 中 Flutter 團隊公開的 API
風險與緩解措施
- 風險：將
dart:zircon和dart:fuchsia遷移至 FFI 可能會遇到非預期的障礙 風險：針對這項工作轉換的程式碼，缺少測試涵蓋範圍
緩解措施：設計以 FFI 為基礎的
dart:zirconAPI 原型，並確認是否正常運作緩解措施：擴大測試涵蓋範圍
緩解措施：可以 (且確實) 遷移舊版轉譯程式碼 (位於
flow/)，不必遷移dart:zircon和dart:fuchsia