Please enable JavaScript.
Coggle requires JavaScript to display documents.
Jetpack Composeのパフォーマンスについて - Coggle Diagram
Jetpack Composeのパフォーマンスについて
どういう問題があるのか?
スクロールで、要素が変更ないのでRecomposeされてしまう
LazyListState#firstVisibleItemScrollOffset
をつかった場合に起こりやすい
スクロール中から止まった場合など、スクロール中から止ったという変化のときだけ処理したい場合などは derivedStateOfを使うと良い
lintが入ってる
https://googlesamples.github.io/android-custom-lint-rules/checks/FrequentlyChangedStateReadInComposition.md.html
1アイテムに複数のcomposeがあって、その中の一部を更新したい場合でも、ほかのcompose関数がrecompose されてしまう。
どう対処するのか?
なぜ起こるのか?
なぜ起こるかを理解するために、仕組みの理解が必要
仕組みはどうなってる?
Composeには3つのフェーズがある
Composition・Layout ・Draw
Composition
コンポーザブルのツリーを構築する
ことで、何を表示するか決定する
What to show
Layout
ツリーを画面上のどこに表示するか決定する
Where to show
Draw
すべてを描画する
Draw to the screen
免責事項ある
全部従う必要はない
https://youtu.be/ahXLwg2JYpc?si=54xGyGritFHHVS3m
パフォーマンスの最適化は万能ではない
変数が多すぎるため
検査、改善、監視すること
・リリースモード
・リアルデバイス
・R8 有効
・ベースラインプロファイル
これらで確認すべきという話もあるが、遅いものは遅い
ぜんぜんデバッグビルドでカクつくことも余裕である
https://youtu.be/Z96wfbID_Yc?t=73
now in androidで計測した結果
話さないこと
一般的なパフォーマンスの話し
devfest
1.view時代からの脱却
ViewGroupのネストは最小にすべき
Viewの時代
ConstraintLayoutなどは子要素を二回測る
ComposeのLayoutのネストはそんなに気にしなくていい
描画フレーム(アニメーション)中の??
アニメーション中のGC
composeの場合
GCですべて止まるのはAPIレベル19まで。21以降は早いので小さいオブジェクト生成ならそんなに気にしなくていい
2 recompose
計算結果をキャッシュする
remember(contacts) { contacts.soretd() }
Recompositionを意識する
いつRecompositnが起こるのか
stateが変わるとき
listStte.firstVisibleItemIndex .> 0
derivedStateOfを使おう
stateの変化と値取得を意識する
3つのフェーズ
Composition
layout
Draw
Canvas { drawRect // drawのフェーズ }
あとのフェーズで実行するほうが早い
Stateへの書き込みが前のフェーズの読み込みに影響するのはご法度
まとめ
Recompositionを意識する
とくにスクロールなど何度も呼ばれる関数を使っている場合に、何度も呼ぶ必要があるのか、値の変化があった場合だけ知れればいいのかを考え、derivedStateOfが使えないか検討すると良さそう。
インスタグラムの検索のUIをつくった
動画のリストがあって、初期状態は1番目の動画が再生されています。
スクロールすると2番目の動画が再生され、1番目の動画は停止される