guide-swiftui-performance-audit

ガイドスキル — API リファレンスではなく、専門的なワークフロー／パターンのガイドです。 もともとは Thomas Ricouard による Dimillian/Skills のものです。MIT License。

SwiftUI パフォーマンス監査

クイックスタート

このスキルを使って、まずコードから SwiftUI のパフォーマンス問題を診断し、コードレビューだけでは症状を説明できない場合は、プロファイリングの証拠を求めます。

ワークフロー

1. 症状を分類します。描画の遅さ、スクロールのカクつき、CPU 使用率の高さ、メモリの増加、ハング、または過剰なビュー更新などです。
2. コードがある場合は、references/code-smells.md を使ったコード優先のレビューから始めます。
3. コードがない場合は、分析に必要な最小限の情報を尋ねます。対象のビュー、データフロー、再現手順、デプロイ先を確認します。
4. コードレビューで結論が出ない場合や、実行時の証拠が必要な場合は、references/profiling-intake.md を使ってプロファイリングの手順を案内します。
5. references/report-template.md を使って、考えられる原因、証拠、修正方法、検証手順をまとめます。

1. 情報収集

以下を収集します。

• 対象のビューまたは機能のコード。
• 症状と具体的な再現手順。
• データフロー：@State、@Binding、環境依存関係、監視可能なモデル。
• 問題が実機とシミュレーターのどちらで発生するか、また Debug と Release のどちらで確認したか。

可能であれば、問題を次のように分類してもらいます。

• CPU 使用率の急上昇またはバッテリー消費
• スクロールのカクつきまたはフレーム落ち
• メモリ使用量の増加または画像による負荷
• ハングまたは応答しない操作
• 過剰なビュー更新、または想定より広範囲に及ぶビュー更新

プロファイリングの情報収集チェックリスト全体については、references/profiling-intake.md を参照してください。

2. コード優先のレビュー

次の点に注目します。

• 広範囲な監視や環境値の読み取りによる無効化の多発。
• リストや ForEach での不安定な識別子。
• body やビュー構築処理内での重い派生処理。
• 複雑な階層、GeometryReader、または Preference の連鎖によるレイアウトの過剰な再計算。
• メインスレッドでの大きな画像のデコードまたはサイズ変更処理。
• 範囲が広すぎるアニメーションやトランジション処理。

問題の詳細な一覧と修正方法については、references/code-smells.md を参照してください。

次の内容を提示します。

• コード上の箇所を示した、考えられる根本原因。
• 推奨する修正とリファクタリング。
• 必要に応じて、最小限の再現例または計測方法の提案。

3. プロファイリングの案内

コードレビューで問題を説明できない場合は、実行時の証拠を求めます。

• トレースのエクスポート、または SwiftUI タイムラインと Time Profiler のコールツリーのスクリーンショット。
• デバイス／OS／ビルド設定。
• プロファイリング対象の具体的な操作。
• 変更を比較する場合は、変更前後のメトリクス。

具体的なチェックリストと収集手順については、references/profiling-intake.md を参照してください。

4. 分析と診断

• 証拠を、最も可能性の高いカテゴリに対応付けます。無効化、識別子の頻繁な変更、レイアウトの過剰な再計算、メインスレッドでの処理、画像の負荷、またはアニメーションの負荷です。
• 説明しやすさではなく、影響の大きさに基づいて問題に優先順位を付けます。
• コードからの推測と、トレースで裏付けられた証拠を区別します。
• プロファイリングがまだ不十分な場合はその点を明示し、不確実性を減らすために必要な追加の証拠を伝えます。

5. 修正

対象を絞って修正します。

• 状態のスコープを狭め、広範囲への監視の波及を減らします。
• ForEach とリストの識別子を安定させます。
• 重い処理は body の外に移し、入力に応じて更新する派生状態、モデル層での事前計算、メモ化されたヘルパー、またはバックグラウンドでの前処理を活用します。任意の計算用キャッシュとして場当たり的に使うのではなく、ビューが所有する状態にのみ @State を使います。
• 等価性の判定がサブツリーの再計算よりも低コストで、入力が真に値セマンティクスを持つ場合に限り、equatable() を使います。
• 描画前に画像をダウンサンプリングします。
• レイアウトの複雑さを軽減するか、可能な場合は固定サイズを使います。

例、Observation 固有の監視の波及に関するガイダンス、修正パターンについては、references/code-smells.md を参照してください。

6. 検証

同じキャプチャを再実行し、ベースラインのメトリクスと比較するようユーザーに依頼します。 提示された場合は、差分（CPU 使用率、フレーム落ち、メモリのピーク）をまとめます。

出力

以下を提供します：

• 簡潔なメトリクス表（利用可能な場合は変更前と変更後）。
• 影響度の高い順に並べた主な問題。
• 推定作業量を添えた修正案。

最終監査の書式には references/report-template.md を使用してください。

参考資料

• プロファイリングの受付と収集チェックリスト：references/profiling-intake.md
• よくあるコードの問題と修正パターン：references/code-smells.md
• 監査出力テンプレート：references/report-template.md
• ユーザーから提供された Apple のドキュメントと WWDC の資料は、references/ に追加してください。
• Instruments を使った SwiftUI パフォーマンスの最適化：references/optimizing-swiftui-performance-instruments.md
• SwiftUI のパフォーマンスを理解して改善する：references/understanding-improving-swiftui-performance.md
• アプリのハングを理解する：references/understanding-hangs-in-your-app.md
• SwiftUI のパフォーマンスを解き明かす（WWDC23）：references/demystify-swiftui-performance-wwdc23.md