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

タップルでComposeの段階的な導入を進めている話 CA.aab #1 2022 / 08 / 16 株式会社タップル
/ 山下俊 / やましゅん

サクッと自己紹介・山下俊 / やましゅん・ 2022/04 株式会社サイバーエージェント新卒入社・ Android
エンジニア @タップル・ Flutterも好き

今日話すことタップルでComposeを導入した際の流れや取り組み、課題について

目次 " Composeをプロダクトに導入するまで 2. Activityの中身をComposeリプレイス 3. リストのアイテムをComposeリプレイス 4. チームでの取り組み 5.
感想

Composeをプロダクトに導入するまで

デバッグメニューで技術検証・Composeのバージョンがalphaだったためユーザーに露出しないデバッグメニュー画面でお試し・リップルエフェクトがうまく動かない・xmlで定義されているリソースを　Composeで扱えるようにしなければいけない検証で見つかった課題など

テーマのマイグレーション xmlで定義されていたstyleをComposeで再構築・カラー / color.xml ・フォント / text_appearance.xml ・ボタン /
style_button.xml TappleTheme TappleThemeに統合することでが使える IDEの補完機能

・マテリアルデザインは採用していない・共通のを実装 TappleColorPalette ・を見据えた実装ダークモード・compose.materialのカラーロールは使用しないダーク /
ライトテーマ共通のカラーパレットを定義カラー

フォント・既存のxml定義から簡単にComposeに変更できるように @style/TextAppearance.Size14.Bold.Large TappleTheme.typography.size14BoldLarge ・を実装しTappleThemeに統合 TappleTypography

ボタン・を定義しTappleThemeに統合 ButtonStyle カラー、サイズ、フォント、リップルエフェクトを TappleThemeで定義・を意識したカスタム性のあるボタンスロットベース・フォントサイズも
で定義 ButtonStyle

Activityの中身をComposeにリプレイス

・ネットワーク通信・エラーハンドリング・ページング処理(無限スクロール) 簡単な画面をComposeでリプレイス Activityの中身をComposeに移行

・カスタムビューは作らずにrememberLazyListState( )を拡張したを実装しを持たせる　rememberInfiniteScrollList( ) 拡張性・Composeは簡単にカスタムビューを作ることができるので、　拡張性や保守性を維持するために無作為にカスタムビューを作らないページング処理(無限スクロール)

最初はDroidkaigiを参考にflowを使ってとしてイベント/エラーを処理するパターンも考えた one-shotなeffect イベント/エラー処理について stateの設計

公式ドキュメントで紹介されていたstateにイベント/エラーを持たせる設計を採用・をもつアプリを実装しやすい KMMでstateを共通化したiosと同じ挙動・ライフサイクルを意識せずにイベント/エラー処理ができる・イベント/エラーを含めて画面の状態を復元できる・の原則に従う single source
of truth エラー stateの値を見てエラーハンドリングイベント https://developer.android.com/jetpack/guide/ui-layer?hl=ja#consume-ui-state ※一部略

リストのアイテムをComposeでリプレイス

最終的には画面のフルComposeを見据えて、Groupieの各Itemをリプレイス xml Compose xml Compose Compose xml RecyclerView

・しやすい作業分担・MVVMを採用している場合、stateは既存のまま変更せず可能 UIだけリプレイス・画面全体のリプレイスに比較して実装コストが低く、デグレも発生しづらいメリット

パフォーマンス低下問題・画面の描画時間(リストのレンダリング時間) ・スクロールパフォーマンス・アニメーションがカクつく GroupieのアイテムをComposeにしたところしてしまった... パフォーマンスが低下補足 : フルComposeにすればxmlと同程度のパフォーマンスが見込める

レンダリング時間 / スクロールパフォーマンス低下の原因・AndroidViewの中にComposeを埋め込む際にComposeラッパーや　recomposerの。 (ensureCompositionCreated( )など) 初期化関数がたくさん実行される ※
基本的にAndroidViewの中にComposeを埋め込む場合、　レンダリングパフォーマンスはxmlよりも低下する・Groupieが毎回Composeを初期化するのでうまくviewをリサイクルできていない

レンダリングパフォーマンス Android Profilerでリリースビルドにてデバッグ RecyclerViewの描画にかかった時間 Composeをxmlに埋め込むために必要な処理 xmlと比較して+500ms ※一部略

スクロールパフォーマンス開発者メニューのCPU利用率可視化でリリースビルドにてデバッグ・明らかにCompose + xmlの方が　CPU利用率が高くなっている AndroidViewのみの場合 Composeを利用した場合

解決策・Splash画面でComposeのsetContentを呼び出し、させておく初期化関数をプリロード補足 : 初期化するタイミングはComposeを導入する画面が　　　表示される前であればどこでも良い・PoolingContainerを使ってcompositionを破棄しないでスクロールさせる　（RecyclerView:
1.3.0-alpha02 以上かつ compose.ui: 1.2.0-beta02 以上が必要） viewCompositionStrategy: 　 DisposeOnDetachedFromWindowOrReleasedFromPool

AndroidViewのみの場合 AFTER (スプラッシュでプリロード) BEFORE (Compose + xml) Composeを利用した場合結果・画面の起動時間は
　xmlと比較して-80ms ・リプレイス前と　ほぼ同等の起動時間・スクロールも　ほぼ同等のCPU使用率

アニメーションがカクつく原因・LayoutInspectorのRecomposition Countを　使ってデバッグ&調査・アニメーションを実行した際に、　データ変更によるrecompositionも実行されるとカクつく・てカクついていた recompositionの回数が多すぎ https://developer.android.com/jetpack/compose/tooling

解決策・を使うことでアニメーション中に発生していた　データ更新によるrecompositionの回数を減らすことで解決 @Stable 補足 : タップルではComposeの、　　　
　　　ただしアニメーション周りではrecompositionの問題が発生しやすい開発中にrecompositionは意識せず問題が発生したらデバッグして対応するという方針

チームでの取り組み

・Composeを導入すべき理由やメリデメについてチームで認識をそろえた上で導入を進めた・作業分担することでチームメンバーがComposeに触れる機会を積極的に作った社内勉強会にて・導入の最初は、　リプレイスの一例を作った上でチームメンバーに展開した少人数で進め迅速にComposeの基盤を作り上げチームでの取り組み

今後の課題・RecyclerViewの計測ログの移行・xmlで作成されているカスタムビューをComposeに移行する・コーディング規約の策定・Figma x Compose によるコンポーネント自動生成・画面全体をリプレイスするComposeマラソンなどの取り組み

感想

良かったところ・UIに集中できるためリストのitemごとにComposeリプレイスがおすすめ・画面状態が複雑な画面でもUIを構築しやすい・アニメーションを直感的に記述できる

大変だったところ・アニメーションを入れると@Stableを意識しなければならなくなる場面が多い・recomposition起因のバグはレビューで気づきにくい・xmlの一部をComposeにする場合はパフォーマンスが少し不安

Thankyou

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

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

Yamashita Shun

Other Decks in Programming

Featured

Transcript