compose-performance

Compose のパフォーマンス

基本原則

ユーザーから見える遷移を 1 つ測定し、処理を引き起こしている実行時の軸を特定してから、その軸が始まるフェーズまたは境界に最小限の修正を適用します。

手順

1. 具体的な遷移を 1 つ再現し、観測可能な証拠を記録します。 再コンポジション回数、コンパイラーレポート、プロファイラーデータ、または明確なトレースを確認します。 Gradle run のみを使用してビルドします。ビルドを実行できない場合は、宣言された型を基に推論し、ツールチェーンの JAR を展開したり、サンドボックスを回避したりしないでください。
2. 主な軸を分類します。パラメーターの安定性とスキップ、State の読み取りフェーズ、または以前のフェーズに書き戻されるスナップショット State のいずれかです。
3. 誤った手掛かりがないか確認します。実際のデータ変更、正確性の欠陥、または再コンポジションが想定される変更のない遅延アイテムなどです。
4. 変更を提案する前に、該当する詳細リファレンスを読みます。
5. レビュー作業では、指摘事項ごとに、証拠に基づく最小限の修正を示します。安定性に関する誤った約束がある場合は、可変の非スナップショットプロパティを不変データまたはスナップショットで監視可能な State に置き換え、その契約を検証してから、アノテーションが引き続き必要かどうかを判断するよう明示します。フェーズに問題がある場合は、変化する読み取りや計算を移動すべきレイアウトまたは描画のコンシューマーを示します。フェーズをまたぐ書き込みは、無効化または追加パスが発生することを示すものであり、値が繰り返し変化する証拠がない限り、振動や無限ループが起きると主張しないでください。診断だけで終わらせないでください。ソースコードしかない場合は、証明されたフィードバック経路と、測定されていない実行時コストを区別します。意図する測定境界に基づく条件付きの修正方針を示します。観測された問題が変化するという証拠なしに、パフォーマンス改善策としてコールバックの切り替え、等価性ガード、またはコンテンツレイアウトの書き換えを指示しないでください。デフォルトの構造的等価性ポリシーを使う mutableStateOf に保持された Int では、値が変わらなければ、すでに無効化は発生しません。
6. 一度に変更する軸は 1 つだけにし、同じ遷移を再測定します。
7. 状態変更を隠したり、古い値をキャッシュしたり、より適切でない所有者に処理を移したりすることなく、観測した境界で証拠が改善した時点で完了とします。

トピック別リファレンス

シグナル	参照先
原因が不明、または複数の軸が相互作用している可能性がある	診断
classes.txt、composables.txt、強いスキップ、不安定なパラメーター、またはコレクションの安定性	安定性
スクロール、アニメーション、ジェスチャー、レイアウト、または描画の State がフレームレートで読み取られる場合、あるいは測定された State がコンポジションにフィードバックされる場合	遅延読み取り
コンポーザブルがコンポジションローカルまたはアクセサー形式の値のみを読み取る	コンポジションの契約
State の所有権またはエフェクトのライフサイクルが根本原因である	Compose State とエフェクト