この質問は、上に構築されています:ジェットパック構成は内部でどのように機能しますか
AndroidComposeViewJetpack Compose は、 Compose 独自のウィジェット ツリーから継承しViewGroup、そのルートとして機能するものに基づいています。そのため、ツリー全体を既存のビューに統合できますが、個々のノードは Android ビューではありません。Android ビューと Compose UI ウィジェットの間の移行は明確です。一部の主要なクラスは Compose 用に再実装され (Canvas など)、Compose の UI ウィジェットは (現在) Layout インスペクターに表示されません。
Jetpack Compose はそのウィジェットをキャンバスにレンダリングし、いくつかの巧妙なトリックを使用して状態の変更を適用します。私が理解している限り、これは既存のレイアウト エンジンと完全に直交しており、ネイティブ ビューとコンポーズ ウィジェットを行ったり来たりする必要はありません。 これは SwiftUI とはまったく対照的です。
SwiftUI は、すべての Apple プラットフォームの既存の UI フレームワークとシームレスに連携します。たとえば、SwiftUI ビュー内に UIKit ビューとビュー コントローラーを配置したり、その逆を行うことができます。
iOS側の知識はほとんどありません。おそらく、UIkit は SwiftUI とのインターフェースに適していたのでしょう。しかし、そうではなく、ネイティブ ウィジェットからの Jetpack Compose の分離が内部の制約によって強制されていない場合、それは奇妙な設計上の決定のように思えます。
さて、私の質問は次のとおりです。Jetpack Compose は、何らかの方法でネイティブ ビューを再利用するのではなく、独自のレンダリング パス (カスタム Canvas 実装に基づく) に基づいているのはなぜですか? これには隠れた利点があるのでしょうか、それとも単に既存のビューをリアクティブ プログラミング パターンに曲げることができなかったのでしょうか? これにより、長期的には潜在的なマルチプラットフォームの取り組みが容易になるように思えますが、短期的にはアプリ開発の断片化がさらに進む可能性があります。