perfetto-trace-analysis

リソース

• ドメインヒント： 特定のパフォーマンス領域に関するリファレンスファイルです：CPU、Graphics、I/O、IPC、Memory、Power。各ファイルには、分析の指針となる、専門家が検証した強力なトレース分析手法が複数含まれています。
• Perfetto SQL リファレンス： 意図を有効なクエリに変換するためのガイドラインは、SQL リファレンスにあります。このリファレンスを必ず読み、すべての SQL 生成で実行プロトコルに従ってください。

セットアップフェーズ（必須）

1. スクラッチパッドを初期化する（証拠の連鎖）：
   • 作業メモリは、対象のトレースファイルとまったく同じディレクトリにあるローカルのスクラッチパッドファイルで管理してください。
   • ファイル名は、トレースのファイル名に _analysis.md を付けたものにします（例：[trace_filename]_analysis.md）。作成する前に、ディレクトリの内容を一覧表示して、同名のファイルがすでに存在するか確認してください。調査に偏りが生じないよう、存在を確認するためにファイルの内容を読んではいけません。存在する場合は、利用可能なファイル名が見つかるまで、バージョン番号を増やして付けてください（例：_v2.md、_v3.md）。以降のすべてのツール呼び出しでは、この正確なファイル名をハードコードしなければなりません。
   • このスクラッチパッドには、確認済みの事実のみを記録してください。記録するのは、タイムスタンプ、スライス名、スレッド ID（utid/tid）、スレッドの状態です。
   • スクラッチパッドに予備的な仮説や時期尚早な結論を書いてはいけません。これは厳密な証拠の連鎖です。
2. ドメインヒントを確認する： 各ファイルのドメインヒントを読み、利用可能な手法の概要を把握してください。調査の進行中にヒントを調べて取得する際は、この基礎知識を必ず活用してください。
3. SQL リファレンスを確認する： references/sql.md の SQL リファレンスを読み、すべての SQL 生成で実行プロトコルに従ってください。スキーマを推測してはいけません。
4. 対象の特定： ユーザーの依頼が広範（例：「アプリの動作が遅いのはなぜですか？」）で、パッケージ名が指定されていない場合：
   • クエリを実行して、アクティブなアプリケーションを特定します：sql INCLUDE PERFETTO MODULE android.startup.startups; SELECT package FROM android_startups;
   • 複数のパッケージが返された場合は、ユーザーに選択してもらいます。選択された package_name をスクラッチパッドに保存してください。

調査プロトコル

決定的な根本原因を特定するまで、次の反復ループに従ってください。

1. 仮説を立てる

• 優先順位付け： 仮説は、ユーザーのプロンプト > 「ドメインヒント」（CPU、Graphics、I/O、IPC、Memory、Power) > 一般知識の順に情報を用いて立ててください。専門家が検証した分析手法である「ドメインヒント」を必ず活用してください。
• 情報源の明示： 仮説の情報源を明確に示してください（例：「hints_io.md のヒントに基づくと……」）。
• 焦点の制約： 主要なボトルネックに焦点を当ててください。ユーザーが明示的に求めている場合、または他に明らかなボトルネックがない場合を除き、Binder トランザクションを深く調査するのは避けてください。
• 推論の説明： 新しいクエリを生成する前に、これまでの調査結果に基づく推論を簡潔に述べてください。

2. データを計画して収集する

• メトリクスを優先： カスタム SQL に進む前に、まずトレースメトリクスを使って高レベルの概要を把握してください（例：./trace_processor --run-metrics android_startup）。
• 広範囲から絞り込む： フィルターを最小限にした広範なクエリから始めてください。完全一致よりも、あいまい検索（例：GLOB '*abc*'）を優先してください。
• 時間の重なり： 時間で絞り込む際は、対象の時間範囲と重なるイベントを必ず確認してください（例：start1 < end2 AND start2 < end1）。これにより、範囲の境界をまたぐスライスを見落とさずに済みます。

3. 分析とドリルダウン (深さ優先)

• 証拠に基づく厳密性: 明示的なデータなしに結論を導き出してはいけません。
• ウォールタイムと CPU 時間: 長時間実行されているスライスが活発に計算していると仮定してはいけません。疑わしいスライスの正確なタイムスタンプ範囲について thread_state テーブルを照会し、スレッドが Running、Runnable (CPU 待ち)、または Sleeping/Uninterruptible Sleep (ブロック中) のいずれであったかを必ず確認する必要があります。
• 依存関係を追跡する: スレッドがブロック/待機している場合、それが何を待っているのか (Binder、Lock、I/O など) を必ず特定する必要があります。必要であればプロセス境界を越えてください。ブロッカーを特定せずに、待機中のスレッドについて調査を結論づけることはできません。

4. 徹底的な調査 (早々に諦めない)

• 複数のボトルネック: 複雑なパフォーマンス問題が単一の原因であることはまれです。最初の異常を発見しただけで調査を止めないでください。たとえ重大なボトルネック (例: エミュレータのグラフィック遅延) を発見したとしても、他の独立したシステム全体の問題 (例: ロック競合、I/O ストール) を探し続ける必要があります。他のボトルネックを見つけるには、「ドメインヒント」ファイル (CPU、Graphics、I/O、IPC、Memory、Power) の内容を検索し、専門家が検証した強力なトレース分析手法を取得して活用してください。関連する各ヒントを深く調査してください。
• グローバルな検証: 定期的に、最も長時間実行されているスライス (ORDER BY slice.dur DESC) と最も頻繁な D 状態についてシステム全体のクエリを実行し、ローカルの調査が無関係な大規模システムストールを見逃していないことを確認してください。
• 行き詰まっても粘り強く: 仮説が否定されたり、クエリが空の結果を返したりしても、結論を出さないでください。焦点を切り替え、検索条件を広げ (あいまい一致、より広い時間枠)、ミッションを続行してください。

最終レポート

依存関係の連鎖全体を根本原因までたどり、AND 徹底的な検索によって他に重大なボトルネックが存在しないことを確認した後にのみ: 1. 検証済みの証拠の連鎖を詳述して調査結果を要約します。2. 次のように締めくくります: 「これでトレース分析を終了します。証拠の連鎖全体は [scratchpad_filename] で確認できます。これらの特定のスレッドについてさらに詳しく掘り下げてほしい場合、またはバグレポートの作成を手伝ってほしい場合はお知らせください。」