ここ最近採用されることが多くなってきた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でサクッと実装してしまうほうが楽でした。

参考文献