Jetpack Compose 内部设计：为什么要在 Canvas 上绘图，而不是重用本机视图？

Question

这个问题建立在：How does jetpack compose under the hood

Jetpack Compose 继承AndroidComposeView自ViewGroupCompose 自己的 widget 树，并作为其根。因此，树作为一个整体可以集成到现有视图中，但单个节点不是 Android 视图。Android 视图和 Compose UI 小部件之间的过渡非常明显：为 Compose 重新实现了一些关键类（如 Canvas），并且 Compose 的 UI 小部件（当前）在布局检查器中不可见。

Jetpack Compose 将其小部件渲染到画布上，并使用一些巧妙的技巧来应用状态更改。据我了解，这与现有布局引擎完全正交，您不应该在本机视图和组合小部件之间来回切换。 这与 SwiftUI 形成鲜明对比：

SwiftUI 可以与所有 Apple 平台上的现有 UI 框架无缝协作。例如，您可以将 UIKit 视图和视图控制器放置在 SwiftUI 视图中，反之亦然。

我对 iOS 方面的知识知之甚少。也许 UIkit 只是更适​​合与 SwiftUI 交互。但如果情况并非如此，并且 Jetpack Compose 与本机小部件的分离不是由于内部约束而强制的，那么这似乎是一个奇怪的设计决策。

现在，我的问题是：为什么 Jetpack Compose 基于其自己的渲染路径（基于自定义 Canvas 实现），而不是以某种方式重新使用本机视图？这是否具有隐藏的优势，或者根本不可能将现有视图弯曲为反应式编程模式？在我看来，从长远来看，这将促进潜在的多平台工作，但在短期内会导致应用程序开发更加分散。

Answer 1

我相信选择渲染自己的 UI 的原因之一是因为 Compose 的目标是跨平台并且类似于 Flutter，我们也许可以使用 Compose 编写支持 iOS 的 UI