タップルでComposeの段階的な導入を進めている話

Transcript

1. タップルでComposeの 段階的な導入を進めている話 CA.aab #1 2022 / 08 / 16 株式会社タップル / 山下俊 / やましゅん
2. サクッと自己紹介 ・ 山下俊 / やましゅん ・ 2022/04 株式会社サイバーエージェント新卒入社 ・ Android エンジニア @タップル ・ Flutterも好き
3. 今日話すこと タップルでComposeを導入した際の 流れや取り組み、課題について
4. 目次 " Composeをプロダクトに導入するまで 2. Activityの中身をComposeリプレイス 3. リストのアイテムをComposeリプレイス 4. チームでの取り組み 5. 感想
5. Composeをプロダクトに導入するまで
6. デバッグメニューで技術検証 ・Composeのバージョンがalphaだったため ユーザーに露出しないデバッグメニュー画面でお試し ・リップルエフェクトがうまく動かない ・xmlで定義されているリソースを 　Composeで扱えるようにしなければいけない 検証で見つかった課題など
7. テーマのマイグレーション xmlで定義されていたstyleをComposeで再構築 ・カラー / color.xml ・フォント / text_appearance.xml ・ボタン / style_button.xml TappleTheme TappleThemeに統合することで が使える IDEの補完機能
8. ・マテリアルデザインは採用していない ・共通の を実装 TappleColorPalette ・ を見据えた実装 ダークモード ・compose.materialのカラーロールは使用しない ダーク / ライトテーマ共通のカラーパレットを定義 カラー
9. フォント ・既存のxml定義から簡単にComposeに変更できるように @style/TextAppearance.Size14.Bold.Large TappleTheme.typography.size14BoldLarge ・ を実装しTappleThemeに統合 TappleTypography
10. ボタン ・ を定義しTappleThemeに統合 ButtonStyle カラー、サイズ、フォント、リップルエフェクトを TappleThemeで定義 ・ を意識したカスタム性のあるボタン スロットベース ・フォントサイズも で定義 ButtonStyle
11. Activityの中身をComposeにリプレイス
12. ・ネットワーク通信 ・エラーハンドリング ・ページング処理(無限スクロール) 簡単な画面をComposeでリプレイス Activityの中身をComposeに移行
13. ・カスタムビューは作らずにrememberLazyListState( )を拡張した を実装し を持たせる 　rememberInfiniteScrollList( ) 拡張性 ・Composeは簡単にカスタムビューを作ることができるので、 　拡張性や保守性を維持するために無作為にカスタムビューを作らない ページング処理(無限スクロール)
14. 最初はDroidkaigiを参考にflowを使って として イベント/エラーを処理するパターンも考えた one-shotなeffect イベント/エラー処理について stateの設計
15. 公式ドキュメントで紹介されていたstateにイベント/エラーを持たせる設計を採用 ・ をもつアプリを実装しやすい KMMでstateを共通化したiosと同じ挙動 ・ライフサイクルを意識せずにイベント/エラー処理ができる ・イベント/エラーを含めて画面の状態を復元できる ・ の原則に従う single source of truth エラー stateの値を見てエラーハンドリング イベント https://developer.android.com/jetpack/guide/ui-layer?hl=ja#consume-ui-state ※一部略
16. リストのアイテムをComposeでリプレイス
17. 最終的には画面のフルComposeを見据えて、Groupieの各Itemをリプレイス xml Compose xml Compose Compose xml RecyclerView
18. ・ しやすい 作業分担 ・MVVMを採用している場合、stateは既存のまま変更せず 可能 UIだけリプレイス ・画面全体のリプレイスに比較して実装コストが低く、デグレも発生しづらい メリット
19. パフォーマンス低下問題 ・画面の描画時間(リストのレンダリング時間) ・スクロールパフォーマンス ・アニメーションがカクつく GroupieのアイテムをComposeにしたところ してしまった... パフォーマンスが低下 補足 : フルComposeにすればxmlと同程度のパフォーマンスが見込める
20. レンダリング時間 / スクロールパフォーマンス低下の原因 ・AndroidViewの中にComposeを埋め込む際にComposeラッパーや 　recomposerの 。 (ensureCompositionCreated( )など) 初期化関数がたくさん実行される ※ 基本的にAndroidViewの中にComposeを埋め込む場合、 　レンダリングパフォーマンスはxmlよりも低下する ・Groupieが毎回Composeを初期化するのでうまくviewをリサイクルできていない
21. レンダリングパフォーマンス Android Profilerでリリースビルドにてデバッグ RecyclerViewの描画にかかった時間 Composeをxmlに 埋め込むために必要な処理 xmlと比較して+500ms ※一部略
22. スクロールパフォーマンス 開発者メニューのCPU利用率可視化でリリースビルドにてデバッグ ・明らかにCompose + xmlの方が 　CPU利用率が高くなっている AndroidViewのみの場合 Composeを利用した場合
23. 解決策 ・Splash画面でComposeのsetContentを呼び出し、 させておく 初期化関数をプリロード 補足 : 初期化するタイミングはComposeを導入する画面が 　　　表示される前であればどこでも良い ・PoolingContainerを使ってcompositionを破棄しないでスクロールさせる 　（RecyclerView: 1.3.0-alpha02 以上かつ compose.ui: 1.2.0-beta02 以上が必要） viewCompositionStrategy: 　 DisposeOnDetachedFromWindowOrReleasedFromPool
24. AndroidViewのみの場合 AFTER (スプラッシュでプリロード) BEFORE (Compose + xml) Composeを利用した場合 結果 ・画面の起動時間は 　xmlと比較して-80ms ・リプレイス前と 　ほぼ同等の起動時間 ・スクロールも 　ほぼ同等のCPU使用率
25. アニメーションがカクつく原因 ・LayoutInspectorのRecomposition Countを 　使ってデバッグ&調査 ・アニメーションを実行した際に、 　データ変更によるrecompositionも実行されるとカクつく ・ てカクついていた recompositionの回数が多すぎ https://developer.android.com/jetpack/compose/tooling
26. 解決策 ・ を使うことでアニメーション中に発生していた 　データ更新によるrecompositionの回数を減らすことで解決 @Stable 補足 : タップルではComposeの 、 　　　 　　　ただしアニメーション周りではrecompositionの問題が発生しやすい 開発中にrecompositionは意識せず 問題が発生したらデバッグして対応するという方針
27. チームでの取り組み
28. ・Composeを導入すべき理由やメリデメについてチームで認識をそろえた上で導入を進めた ・作業分担することでチームメンバーがComposeに触れる機会を積極的に作った 社内勉強会にて ・導入の最初は、 　リプレイスの一例を作った上でチームメンバーに展開した 少人数で進め迅速にComposeの基盤を作り上げ チームでの取り組み
29. 今後の課題 ・RecyclerViewの計測ログの移行 ・xmlで作成されているカスタムビューをComposeに移行する ・コーディング規約の策定 ・Figma x Compose によるコンポーネント自動生成 ・画面全体をリプレイスするComposeマラソンなどの取り組み
30. 感想
31. 良かったところ ・UIに集中できるためリストのitemごとにComposeリプレイスがおすすめ ・画面状態が複雑な画面でもUIを構築しやすい ・アニメーションを直感的に記述できる
32. 大変だったところ ・アニメーションを入れると@Stableを意識しなければならなくなる場面が多い ・recomposition起因のバグはレビューで気づきにくい ・xmlの一部をComposeにする場合はパフォーマンスが少し不安
33. Thankyou