AI Skills
xcode-compilation-analyzer

xcode-compilation-analyzer

热门

使用构建时间摘要和Swift前端诊断来分析Swift及混合语言编译热点，然后生成优先推荐源码级优化方案。当开发者报告编译缓慢、类型检查警告、昂贵的干净构建编译阶段、长时间的CompileSwiftSources任务、warn-long-function-bodies输出，或希望加速Swift类型检查时使用。

1187Star
46Fork
更新于 2026/4/15
获取 Skill源代码

相关 Skills

brainstorming4.5万anti-reversing-techniques3.8万doublecheck3.7万
SKILL.md
readonly只读
name
xcode-compilation-analyzer
description

使用构建时间摘要和Swift前端诊断来分析Swift及混合语言编译热点，然后生成优先推荐源码级优化方案。当开发者报告编译缓慢、类型检查警告、昂贵的干净构建编译阶段、长时间的CompileSwiftSources任务、warn-long-function-bodies输出，或希望加速Swift类型检查时使用。

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 到 Objective-C 接口
  • 跳过框架限定且错过模块缓存重用的头文件导入
  • 从未被继承但缺少 final 的类
  • 内部符号上过于宽泛的访问控制（public/open）
  • 应分解为子视图的庞大 SwiftUI body 属性
  • 没有中间类型注释的长方法链或闭包

报告格式

对于每个建议，包括：

  • 观察到的证据
  • 可能受影响的文件或模块
  • 预期的等待时间影响（例如“预计将干净构建减少约2秒”或“减少并行编译工作，但不太可能减少构建等待时间”）
  • 置信度
  • 是否需要批准才能应用

如果证据指向项目配置而非源代码，请通过阅读其 SKILL.md 并将工作流应用于同一项目上下文，将其移交给 xcode-project-analyzer。

首选策略

  • 在推荐持久性构建设置更改之前，建议通过构建命令临时注入标志。
  • 优先将庞大的视图构建器、闭包或结果构建器表达式缩小为更小的类型化单元。
  • 当显式导入和协议类型化能减少编译器搜索空间时，推荐使用。
  • 指出混合语言边界是真正问题，而不仅仅是 Swift 语法本身。

附加资源