ここ最近採用されることが多くなってきたJetpackCompose(以下Composeと呼びます。)ですが、xmlで作成していたり、Javaで記述されているような既存UIを一括で移行していくことは難しい場面が多いです。
そこで、GoogleDevelopersの記事でも紹介しているような、部分的にCompose移行していく方法が挙がってくるかと思います。
方法としてはComposeViewを使う方法と、AbstractComposeViewを使う方法と2パターンあります。
いざコーディングしてみると、両者ともやっていることは「Composeを既存UIに当て込むための橋渡し」であり、使い分けの判断がよくわかりませんでした。
色々記事を読んだり、色々実装を試してみた上で、「こういうことかな？」という使い分けの判断を持つことができたので、メモ書きしておきます。
結論(個人的見解)
AbstractComposeViewを使う場面
Javaで記述されているFragmentやActivityが親クラスのとき
javaだとsetContent()ができないので、xmlにAndroidViewとして当て込めるAbstractComposeViewの出番です。
既存コード内にComposeのコードを混ぜたくないとき
個人的な主観ですが、既存のコードにComposeのコードが混ざると結構読みにくかったりします。
Composeという概念を既存コードからは抽象化しておくと可読性だけでなく、追加したComposeを諸事情で消すことになったとき、混ざったコードを引き剥がす苦労がなくなります。
「試しにこのレイアウトを入れて様子を見たい」というオーダーにAbstractComposeViewは不向きということですね。（入れ替え場所が元々Composeであれば、ComposeViewのほうが良いと思います。）
ComposeViewを使う場面
どこまでComposeに移行できているかを把握したいとき
xmlの中身が徐々にComposeViewに置き換わっていくので、地味にわかりやすいです。
全部ComposeViewになったらxml削除の合図！
State管理等が不要なComposeを手早く実装したいとき
ComposeViewのほうが実装速度は早いと思うので、State管理などが不要で既存コードにそこまで影響が出ないものであれば、ComposeViewでサクッと実装してしまうほうが楽でした。
参考文献