Xcode Compilation Analyzer

コンパイル時間が、単なる一般的なプロジェクト設定ではなくボトルネックに見える場合、このスキルを使用してください。

コアルール

• 証拠から始めてください。理想的には最近の .build-benchmark/ アーティファクトまたは生のタイミング集計出力です。
• 調査中は、永続的なプロジェクト編集よりも分析専用のコンパイラフラグを優先してください。
• 結果を累積コンパイル時間ではなく、期待される 実経過時間 への影響でランク付けしてください。コンパイルタスクが重度に並列化されている場合（コンパイルカテゴリの合計 >> 実経過時間の中央値）、個々のホットスポットを修正しても並列効率が改善される可能性があることに注意してください。ビルド待機時間は短縮されないかもしれません。
• 証拠が並列化されたタスクではなくシリアルボトルネックを指している場合、推奨事項を「コンパイラワークロードを削減（並列）」というラベルで表現してください。「ビルド時間を削減」ではなく。
• 明示的な開発者の承認なしに、ソースまたはビルド設定を編集しないでください。

検査対象

• クリーンビルドとインクリメンタルビルドの Build Timing Summary 出力
• 実行時間の長い CompileSwiftSources またはファイル単位のコンパイルタスク
• SwiftEmitModule 時間 -- 大規模なモジュールでは1行の変更後に 60秒以上に達する可能性があります。インクリメンタルビルドで支配的な場合、モジュールが大きすぎるか、マクロが多すぎる可能性があります
• Planning Swift module 時間 -- インクリメンタルビルドで不釣り合いに大きい場合（モジュール当たり最大30秒）、予期しない入力無効化またはマクロ関連のリビルドカスケードを示唆しています
• ad hoc 実行（以下のフラグ付き）:
  • -Xfrontend -warn-long-expression-type-checking=<ms>
  • -Xfrontend -warn-long-function-bodies=<ms>
• より詳細な診断フラグ（徹底的な調査用）:
  • -Xfrontend -debug-time-compilation -- ファイル単位のコンパイル時間（最も遅いファイルをランク付けするため）
  • -Xfrontend -debug-time-function-bodies -- 関数単位のコンパイル時間（フィルタリングなし、閾値ベースの警告フラグを補完）
  • -Xswiftc -driver-time-compilation -- ドライバレベルのタイミング（ドライバオーバーヘッドを分離するため）
  • -Xfrontend -stats-output-dir <path> -- コンパイル単位ごとの詳細コンパイラ統計（JSON）（根本原因分析用）
• ブリッジング作業を増やす Swift と Objective-C が混在するサーフェス

分析ワークフロー

1. 主な問題が広範なコンパイルボリュームなのか、それとも少数の極端なホットスポットなのかを特定してください。
2. タイミング集計カテゴリを解析し、最大のコンパイル貢献者をランク付けしてください。
3. 診断スクリプトを実行して、型チェックのホットスポットを表面化させてください:

   python3 scripts/diagnose_compilation.py \
     --project App.xcodeproj \
     --scheme MyApp \
     --configuration Debug \
     --destination "platform=iOS Simulator,name=iPhone 16" \
     --threshold 100 \
     --output-dir .build-benchmark
   

   これにより、ミリ秒の閾値を超える関数と式のランク付きリストが生成されます。診断アーティファクトをソース検査と並行して使用して、最も高コストのファイルから最初に焦点を当ててください。
4. 証拠を具体的な推奨リストにマッピングしてください。
5. コードレベルの提案をプロジェクトレベルまたはモジュールレベルの提案から分けてください。

Apple が導き出したチェック

まずこれらのパターンを探してください:

• 高コストの式における明示的な型情報の欠落
• 型チェックが困難な複雑なチェーンまたはネストされた式
• AnyObject として型付けされたデリゲートプロパティ（具体的なプロトコルの代わりに）
• 肥大化した Objective-C ブリッジングヘッダーまたは生成された Swift-to-Objective-C サーフェス
• フレームワーク修飾をスキップしてモジュールキャッシュの再利用を逃すヘッダインポート
• サブクラス化されない final が欠落したクラス
• 内部専用シンボルに過度に広いアクセス制御（public/open）
• サブビューに分解すべき巨大な SwiftUI body プロパティ
• 中間的な型注釈のない長いメソッドチェーンまたはクロージャ

レポート形式

各推奨事項について、以下を含めてください:

• 観察された証拠
• 影響を受ける可能性の高いファイルまたはモジュール
• 期待される実経過時間への影響（例："クリーンビルドを約2秒削減することが期待されます" または "並列コンパイル作業を削減しますが、ビルド待機時間を削減する可能性は低いです"）
• 信頼度
• 適用前に承認が必要かどうか

証拠がソースではなくプロジェクト設定を指している場合は、xcode-project-analyzer にその SKILL.md を読んで同じプロジェクトコンテキストにワークフローを適用することで引き継いでください。

推奨戦術

• 永続的なビルド設定の変更を推奨する前に、ビルドコマンドを通じた ad hoc フラグ注入を提案してください。
• 巨大なビュービルダー、クロージャ、または結果ビルダー式を、より小さい型付き単位に絞り込むことを優先してください。
• 明示的なインポートとプロトコル型付けを、コンパイラの検索空間を削減する場合に推奨してください。
• 混在言語境界が Swift 構文だけではなく、本当の問題である場合に呼び出してください。

追加リソース

• 詳細な監査チェックリストについては、references/code-compilation-checks.md を参照してください。
• 共有推奨構造については、references/recommendation-format.md を参照してください。
• ソース引用については、references/build-optimization-sources.md を参照してください。