Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Yamashita Shun

August 19, 2022
Tweet

Other Decks in Programming

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