compose-recomposition-performance

Compose の再コンポジションパフォーマンス

ルーターのみです。詳しい修正方法は、以下の専門スキルを参照してください。

3 つの軸

1. パラメーターの安定性／スキップ — Compose はこの再起動可能なコンポーザブルをスキップできますか。引数は安定していて、比較可能ですか。
2. State の読み取り場所 — フレームレートに関わる State は、コンポジション中に読み取られていますか。それともレイアウト／描画中ですか。
3. フェーズをまたぐ書き戻し — 後続フェーズでスナップショット状態に書き込み、先行フェーズを無効化していませんか。たとえば、コンポジション中のマップ／リストの変更によって同じコンポジションが再び無効化されるケースや、onSizeChanged（レイアウトフェーズ）が、コンポジション中に兄弟要素から読み取られる状態に書き込むケースです。

軸 2 と 3 は重なることがよくあります（たとえば、兄弟要素がコンポジション中に測定サイズを読み取る場合、遅延読み取りの違反であると同時に、レイアウトからコンポジションへの書き戻しでもあります）。軸 1 は独立しています。

ここから該当する専門スキルへ

主な疑い	次のスキル
スキップ、不安定なパラメーター、コンパイラー／composables.txt の変更	compose-stability-diagnostics
フレームレートに関わる State の読み取りフェーズ（コンポジションとレイアウト／描画）	compose-state-deferred-reads
コンポジション中の putAll ／マップの再構築／行をまたいだ height(state)	compose-state-deferred-reads — § 書き戻し
コンポーザブル本体でのフォーカス駆動の付随処理	compose-side-effects — snapshotFlow
複数の軸に関する証拠がある場合	該当するスキルを並行して適用します

レビューの順序

1. 1 つの遷移（フォーカス移動、挿入、スクロール）を再現し、どのコンポーザブルが再コンポジションされるかを記録します。
2. 変更されていない遅延読み込み項目で回数が急増する場合は、安定性を疑う前に書き戻し（コンポジション中の変更や行をまたぐ測定）を確認します。
3. スクロール／アニメーション中に毎フレーム回数が増える場合は、遅延読み取りを確認します。
4. データが安定しているにもかかわらずスキップされない場合は、パラメーターの安定性とコンパイラーレポートを確認します。
5. 修正のたびに再測定します。

誤った対処

次の変更では、再コンポジションの回数が減らないことがよくあります。

試み	失敗する理由
インラインの when (index) の代わりに remember(index) { isFirstRow(index) } を使う	入力が同じなので、スキップによるメリットはありません
読み取り専用の派生マップに ID キャッシュを使う	古いオーバーレイが使われる可能性があります。remember(keys) で十分です
測定対象の行と兄弟行の両方に mutableIntStateOf とレイアウトモディファイアを使う	測定のみの方法でない限り、兄弟行は引き続きコンポジション中にサイズを読み取ります
フォーカス移動のテストで両方の行に Exactly(1) を強制する	多くの場合、片方の行が 0 回しか再コンポジションされないのは正しい動作です
ラムダのキャプチャを安定化せずに状態を持ち上げる	毎フレーム新しいラムダインスタンスが作られ、引き続きスキップできません

適用しない場合

• 再コンポジションが実際のデータ変更を反映している場合、または問題がコストではなく正しさに関する場合。
• プロファイラーやコンパイラーのシグナルから問題が示されていない場合。

関連

• compose-state-authoring — mutableState* を安全に作成する方法。