問題タブ [android-jetpack-compose]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
android - Jetpack Compose の内部設計: ネイティブ ビューを再利用するのではなく、キャンバスに描画するのはなぜですか?
この質問は、上に構築されています:ジェットパック構成は内部でどのように機能しますか
AndroidComposeView
Jetpack 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 実装に基づく) に基づいているのはなぜですか? これには隠れた利点があるのでしょうか、それとも単に既存のビューをリアクティブ プログラミング パターンに曲げることができなかったのでしょうか? これにより、長期的には潜在的なマルチプラットフォームの取り組みが容易になるように思えますが、短期的にはアプリ開発の断片化がさらに進む可能性があります。