WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Identify trends with the Power and Performance API

Identify trends with the Power and Performance API

Developer ToolsApp StorePerformance
观看原视频

Highlight

App Store Connect 在 2020 年把 Xcode Organizer 的聚合电量、性能、I/O 指标和诊断数据开放为 Power and Performance API，团队可以把趋势、回归和调用栈接入自定义 dashboard 与告警流程。

核心内容

Xcode 11 的 Organizer 已经能展示线上 App 的聚合电量、性能和 I/O 指标。问题在于，这些数据以前主要留在 Xcode 里。团队想把同一批数据放进自己的监控管线、dashboard 或 bug 系统时，只能靠人工查看，再把结论搬到别处。（00:48）

这场 session 给出的答案是 App Store Connect API 里的 Power and Performance API。它把 Xcode Organizer 背后的 metrics、diagnostics 和新的 smart insights 变成可编程访问的数据。数据来自用户同意共享的设备，Apple 在服务器侧聚合后，通过 API 提供给开发团队。（01:21）

API 的价值在发布之后最明显。新版本上线后，团队可以自动拉取最近版本的 productData 和 insights，观察 battery drain、launch、disk writes、hang rate 等指标在不同设备和百分位上的变化。出现回归时，再用 diagnostic signatures 找到主要问题组，拉取 diagnostic logs 看调用栈。（04:26）

演示里的 MealPlanner 就是这个流程。它新加了保存照片的功能，团队通过 API 发现最新版本在所有 iPhone 的 50th percentile 用户上出现 disk writes regression。接着请求 top diagnostic signatures，再下载对应 logs，最后从 call stack 追到新增照片功能造成的磁盘写入。（10:24）

详细内容

一条 API 链路覆盖趋势、回归和根因

（02:55）Apple 在这场 session 里介绍了四类 REST API 资源：用 App ID 获取最近版本的聚合指标和 insights；用 build ID 下载特定版本的指标；用 build ID 获取 top diagnostic signatures；用 signature ID 下载 diagnostic logs。官方 Code tab 展示了其中三条核心请求。

GET /v1/apps/{id}/perfPowerMetrics
GET /v1/builds/{id}/diagnosticSignatures
GET /v1/diagnosticSignatures/{id}/logs

关键点：

  • perfPowerMetrics 面向 App 资源，用来拿最近版本的聚合指标和 smart insights。
  • diagnosticSignatures 面向 build 资源，用来把同类问题聚合成可排序的问题组。
  • diagnosticSignatures/{id}/logs 面向具体 signature，用来下载可做根因分析的匿名诊断日志。
  • transcript 还提到一个按 build ID 下载特定版本 metrics 的资源，但本场 Code tab 没给出具体 URL，文章里不补写未展示的 endpoint。

perfPowerMetrics 返回 productData 和 insights

（04:48）应用级 metrics 请求使用 App ID。返回值是结构化 JSON，主要分成 productData 和 insights 两块。

GET /v1/apps/{id}/perfPowerMetrics

关键点：

  • {id} 是 App Store Connect API 里的 application ID。
  • productData 保存聚合 metrics。每个 metric 有自己的 metadata，例如 unit。
  • 每个 metric 和 device 的组合会给出 50th percentile 与 90th percentile。
  • metrics summary 覆盖最多 8 个最近 App 版本。
  • insights 用前面的 metrics 自动标记热点。session 里举的例子是 launch time 只在 90th percentile iPhone 用户上回归。

这一步适合做趋势 dashboard。后台任务按固定周期请求 perfPowerMetrics，按 metric、device、percentile 和 version 拆开存储，就能把 Xcode Organizer 里看到的趋势接进团队自己的工具。

访问 API 需要 App Store Connect token 和 metrics Accept header

（11:19）演示先用 App Store Connect API key 生成 access token，再用 token 请求 perfPowerMetrics。官方代码片段使用 curl 展示了两个关键 header。

curl -X GET -H "Authorization: Bearer ${JWT}" -H "Accept: application/vnd.apple.xcode-metrics+json,application/json" https://api.appstoreconnect.apple.com/v1/apps/${id}/perfPowerMetrics

关键点：

  • Authorization: Bearer ${JWT} 使用 App Store Connect API key 生成的 token。
  • Accept 同时声明 application/vnd.apple.xcode-metrics+json 和普通 JSON。
  • ${id} 是 MealPlanner 这类目标 App 的 App ID。
  • 响应会同时返回 productData 和 insights，演示随后直接检查 insights 里的 regression summary。

diagnostic signatures 把同类问题聚在一起

（08:19）发现回归后，下一步是从 build 维度拿 diagnostic signatures。session 明确说明，2020 年可以通过 Xcode 和 API 访问 disk writes diagnostic signatures。

GET /v1/builds/{id}/diagnosticSignatures

关键点：

  • {id} 是 App Store Connect API 提供的 build ID。
  • 返回的 data 列表包含多个 signature，每个 signature 有唯一 ID 和 attributes。
  • signature string 对应 Xcode UI 里的 call frame，用来代表这组调用栈。
  • weight 是归一化后的 signature weight，表示该 signature 的相对重要性。
  • response 里还会带一个 related URL，里面已经包含 signature ID，可继续请求 logs。

演示中，MealPlanner 先用最新 App 版本的 build ID 请求 top signatures，再取排名靠前的 disk writes signature 做下一步分析。

diagnostic logs 提供设备 metadata 和调用栈树

（09:42）拿到 signature ID 后，可以请求对应的 diagnostic logs。它包含来自单台设备的匿名诊断详情。

GET /v1/diagnosticSignatures/{id}/logs

关键点：

  • {id} 是上一条 diagnosticSignatures 响应里的 signature ID。
  • diagnosticMetadata 包含 deviceType、osVersion、buildVersion 等信息。
  • disk writes 这类事件会带 callStacks。
  • 每个 call stack frame 包含 rawFrame、parsed frame 信息和 subFrames。
  • 沿着 subFrames 从 root frame 向下遍历，就能还原完整调用栈树。
  • transcript 明确提到，这个 call stack JSON 结构和 MetricKit 共享，适合复用解析逻辑。

演示的最后一步是把 call stack pretty-print 出来。Yeounoh 从底部 frame 往上看，定位到新增的保存照片功能造成 heavy disk writes I/O，然后回到源码位置做优化。（13:22）

核心启发

  • 做什么：做一个发布后性能趋势 dashboard。 为什么值得做：perfPowerMetrics 给出最近版本的聚合 metrics，数据粒度包含 metric、device、50th percentile 和 90th percentile。 怎么开始：用 App ID 定时请求 GET /v1/apps/{id}/perfPowerMetrics，把 productData 按版本写入时序库，先画 launch、battery drain、disk writes 和 hang rate 四条趋势。

  • 做什么：把 smart insights 接进回归告警。 为什么值得做：insights JSON 直接包含 analyzed versions、regression summary、impacted devices 和 percentiles，适合变成可读告警。 怎么开始：每次新版本有足够线上数据后读取 insights，把 summary string、受影响设备和 percentile 写进 Slack 或 issue tracker。

  • 做什么：自动生成 diagnostic triage 工单。 为什么值得做：diagnosticSignatures 会把同类问题聚合并给出 weight，团队可以先处理影响最大的 signature。 怎么开始：对异常 build 请求 GET /v1/builds/{id}/diagnosticSignatures，按 weight 排序，把 signature string 和 related logs URL 附到工单里。

  • 做什么：复用一套调用栈解析器处理 API logs 和 MetricKit diagnostics。 为什么值得做：session 明确说 diagnostic log 的 call stack JSON 结构和 MetricKit 共享，同一个解析器可以覆盖服务端聚合日志和设备侧诊断。 怎么开始：从 GET /v1/diagnosticSignatures/{id}/logs 的 callStacks 入口开始，递归遍历 subFrames，输出可读的 frame 树和 device metadata。

关联 Session

评论

GitHub Issues · utterances