Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
タップルでComposeの段階的な導入を進めている話
Search
Yamashita Shun
August 19, 2022
Programming
1
690
タップルでComposeの段階的な導入を進めている話
Yamashita Shun
August 19, 2022
Tweet
Share
Other Decks in Programming
See All in Programming
Elm 0.19.0 Changes
bkuhlmann
0
490
はてなにおける CSS Modules、及び CSS Modules に足りないもの / CSS Modules in Hatena, and CSS Modules missing parts
mizdra
7
930
Random\Randomizer クラスで日常のあれこれを解決しよう! / Random\Randomizer class solves familiar trouble
cocoeyes02
0
240
Komplexe Oberflächen mit SVG und der Web Animation API
joergneumann
0
670
Amazon SQSコンシューマー疎結合への旅 - 出張! #DevelopersIO IT技術ブログの中の人が語る勉強会 #3
quiver
0
270
効率化に挑戦してみたらモバイル開発が少し快適になった話
ryunakayama
0
130
OpenAPIを中心に考えるAPI開発入門 / Introduction to API Development with a Focus on OpenAPI
seike460
PRO
2
170
Milestoner
bkuhlmann
1
410
初心者のためのRubyKaigi入門/RubyKaigi Introduction
a_matsuda
1
590
"config" ってなんだ? / What is "config"?
okashoi
0
240
Polars入門
daikikatsuragawa
1
100
Fast JSX: Don't clone props object #28768
yossydev
1
100
Featured
See All Featured
Designing on Purpose - Digital PM Summit 2013
jponch
110
6.5k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Designing Experiences People Love
moore
136
23k
Faster Mobile Websites
deanohume
299
30k
Gamification - CAS2011
davidbonilla
76
4.6k
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
Making the Leap to Tech Lead
cromwellryan
124
8.5k
Web Components: a chance to create the future
zenorocha
305
41k
How to Ace a Technical Interview
jacobian
272
22k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.6k
The Cult of Friendly URLs
andyhume
74
5.7k
Art, The Web, and Tiny UX
lynnandtonic
289
19k
Transcript
タップルで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