Compose Performance Audit

概要

Jetpack Compose ビューのパフォーマンスを、計測とベースライン設定からルート原因分析と具体的な改善手順まで、エンドツーエンドで監査します。

ワークフロー判定ツリー

• ユーザーがコードを提供した場合は、「Code-First Review」で開始します。
• ユーザーが症状のみを説明した場合は、最小限のコード/コンテキストを要求してから「Code-First Review」を実行します。
• コードレビューが結論に至らない場合は、「Guide the User to Profile」に移行し、Layout Inspector の出力または Perfetto トレースを要求します。

1. Code-First Review

以下を収集します:

• 対象の Composable コード。
• データフロー: state、remember、derived state、ViewModel への接続。
• 症状と再現手順。

以下に注目します:

• Recomposition ストーム: 不安定なパラメータまたは広範な状態変更から。
• 不安定なキー: LazyColumn/LazyRow 内（key の変動、キーの欠落）。
• composition 内の重い作業: フォーマット、ソート、フィルタリング、オブジェクト割り当て。
• 不要な recomposition: remember の欠落、不安定なクラス、ラムダ式。
• 大きな画像: 適切なサイズ設定や非同期ロードなし。
• Layout の thrash: ネストが深い、intrinsic 測定、SubcomposeLayout の誤用。

提供内容:

• コード参照を含むルート原因の可能性。
• 提案される修正とリファクタリング。
• 必要に応じて、最小限の再現方法または計測提案。

2. Guide the User to Profile

データ収集方法を説明します:

• Android Studio の Layout Inspector を使用して recomposition カウントを確認します。
• Compose ツーリングで Recomposition Highlights を有効にします。
• Perfetto または System Trace を使用してフレームタイミング分析を行います。
• Macrobenchmark の結果でスタートアップ/スクロール メトリクスを確認します。

以下をリクエストします:

• recomposition カウントを示す Layout Inspector のスクリーンショット。
• Perfetto トレースまたは System Trace のエクスポート。
• デバイス/OS/ビルド設定（デバッグ vs リリース）。

重要: プロファイリングは release ビルド で R8 を有効にして実行してください。デバッグビルドにはかなりのオーバーヘッドがあります。

3. 分析と診断

Compose の可能性が高い問題を優先順位付けします:

• Recomposition ストーム: 不安定なパラメータまたは広範な状態変更から。
• 不安定なキー: lazy リスト 内（key の変動、インデックスベースのキー）。
• composition 内の重い作業: フォーマット、ソート、オブジェクト割り当て。
• remember の欠落: すべての recomposition で再作成が発生します。
• 大きな画像: Modifier.size() 制約なし。
• 不要な state の読み取り: 誤った composition フェーズで。

トレース/Layout Inspector からの証拠と共に検出結果を要約します。

4. 改善

対象を絞った修正を適用します:

• パラメータの安定化: データクラスに @Stable または @Immutable アノテーションを使用します。
• キーの安定化: LazyColumn/LazyRow アイテムに安定した一意の ID を使用します。
• state 読み取りの遅延: derivedStateOf、ラムダベースの modifier、または Modifier.drawBehind を使用します。
• 高コストな計算を remember: remember { } または remember(key) { } でラップします。
• recomposition をスキップ: 安定した composable を抽出し、key() でアイデンティティを制御します。
• 非同期画像ロード: Coil/Glide を適切なサイズ制約と共に使用します。
• layout の複雑さを削減: 階層をフラット化し、深いネストを避けます。

一般的なコード アンチパターン（と修正）

不安定なラムダキャプチャ

// BAD: 毎 recomposition で新しいラムダインスタンスが作成される
Button(onClick = { viewModel.doSomething(item) }) { ... }

// GOOD: remember またはメソッド参照を使用
val onClick = remember(item) { { viewModel.doSomething(item) } }
Button(onClick = onClick) { ... }

composition 内の重い作業

// BAD: 毎 recomposition でソート実行
@Composable
fun ItemList(items: List<Item>) {
    val sorted = items.sortedBy { it.name } // 毎 recomposition で実行
    LazyColumn { items(sorted) { ... } }
}

// GOOD: remember をキーと共に使用
@Composable
fun ItemList(items: List<Item>) {
    val sorted = remember(items) { items.sortedBy { it.name } }
    LazyColumn { items(sorted) { ... } }
}

LazyColumn でのキー欠落

// BAD: インデックスベースのアイデンティティ（リスト変更時に recomposition 発生）
LazyColumn {
    items(items) { item -> ItemRow(item) }
}

// GOOD: 安定したキーベースのアイデンティティ
LazyColumn {
    items(items, key = { it.id }) { item -> ItemRow(item) }
}

不安定なデータクラス

// BAD: 不安定（List を含み、これは安定していない）
data class UiState(
    val items: List<Item>,
    val isLoading: Boolean
)

// GOOD: 本当に不変の場合は Immutable とマーク
@Immutable
data class UiState(
    val items: ImmutableList<Item>, // kotlinx.collections.immutable
    val isLoading: Boolean
)

早すぎる state の読み取り

// BAD: composition 時に state を読み取り（ツリー全体が recompose）
@Composable
fun AnimatedBox(scrollState: ScrollState) {
    val offset = scrollState.value // スクロールのたびに recompose
    Box(modifier = Modifier.offset(y = offset.dp)) { ... }
}

// GOOD: state の読み取りを layout/draw フェーズに遅延
@Composable
fun AnimatedBox(scrollState: ScrollState) {
    Box(modifier = Modifier.offset {
        IntOffset(0, scrollState.value) // layout フェーズで読み取り
    }) { ... }
}

composition 内のオブジェクト割り当て

// BAD: 毎 recomposition で新しい Modifier チェーンを作成
Box(modifier = Modifier.padding(16.dp).background(Color.Red))

// GOOD（動的な modifier の場合）: modifier を remember
val modifier = remember { Modifier.padding(16.dp).background(Color.Red) }
Box(modifier = modifier)

安定性チェックリスト

型	デフォルトで安定?	修正
プリミティブ（Int、String、Boolean）	はい	N/A
安定なフィールドを持つ data class	はい*	すべてのフィールドが安定していることを確認
List、Map、Set	いいえ	kotlinx の ImmutableList を使用
var プロパティを持つクラス	いいえ	外部的に安定している場合は @Stable を使用
ラムダ式	いいえ	remember { } を使用

5. 検証

ユーザーに以下を実行するよう依頼します:

• Layout Inspector を再実行し、recomposition カウントを比較します。
• Macrobenchmark を実行し、フレームタイミングを比較します。
• release ビルドで実機でテストします。

提供されている場合は、差分（recomposition カウント、フレームドロップ、jank）を要約します。

出力

以下を提供します:

• 短いメトリクス テーブル（利用可能な場合は before/after）。
• 最上位の問題（影響度順）。
• 提案される修正と推定される作業量。

参考資料

• Jetpack Compose Performance
• Compose Stability Explained
• Debugging Recomposition
• Macrobenchmark