这个问题建立在：jetpack compose 如何在幕后工作
Jetpack Compose 基于AndroidComposeView它继承自ViewGroupCompose 自己的小部件树并充当其根。因此，整个树可以集成到现有视图中，但单个节点不是 Android 视图。Android 视图和 Compose UI 小部件之间的过渡非常明显：为 Compose 重新实现了一些关键类（如 Canvas），并且 Compose 的 UI 小部件（当前）在布局检查器中不可见。
Jetpack Compose 将其小部件渲染到画布上，并使用一些巧妙的技巧来应用状态更改。据我了解，这与现有的布局引擎完全正交，您不应该在本机视图和撰写小部件之间来回切换。 这将与 SwiftUI 形成鲜明对比：
SwiftUI 与所有 Apple 平台上的现有 UI 框架无缝协作。例如，您可以将 UIKit 视图和视图控制器放置在 SwiftUI 视图中，反之亦然。
我对 iOS 方面的知识几乎一无所知。也许 UIkit 更适合与 SwiftUI 交互。但如果情况并非如此，并且 Jetpack Compose 与原生小部件的分离不是由内部约束强加的，那么这似乎是一个奇怪的设计决定。
现在，我的问题是：为什么 Jetpack Compose 基于自己的渲染路径（基于自定义 Canvas 实现），而不是以某种方式重新使用原生视图？这是否具有隐藏的优势，或者根本不可能将现有视图转变为反应式编程模式？在我看来，从长远来看，这似乎会促进潜在的多平台努力，但在短期内会导致 App 开发更加分散。