AI Skills
xcode-compilation-analyzer

xcode-compilation-analyzer

熱門

使用建置時間摘要與 Swift 前端診斷，分析 Swift 及混合語言的編譯熱點，並產出以原始碼層級優化為優先的建議計畫。適用於開發者回報編譯緩慢、型別檢查警告、耗時的乾淨建置編譯階段、長時間的 CompileSwiftSources 任務、warn-long-function-bodies 輸出，或希望加速 Swift 型別檢查的情境。

1187星標
46分支
更新於 2026/4/15
獲取技能源代碼

相關技能

brainstorming4.5萬anti-reversing-techniques3.8萬doublecheck3.7萬
SKILL.md
readonlyread-only
name
xcode-compilation-analyzer
description

Analyze Swift and mixed-language compile hotspots using build timing summaries and Swift frontend diagnostics, then produce a recommend-first source-level optimization plan. Use when a developer reports slow compilation, type-checking warnings, expensive clean-build compile phases, long CompileSwiftSources tasks, warn-long-function-bodies output, or wants to speed up Swift type checking.

Xcode 編譯分析工具

當瓶頸在於編譯時間（而非一般專案設定）時，使用此技能。

核心規則

  • 從證據出發，最好是最近的 .build-benchmark/ 產出或原始時間摘要輸出。
  • 調查期間優先使用僅分析的編譯器旗標，而非直接修改專案設定。
  • 根據預期的實際時間影響排序發現，而非累計編譯時間影響。當編譯任務高度並行化（編譯類別總和 >> 實際時間中位數）時，請注意修正個別熱點可能提升並行效率，但不會減少建置等待時間。
  • 若證據指向並行工作而非序列瓶頸，將建議標示為「減少編譯器工作量（並行）」，而非「減少建置時間」。
  • 未經開發者明確同意，不得編輯原始碼或建置設定。

檢查項目

  • 乾淨建置與增量建置的 Build Timing Summary 輸出
  • 長時間執行的 CompileSwiftSources 或每個檔案的編譯任務
  • SwiftEmitModule 時間——大型模組中單行變更後可能達到 60 秒以上；若在增量建置中佔主導地位，表示模組可能過大或巨集過多
  • Planning Swift module 時間——若此類別在增量建置中異常大（每個模組最多 30 秒），表示意外的輸入失效或巨集相關的重新建置連鎖反應
  • 臨時執行以下旗標：
    • -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，並將其工作流程套用至相同專案環境。

偏好策略

  • 在建議永久修改建置設定前，先建議透過建置指令臨時注入旗標。
  • 優先將大型視圖建構器、閉包或結果建構器表達式縮小為較小的型別化單元。
  • 當能減少編譯器搜尋空間時，建議明確的匯入與協定型別。
  • 若混合語言邊界才是真正問題，而非單純的 Swift 語法，請特別指出。

其他資源