ios-performance-profiling

iOS パフォーマンスのプロファイリング

目的

このスキルは、適切なプロファイリングワークフローを選び、根拠を収集してパフォーマンスの兆候を解釈し、最適化が機能したと結論づける前に検証を推奨するために使用します。

このスキルは、プロファイリングの振り分けと根拠の収集ワークフローを担います。起動パフォーマンス、SwiftUI パフォーマンス、Swift Concurrency パフォーマンス、体感パフォーマンス、Swift ランタイムコストに関する、より具体的なスキルの代わりとして使用しないでください。

このスキルを使用する場面

次のようなタスクで使用します。

• Instruments のテンプレートまたはプロファイリングワークフローを選ぶ。
• トレース、スクリーンショット、XCTest メトリクス、MetricKit ペイロード、Organizer データ、ログ、サインポストを解釈する。
• ハング、アニメーションのカクつき、CPU スパイク、メモリの増加、リーク、ディスク I/O、ネットワーク遅延、電力使用量、本番環境でのリグレッションを診断する。
• 変更前後の測定計画を立てる。
• サインポストまたはパフォーマンステストを追加する。
• 提案された最適化が根拠に裏付けられているか確認する。

このスキルを使用しない場面

次のような場合は、主要なスキルとして使用しないでください。

• タスクで起動パフォーマンスのプロファイリング、測定、検証方法を尋ねられている場合を除き、アプリの起動アーキテクチャや起動に不可欠な作業。
• タスクで収集すべきプロファイリングの根拠を尋ねられている場合を除き、SwiftUI の無効化、アイデンティティ、レイアウト、スクロールの修正。
• タスクでタスクの動作、アクター間のホップ、エグゼキューター関連の遅延をプロファイリングする方法を尋ねられている場合を除き、Swift Concurrency の設計やアクター分離。
• タスクで体感遅延の検証方法を尋ねられている場合を除き、体感パフォーマンス、読み込み状態、スケルトン、楽観的 UI、フィードバックの設計。
• タスクで測定方法を尋ねられている場合を除き、Swift ランタイム、ARC、アロケーション、エグジステンシャル、ジェネリクス、ディスパッチ、リンクのコスト。

ユーザーがすでに分野を把握しており、測定ワークフローではなく修正を必要としている場合は、より具体的なスキルを優先してください。

基本原則

最適化の前に根拠を確認します。

次のループを使用してください。

Symptom -> reproducible scenario -> correct tool -> trace or metric -> hypothesis -> focused fix -> re-measure

検証手段がない限り、変更によってパフォーマンスが向上したと主張しないでください。根拠が不足している場合は、まだ証明されていない点と、次に測定すべき内容を伝えてください。

実施可能性の確認

実際のプロファイリングワークフローを推奨または実行する前に、何が利用可能かを確認してください。

次の点を質問するか、推測してください。

• ビルド可能な Xcode プロジェクト、ワークスペース、スキーム、ターゲットはありますか？
• 実機でプロファイリングできますか。それとも Simulator だけですか？
• Release または Release に近い構成を利用できますか？
• 安定したデータとアプリの状態で、シナリオを再現できますか？
• Instruments のトレース、スクリーンショット、MetricKit ペイロード、Organizer のスクリーンショット、ログ、XCTest の結果を利用できますか？
• トレースやレポートを成果物として共有できますか？
• タスクで求められているのは、プロファイリング計画、コードレビュー、既存の根拠の解釈のどれですか？

ツールや成果物が利用できない場合は、アプリをプロファイリングしたかのように装わず、測定計画を提示してください。

測定のベースライン

次を優先してプロファイリングしてください。

• UI、起動、電力、メモリプレッシャー、熱の動作、本番環境に近い応答性については、Simulator より実機を使用する。
• Debug ビルドより Release または Release に近いビルドを使用する。
• 1 回だけ測定するのではなく、複数回実行する。
• 入力データを安定させ、シナリオを決定論的にする。
• レポートにデバイスと OS の情報を含める。
• システムレベルのトレースが広範すぎる場合は、アプリ固有の処理の前後にサインポストを設定する。

相対的なローカル調査が目的で、その制約を明確に説明できる場合に限り、Simulator を使用してください。

ツールの選択

お気に入りのワークフローではなく、症状に応じてツールを選びます。

症状または質問	主なツール	補助的な手がかり
コールド起動、ウォーム起動、初回フレーム、最初の操作	App Launch、Time Profiler、XCTest の起動メトリクス	MetricKit、Organizer、signpost
メインスレッドの停止またはフリーズ	Hangs、Time Profiler	Main Thread Checker、signpost
アニメーションの引っかかり、スクロールの引っかかり、フレームのドロップ	Animation Hitches、Core Animation、Time Profiler	SwiftUI Instrument、signpost
SwiftUI での更新の繰り返し、または広範な無効化	SwiftUI Instrument	Time Profiler、signpost
CPU の急増または処理の遅延	Time Profiler	Counters、signpost、XCTest のメトリクス
メモリの増加、大量の割り当て、頻繁な確保と解放	Allocations、VM Tracker	Memory Graph、Leaks、XCTest のメモリメトリクス
参照サイクルまたは論理的なメモリリーク	Memory Graph Debugger	Allocations の世代分析
ディスクの読み書き、永続化の停止、過剰な書き込み	File Activity、System Trace	MetricKit のディスク書き込み診断
ネットワークの遅延または重複したリクエスト	Network instrument、URLSession メトリクス	signpost、サーバーのタイミング情報
バッテリー消費、熱的負荷、ウェイクアップ	Energy Log、Power Profiler	MetricKit、Organizer
本番環境でのみ発生するリグレッション	MetricKit、Organizer	Instruments を使ったローカルでの再現
リグレッションの防止	XCTest のメトリクス	CI の履歴、MetricKit のリリース比較

システムの計測ツールではアプリ固有の信号が十分に見えない場合は、処理の前後に os_signpost または OSSignposter を追加します。

スキル間のルーティング

このスキルを使って、プロファイリングの手順を選択し、検証します。より深い分野別の分析が必要な場合は、より専門的なスキルに振り分けます。

• プリメイン処理、dyld、静的イニシャライザー、アプリの初期化、ルートシーンの構築、初回フレーム、最初の操作、SDK の起動、データベースのウォームアップ、または起動に不可欠な依存関係チェーンが証拠から示唆される場合は、ios-launch-performance を使います。
• 広範な状態の読み取り、不要な無効化、不安定な識別子、高コストなレイアウト、行の複雑さ、スクロールの動作、または body の繰り返し処理が証拠から示唆される場合は、swiftui-performance を使います。
• タスクの過剰な生成、アクター間の移動、MainActor のボトルネック、キャンセルの欠如、AsyncSequence の負荷、エグゼキューターの動作、または非同期処理による UI の遅延が証拠から示唆される場合は、swift-concurrency-performance を使います。
• アプリは実際に処理を行っているものの、ユーザーから見た問題がフィードバックの欠如、不適切な読み込み状態、段階的な表示の遅れ、または体感上の遅延であることが証拠からわかる場合は、ios-perceived-performance を使います。
• 割り当ての頻発、ARC の処理、存在型、ジェネリクス、動的ディスパッチ、コピーオンライト、ブリッジング、リンク、またはランタイムレベルのコストが証拠から示唆される場合は、swift-runtime-performance を使います。

これらのスキルの詳細なガイダンスをここで重複させないでください。

プロファイリングのワークフロー

1. ユーザーから見える症状を特定します。
2. 症状を再現する正確なシナリオを定義します。
3. 症状に応じて主なプロファイリングツールを選びます。
4. デバイス、OS、ビルド構成、データセット、実行回数を記録します。
5. 最も有力な信号を取得します。スタック、フレームの引っかかり、割り当ての増加、参照経路、ネットワークのウォーターフォール、ディスク書き込み、ウェイクアップ、または本番環境のメトリクスなどです。
6. データが証明していることと、示唆しているにすぎないことを区別します。
7. 優先順位を付けた仮説を1つまたは2つ立てます。
8. 対象を絞った最小限の修正、または次の調査手順を提案します。
9. 同じシナリオでもう一度測定します。
10. 問題の重要度に応じて、リグレッションを防ぐ仕組みを提案します。

トレースの解釈ルール

トレース、レポート、スクリーンショットを読む際は、次の点に従ってください。

• 考えられる原因を幅広く並べるより、最も強い根拠を優先してください。
• ローカルトレースと本番環境のメトリクスを区別してください。
• CPU バウンド、ブロック中、待機中、I/O バウンド、メモリ圧迫、ネットワークバウンドの症状を区別してください。
• コストがユーザーに見えるクリティカルパス上にあるかを確認してください。
• 平均値は慎重に扱ってください。ハング、起動、本番環境のレイテンシでは、p95 や p99 のほうが重要なことがよくあります。
• 1 回正常に動作しただけで、問題が修正されたと判断しないでください。
• メモリの増加だけを根拠に、保持サイクルがあると推測しないでください。所有権のパスを調べてください。
• 経過時間の遅れだけを根拠に、CPU コストが原因だと推測しないでください。アプリが I/O、ロック、ネットワーク、メインアクターでブロックされている可能性があります。

修正の選定ルール

修正を推奨するのは、根拠と結び付けた後にしてください。

次を優先してください。

• クリティカルパス上の処理を遅延させる、または取り除く。
• 繰り返し行われる処理の範囲を絞る。
• 重複するリクエストや計算を減らす。
• あらゆる箇所に弱参照を追加するのではなく、所有権チェーンを修正する。
• ディスクへの書き込みをまとめる、または書き込み増幅を減らす。
• 画面に表示されなくなった処理や不要になった処理をキャンセルできるようにする。
• サインポストとテストを追加して、問題を継続的に観測できるようにする。

次のことは避けてください。

• トレースの根拠なしに広範囲な書き換えを行う。
• UI が引き続き処理を待っているか確認せずに、バックグラウンドキューへ処理を移す。
• 依存関係を理解する前に並列化する。
• クリティカルパス上にないコードを最適化する。
• 実際には測定していないことまでツールで証明できると主張する。

注意点

• Instruments はローカルの原因を明らかにし、MetricKit と Organizer は本番環境のシグナルを特定します。可能であれば両方を使用してください。
• 回帰の防止には、深い原因分析より XCTest のパフォーマンステストのほうが適しています。
• デバッグビルドでは、CPU、アロケーション、SwiftUI、並行処理の挙動が歪むことがあります。
• シミュレーターの結果は、起動、スクロール、メモリ圧迫、電力、熱の挙動について誤解を招くことがあります。
• ハングの原因は、メインスレッドのビジーループ、ロック競合、同期 I/O、アクターの待機、依存関係の循環などです。CPU 飽和と決めつけないでください。
• オブジェクトがまだ参照されている場合、保持サイクルの調査には通常 Leaks より Memory Graph のほうが適しています。
• アロケーションの急増が必ずしもリークとは限りません。世代をまたいだ増加や、保持されたオブジェクトグラフを探してください。
• ローカルの CPU トレースに問題がなくても、ネットワークウォーターフォールから画面の遅さの原因が分かることがあります。
• 電力の回帰は、タイマー、ポーリング、ウェイクアップ、バックグラウンドタスク、センサー、位置情報、画面外のアニメーションなど、小さな処理の繰り返しが原因であることがよくあります。
• 修正前後で再現可能な測定を行わずに、最適化が成功したと判断しないでください。

参考資料

関連する場合にのみ、以下をお読みください。

• references/tool-selection.md — 症状から Instruments のテンプレート、MetricKit、XCTest のメトリクス、サインポスト、または本番環境の診断方法を詳しく対応付ける必要がある場合にお読みください。
• references/time-profiler-and-hangs.md — Time Profiler、Hangs、メインスレッドのフリーズ、ブロックされたスレッド、ロック競合、同期 I/O、CPU スパイク、またはスタックの解釈が関係する場合にお読みください。
• references/animation-hitches-and-swiftui.md — アニメーションのカクつき、スクロールのカクつき、フレームのドロップ、Core Animation、SwiftUI Instrument、ビューの更新の繰り返し、フレーム予算、または UI の応答性に関するトレースが関係する場合にお読みください。
• references/memory-leaks-and-allocations.md — Allocations、Leaks、Memory Graph Debugger、VM Tracker、メモリの増加、保持サイクル、キャッシュ、デコード済み画像、または頻繁なメモリ割り当てが関係する場合にお読みください。
• references/network-disk-power.md — ネットワークの遅延、重複リクエスト、キャッシュの動作、ディスクの読み取り／書き込み、永続化の停滞、過剰なログ出力、バックグラウンド処理、ウェイクアップ、バッテリー消費、またはサーマルプレッシャーが関係する場合にお読みください。
• references/xctest-metrickit-organizer.md — XCTest のパフォーマンステスト、XCTApplicationLaunchMetric、CI の回帰ガード、MetricKit のペイロード、Xcode Organizer、本番環境での回帰、デバイスコホート、p95、または p99 が関係する場合にお読みください。
• references/signposts-and-scenarios.md — 再現可能なシナリオ、サインポストの計測、サインポストの命名、カスタムのトレース領域、変更前後の比較、またはプロファイリングレポートのテンプレートが必要な場合にお読みください。

出力の期待事項

ほとんどのプロファイリングタスクでは、次の形式で回答してください。

## Symptom

...

## Profiling path

Primary:
Secondary:
Why this tool:

## What to inspect

...

## Likely hypotheses

1. ...
2. ...

## Suggested fixes or next steps

...

## Verification

...

コードレビューでは、次の形式で回答してください。

## Summary

...

## Findings

### 1. Finding title

Risk:
Why it matters:
Suggested change:
How to verify:

## Profiling checklist

...

トレース、レポート、ログ、MetricKit のペイロード、Organizer のスクリーンショット、または Instruments のスクリーンショットについては、次の形式で回答してください。

## What the data shows

...

## Strongest signal

...

## Likely cause

...

## What is not proven yet

...

## Next step

...

## Verification

...

最終確認チェックリスト

パフォーマンスに関する回答を確定する前に、次の点を確認してください。

• ユーザーが目にする症状を特定しましたか？
• 症状に基づいてツールを選びましたか？
• 利用できる証拠と不足している情報を明示しましたか？
• ローカルのトレースと本番環境のメトリクスを区別しましたか？
• デバイス、OS、ビルド設定、データセット、実行回数を考慮しましたか？
• 証拠なしに断定していませんか？
• 関連する場合、実機での Release プロファイリングを推奨しましたか？
• 有用な場合、アプリ固有の操作にサインポストを提案しましたか？
• 一度に、対象を絞った修正または次の調査手順を1つ提案しましたか？
• 再測定の手順を含めましたか？
• 適切な場合、回帰を防ぐ手段として XCTest、MetricKit、または Organizer を提案しましたか？
• 証拠に裏付けられていない大規模な書き換えを提案していませんか？