WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Diagnose Power and Performance regressions in your app

Diagnose Power and Performance regressions in your app

XcodePerformanceMetricKitApp Store Connect
观看原视频

Highlight

Xcode Organizer 新增 Regressions 标签页，自动对比最近 16 个版本的性能数据，标记出电池、启动时间、挂起、内存、磁盘写入、滚动卡顿、异常终止七类指标的退化趋势，并按设备和用户百分位细分。

核心内容

你刚发了一个新版本。用户反馈说”有点卡”、“耗电快了”。你想定位问题，打开 Xcode Organizer，面对七大类指标、几十种设备型号、典型用户 vs 高频用户的不同数据——信息量太大，不知道从哪下手。

WWDC21 的解决方案是：让系统帮你找问题。

Xcode Organizer 新增了一个 Regressions 标签页。它自动分析过去 16 个版本的性能数据，识别出哪些指标在最新版本里明显变差了。每个回归都标注了：什么指标退化了、退化了多少、哪些设备和哪些用户群体受影响。

你打开 Regressions 标签页，看到三个问题：异常终止增加了、后台任务超时变多了、磁盘写入涨了 28%。按严重程度排序，逐个解决。

详细内容

Regressions 的检测原理

（03:01）

系统对每条指标做趋势分析：

  1. 取最近几个版本的平均值作为基线
  2. 比较最新版本的值与基线
  3. 如果趋势向上且最新值显著高于基线，标记为回归

示例：App 平均启动时间 1.1 秒，最新版本突然跳到 2.5 秒，Regressions 标签页会高亮显示这个问题。

关键点：

  • 分析覆盖最近 16 个版本
  • 支持按设备型号和典型/高频用户百分位筛选
  • 回归按指标类别和子类别分组展示

异常终止回归

（04:52）

异常终止分两类：前台崩溃（Illegal Instruction）和后台超时（Task Timeout）。

前台崩溃最糟糕——用户正在用 App，突然闪退回主屏幕。常见原因是访问了无效函数指针。Regressions 会显示：

  • 崩溃类型（Illegal Instruction / Bad Access 等）
  • 受影响设备和百分位
  • 最近四个版本的趋势图
  • 平均值 vs 最新值

示例数据：最新版本每 10 天崩溃 1 次（高频用户）。修复方向：检查是否有废弃的 @objc 方法被调用，或第三方 SDK 使用了无效指针。

关键点：

  • 前台崩溃对用户体验伤害最大，优先修复
  • 结合 Crash Diagnostics 查看具体堆栈
  • 参考 WWDC21 “Why is my app getting killed?” session 深入了解终止原因

后台任务超时回归

（06:27）

App 切到后台后有 30 秒执行时间，超时会被系统终止。Regressions 显示：最新版本每 3 天被后台终止 1 次。

后台终止比前台崩溃影响小，但发生频率更高。用户下次切回 App 时需要重新启动，导致慢启动体验。

修复方向：

  • 检查后台任务是否在适当时间调用了 endBackgroundTask
  • 利用 backgroundTimeRemaining 提前保存进度
  • 集成 UIKit 的 State Restoration，确保终止后能无缝恢复

关键点：

  • 后台终止频率通常高于前台崩溃
  • 30 秒是硬限制，不能延长
  • State Restoration 可以掩盖后台终止的负面影响

磁盘写入回归与反模式检测

（08:47）

磁盘写入过多会磨损存储硬件、造成 UI 卡顿、消耗电量。Regressions 显示磁盘写入增加了 28%。

Xcode 13 的 Organizer 在磁盘写入报告中新增了 Insights 字段。系统维护了一个已知反模式库，自动扫描上报的堆栈，匹配到反模式时直接给出优化建议。

示例：Top Signature 占 67% 的写入量，堆栈指向 SQLite 操作。Insights 建议：“Add an index”。

用 File Activities Instruments 验证修复效果：

  • 修复前：临时文件写入 180MB，引入 780ms 延迟
  • 添加索引后：该函数的写入降为 0，延迟消失

关键点：

  • Insights 覆盖 SQLite 索引缺失、过度写入临时文件等常见反模式
  • 反模式库会持续扩展
  • File Activities Instruments 是验证修复效果的最佳工具

App Store Connect API

（12:57）

如果你有自定义分析流水线，可以用 API 程序化获取同样的数据：

# 性能指标和回归洞察
GET /v1/apps/{application-id}/perfPowerMetrics
GET /v1/builds/{id}/perfPowerMetrics

# 诊断签名和日志
GET /v1/builds/{id}/diagnosticSignatures
GET /v1/diagnosticSignatures/{id}/logs

返回的 JSON 结构中，insights 包含所有检测到的回归，populations 列出受影响的设备和百分位。诊断签名的响应中包含详细堆栈和优化建议链接。

关键点：

  • API 返回的数据与 Xcode Organizer 完全一致
  • 适合集成到现有监控平台
  • 建议设置自动化流程，每次发版后拉取数据

核心启发

  1. 把”检查 Regressions”纳入发版流程。发版一周后打开 Xcode Organizer 的 Regressions 标签页，按严重程度排序处理：异常终止 > 任务超时 > 磁盘写入 > 其他指标。入口：Xcode → Window → Organizer → Regressions。

  2. 为 SQLite 表添加合适的索引。如果磁盘写入报告的 Top Signature 指向 SQLite 操作，大概率是缺少索引导致全表扫描。用 EXPLAIN QUERY PLAN 定位慢查询，添加索引后在 File Activities Instruments 中验证写入量变化。入口：Xcode Organizer → Disk Writes → Insights。

  3. 给后台任务加时间预算检查。在后台任务执行循环中定期检查 backgroundTimeRemaining，不足 10 秒时保存进度并主动结束。避免被动等待系统终止。入口：UIApplication.shared.backgroundTimeRemaining。

  4. 用 App Store Connect API 搭建性能监控流水线。编写定时任务每天拉取 /v1/builds/{id}/perfPowerMetrics，将数据存入时序数据库。设置告警：某指标退化超过 20% 时通知团队。入口：App Store Connect API + 自定义 dashboard。

  5. 关注 Top Percentile 用户的数据。典型用户的数据可能看起来正常，但高频用户（Top Percentile）往往最先遇到性能问题。Organizer 支持分别查看两类用户的数据，优先处理 Top Percentile 的回归。入口：Organizer 右上角百分位筛选器。

关联 Session

评论

GitHub Issues · utterances