Jetpack Compose LivestreamのQ&A部分メモ

#TheAndroidShow: Jetpack Compose Livestream のQ&A部分がかなりの情報量だったので、抜粋してメモ的に書き起こしてみました。

（Q&Aは12:10あたりから）

Q: Composeはレンダリングのパフォーマンスを期待できる状態なのか

全体としてのパフォーマンス

• いくつかまだ最適化されきってない箇所があるが、全体としてViewに対してパフォーマンスは向上している。
• Layoutのmeasureは大体の場合でViewより向上している
• layout modifier APIがAlphaの初期から変わってない部分があるが、修正を加えている
• compositionでは、初期化と更新とでプロセスを分けて簡素化させようとしている
  • これでパフォーマンスの向上が見込めるはず

multi-threading API

• マルチスレッドAPIがexperimentalとして新しく追加されている
• メインスレッド外でのcompositionが可能になる
• 複数の要素を並列に用意したり、まるっきり別のスレッドで作ったりできる

lazy list and scrolling performance

• リストやスクロールのパフォーマンスはチームで活発に調査している

• スタックの深い所をいじる必要があって、少し時間がかかりそう。

• ここ数ヶ月はAPIの安定化に集中していたが、パフォーマンスも意識している

• 例えば、パフォーマンスの最適化のためにAPI層にラムダをつかったmodifierを用意しているが、実際の最適化はまだ準備中だったりする

• 全体としては重要な箇所ではいいパフォーマンスを見せている

• 足りていない箇所も改良を続けていく

プラットフォームとの分離

• プラットフォームと切り離すことがJetpack Composeの主要な目的の一つ
  • 達成するのにいくつかのトレードオフがある
• パフォーマンスの最適化を継続的に行えるメリットはある
• 切り離したことによってアプリが実行時にロードするクラスが増えたり、読み込むコードが増える
• こういった側面でも調査を続けていて、ツールや解決策を見出そうとしている
• でも全体としてはいい感じ
• ツールキットがパフォーマンス低下となるようなミスを防いでくれたりする
  • multiple measure passesなど

Q: XMLレイアウトを使った既存のプロジェクトでも使える？

• かなり初期の段階から相互運用を重視してきた
• デベロッパーがいきなりアプリをまるごとCompose書き換えるなんてことはしないことを理解している
• ViewとComposeが共存するストーリーを意識している
  • 一つの小さなViewを差し替えたり、一つの画面を差し替えたり
  • アプリにどれくらいComposeを導入するかは使い手に委ねている
• つまりXMLレイアウトがあるアプリの開発を続けることは可能ということ
  • （既存のアプリを捨てる必要はない）

XMLレイアウト != ComposeのUI

• ただし、Composeが担う部分のUIはXMLレイアウトで表現するべきではない
• Composeを十分に活用するためには、コードで書かれる必要がある
• つまり、Composeで動かしたいUIとXMLレイアウトには実際は相互運用性はない
• ただほかのXMLファイルとは相互運用性はある
  • stringやcolors、dimensionsなどは使える

Q: Compose用のツールについての新しい情報はないか

• 今回のComposeベータ版のリリースとともに、Android Studio Arctic Foxのカナリア版をリリースした

Preview機能

• Composeのプレビュー機能は以前からあるが、ここ数ヶ月で様々な機能が実装された
  • プレビュー内でビューに触れる
  • 部分的に端末にデプロイできる
  • プレビューと端末の両方で更新した箇所をアプリをビルドせずに見れる

Constraint Layout

（質問内でConstraint Layoutにも触れられていた）

• ComposeはConstraint Layoutとは違ったアプローチをとっている
• XMLベースではなくコードベースなので、Constraint Layoutはサポート自体はされているが、Composeにとって自然な形で入っている

ベータになったことの影響

• ベータに昇格されたことによって、APIが安定した
• 変化するAPIの追従が大変だったが、安定したことによってツールに手を入れやすくなった

Q: Reduxなどのような状態管理のコンセプトやライブラリはある？

• 状態管理はアプリの最も重要な要素のひとつ
• Composeが様々な状態管理の方法に対応できることを重要視している

Compose自体は特定のコンセプトを強制しないようにしている

• Androidのエコシステムでは最近MVIにシフトしてきている
• ComposeもMVIとの相性がいい
• ReduxはMVIと似ていて、Compose自体は特定のコンセプトを強制しないようにしているので、Composeを組み込むのも比較的簡単なはず
• Toolkitチームとしては皆さんに色んな方法を試して、どの方法がよさそうかを逆に教えて欲しい

Q: Composeを始めるにあたってチュートリアルなどはある？

Pathway

• Pathwayを用意している
• 用意した教材をキュレートした「道筋」
• かなり覚えることが多いので、一歩ずつ学べるように用意した

その他の資料

• 他にも一緒に色んなものをリリースした
  • ドキュメント
  • アニメーションについてのコードラボ
  • たくさんのサンプル

Q: MotionLayoutはComposeではどうなる？

• 現時点ではMotionLayoutはComposeでは動かない
• 既存のViewシステムとComposeでは、アニメーションの動作はまるっきり違う
• ただMotionLayoutは重要視していて、どう実装しようかを検討しているところ
• 新しいアニメーションAPIを用意しているので、検討はこれから
• 今回アニメーションのAPIも安定したので、我々も皆さんもいいと思えるような実装について検討できるようになった

Q: で、プロダクション環境で使えるの？

ベータ版としてローンチしたことには理由がある

• 最近本当によく聞かれる（苦笑）
• 今日はベータ版をローンチした。ベータ版であることには理由がある
• まだやることが残っている
  • アクセシビリティがトークバックだけだったり
• 厳密にはプロダクション環境で使うことは可能といえば可能
  • 実際いくつかのアプリがリリース済み
• 止めはしないけど、いくつかのトレードオフがあることを認識して欲しい

リリースを前提としたテストはしておいたほうがいい

• 現時点ではプロダクションでのリリーズを前提として学習や準備をしておくことをオススメする
• プロダクションを前提としたテストをしておくことで、実際の使用で問題になる部分を洗い出しておくことが重要
• フィードバックをもらうことでstableに修正を含めることもできる

Q: Composeはアクティビティやフラグメントの代わりになる？

• アクティビティやフラグメントはプラットフォームの一部なので、代わりにはならない
• ただ、Composeを使ったアプリを作ると、アクティビティや特にフラグメントに触れる機会がかなり減ると思う
• ComposeではCompose hierarchyをフラグメントの配下などでインスタンス化する
• フラグメントを多用するアプリではComposeを導入することが簡単になる
• 新規でComposeを使ったアプリを作る場合はアクティビティを使う機会は特に減ると思う（フラグメントも）

Q: Jetpack Compose、たのしい？

• もちろん。楽しいなんてもんじゃない。

---

（参考）

大きな発表だけあってかなり手厚く案内が出ていますね

• #TheAndroidShow: Jetpack Compose
  • メインのランディングページ
• Android Developers Blog: Announcing Jetpack Compose Beta!
  • ブログ記事
• Jetpack Compose: Beta overview - YouTube
  • Composeの概要を紹介している動画
• Jetpack Compose Pathway |  Android Developers
  • Compose関連チュートリアルを順に学べるPathway