開発に使ってみた所感
推奨アーキテクチャからなら移行しやすい
ViewModelとFragmentの責務がきれいに分離されているなら、移行はそれほど大変ではありません。ただし公式のドキュメントにもあるように、単方向データフロー（Unidirectional Data Flow）アーキテクチャのほうが適切です。このとき、ViewModelにdispatchEvent(event: Event<T>)のようなメソッドをつくってそれを呼ぶのでも良いのですが、ViewModel内にval dispatchEvent : (Event<T>) -> Unitのような関数型のプロパティを作成し、FragmentからはViewModelのメソッド呼び出しを行わず、そのプロパティを通じたイベント送信のみを行うようにしたほうが、参画したばかりのメンバーにも単方向性のルールを理解しやすいでしょう。
LiveDataよりもFlowのほうがよい
ViewModelがFragmentへ提供するViewの状態は、「ユーザーの情報」や「商品の情報」のように分離するのではなく、1つに集約されているべきです。このとき、各状態がLiveDataではなくFlowであれば、combine()のようなストリーム変換の関数が使えるため便利です。LiveDataであっても同様の拡張関数を作ることは容易ですが、新規メンバーのことを考えると標準で用意されているほうが好ましいですし、LiveDataの変更イベントはメインスレッドで通知されることを考えると、パフォーマンス面でもFlowのほうが良いです。
困ることはそう多くない
まだ狭い範囲でしか試せていませんが、必要なライブラリはすでに充実してきていて特に困っていません。
Hiltによる依存性の注入、Navigationによる画面遷移、PagingによるページングリストはすでにComposeに対応されていますし、ネットワーク経由での画像の読み込みもCoilがあります。そのため、一般的なアプリのたいていのユースケースは満たすことができるでしょう。
Previewは今後に期待
ComposeのPreview機能では複数の条件でのプレビュー表示を一括で確認することができる点や、インタラクティブモードによってアニメーションなども確認できるのは良いのですが、ことあるごとに再ビルドを求められるのが困りものです。このときのビルドは速いのですが、そもそも従来のXMLでのレイアウトでは、ほとんどの状況でリビルドは求めらることなくリアルタイムで確認できていました。まだ慣れないうちは、Composeでのレイアウトに時間がかかるかもしれません。この点は今後のバージョンに期待したいところです。
Compose関数の特性に注意
Compose関数にはいくつか注意すべき点があります。Compose関数は状態の変化に応じて自動的に再実行されることで表示が更新されますが、このときに実行されるのは表示が変更される可能性のある関数のみで、実行される順序は保証されていません。また、アニメーション中などの場合、同じ関数が高速に何度も繰り返し呼ばれることがあります。したがって、関数内で副作用のある処理や重たい処理を行おうものなら、大変なことになるでしょう。Jetpack Composeで推奨されるアーキテクチャに従って開発されるよう注意が必要です。
まとめ
Jetpack Composeは今後も普及と拡張が期待できる、実用的な宣言的UIフレームワークです。
複雑化していく状態管理やパフォーマンスへの課題感からJetpack Composeの試験的な導入を決定しました。試した範囲ではまだパフォーマンスの向上は確認できていませんが、状態の管理はとてもクリーンとなったことで快適に開発でき、安心してリリースできるようになりました。
まだ導入に躊躇している方は、小さな箇所から始めてみてはどうでしょうか。
