axiom-app-store-connect-ref

App Store Connect 参考

概览

App Store Connect（ASC）为你的 App 提供崩溃报告、TestFlight 反馈和性能指标。本参考介绍如何在 ASC 中查找并导出崩溃数据以供分析。

ASC 与 Xcode Organizer 对比

任务	最佳工具
开发期间快速排查崩溃	Xcode Organizer
查看团队范围的崩溃情况	App Store Connect
查看带有截图的 TestFlight 反馈	App Store Connect
查看历史指标和趋势	App Store Connect
下载崩溃日志以供分析	两者均可（ASC 的导出功能更好）
符号化	Xcode Organizer

---

前往崩溃数据页面

崩溃页面路径

App Store Connect
└── My Apps
    └── [Your App]
        └── Analytics
            └── Crashes

直接 URL 模式： https://appstoreconnect.apple.com/analytics/app/[APP_ID]/crashes

崩溃仪表板各部分

1. 筛选栏 — 平台、版本、日期范围、对比
2. 无崩溃用户数图表 — 每日百分比趋势线
3. 按版本统计的崩溃数 — 对比各版本的柱状图
4. 主要崩溃特征 — 按占比排序，显示异常类型和函数名称

关键指标说明

指标	含义
无崩溃用户数	未遇到崩溃的每日活跃用户所占百分比
崩溃数	收到的崩溃报告总数
崩溃率	每 1,000 个会话中的崩溃数
受影响设备数	发生崩溃的唯一设备数量
崩溃特征	具有相同堆栈跟踪的崩溃分组

筛选选项

筛选条件	用途
平台	iOS、iPadOS、macOS、watchOS、tvOS
版本	深入查看特定 App 版本
日期范围	过去 7/30/90 天或自定义范围
对比	对比不同版本的崩溃率
设备	按 iPhone 型号、iPad 等筛选
OS 版本	查找特定 OS 版本上的崩溃

---

查看单个崩溃报告

崩溃特征详情

每个崩溃特征都会显示：

• 标题 — 异常类型、受影响设备数、崩溃占比，以及首次出现日期
• 异常信息 — 类型（例如 EXC_BAD_ACCESS）、代码和地址
• 崩溃线程 — 包含二进制文件、函数和偏移量的堆栈帧
• 分布情况 — 按 iOS 版本和设备型号细分

下载崩溃日志

1. 点击某个崩溃特征
2. 找到下载日志按钮（右上角）
3. 选择格式：
   • .ips（JSON 格式，iOS 15+）
   • .crash（文本格式，旧版）
4. 使用 crash-analyzer Agent 解析：/axiom:analyze-crash

---

TestFlight 反馈

反馈页面路径

App Store Connect
└── My Apps
    └── [Your App]
        └── TestFlight
            └── Feedback

反馈条目内容

每条反馈都包含：

字段	说明
截图	测试人员看到的内容（通常最有价值）
评论	测试人员对问题的描述
App 版本	确切的 TestFlight 构建编号
设备型号	iPhone 15 Pro Max、iPad Air 等
OS 版本	iOS 17.2.1 等
电池电量	电量低可能影响行为
可用磁盘空间	磁盘空间不足可能导致写入失败
网络类型	WiFi 或蜂窝网络
地区设置	语言和地区设置
时间戳	提交时间

筛选反馈

筛选条件	用途
构建版本	聚焦特定 TestFlight 构建版本
日期	优先查看最新反馈
包含截图	快速查找视觉问题

限制：无法回复

TestFlight 反馈是单向的。你无法通过 ASC 回复测试人员。如需跟进：

• 通过 TestFlight 群组邮件联系
• 添加 App 内反馈机制
• 在 TestFlight 备注中提供你的邮箱

---

指标仪表板

指标页面路径

App Store Connect
└── My Apps
    └── [Your App]
        └── Analytics
            └── Metrics

可用指标类别

类别	显示内容
崩溃	无崩溃用户数、崩溃次数、主要签名
卡顿率	主线程卡顿 > 250ms
磁盘写入	过多的磁盘 I/O 模式
启动时间	应用启动性能
内存	峰值内存使用量、终止次数
电池	前台/后台能耗
滚动	滚动卡顿率

终止（非崩溃导致的强制退出）

Metrics 面板会显示不会生成崩溃报告的终止情况：

终止类型	原因
内存限制	Jetsam 因内存压力强制结束应用
CPU 限制（后台）	超出后台 CPU 配额
启动超时	应用启动耗时过长
后台任务超时	后台任务超出时间限制

比较版本

使用 Compare 筛选器查看：

• 崩溃率是改善了还是恶化了？
• 哪个版本引入了峰值？
• 各版本发布后的性能趋势

---

导出数据

手动导出

1. 前往 Crashes 或 Metrics
2. 使用日期范围筛选器选择时间段
3. 点击 Export（如果可用），或下载单个崩溃日志

App Store Connect API

如需自动导出，请使用 App Store Connect API：

# Get crash diagnostic insights
GET /v1/apps/{id}/perfPowerMetrics

# Authentication requires API key from ASC
# Users and Access → Keys → App Store Connect API

API 功能：

端点	数据
perfPowerMetrics	性能与电源指标
diagnosticSignatures	崩溃签名汇总
diagnosticLogs	单个崩溃日志
betaTesters	TestFlight 测试人员信息
betaFeedback	TestFlight 反馈条目

通过 MCP 访问

如果已配置 asc-mcp，你可以通过 Claude Code 以编程方式访问 ASC 数据：

手动执行的 ASC 操作	asc-mcp 工具
查看崩溃指标	metrics_app_perf, metrics_build_diagnostics
下载崩溃日志	metrics_get_diagnostic_logs
列出 TestFlight 测试人员	builds_get_beta_testers
查看应用评价	reviews_list, reviews_stats
回复评价	reviews_create_response
检查构建状态	builds_get_processing_state
导出销售数据	analytics_sales_report（需要 vendor_number）

设置和工作流：/skill axiom-asc-mcp

Xcode Cloud 集成

如果使用 Xcode Cloud，崩溃数据会与 CI/CD 集成：

• 查看每次工作流运行中的崩溃
• 比较不同分支之间的崩溃率
• 在崩溃激增时自动发出提醒

---

最佳实践

每日监控

1. 检查无崩溃用户百分比
2. 查看是否有新的崩溃签名
3. 监控不同版本之间的回归情况

崩溃分类优先级

优先级	标准
P0 - 严重	>1% 的用户受到影响，存在数据丢失风险
P1 - 高	>0.5% 的用户受到影响，影响用户使用
P2 - 中	<0.5% 的用户受到影响，存在变通方案
P3 - 低	罕见、边缘情况、无影响

与版本发布相关联

每次发布后：

1. 等待 24-48 小时，让崩溃数据完成处理
2. 将无崩溃率与上一版本进行比较
3. 调查任何新的主要崩溃签名
4. 查看 TestFlight 反馈中的用户报告

---

常见问题

为什么在 ASC 中看不到崩溃？

原因	解决方法
时间太近	等待 24 小时完成处理
尚无用户	需要有活跃安装才能上报
用户选择退出	需要设备共享分析数据
构建未分发	必须通过 TestFlight 或 App Store 分发

为什么崩溃日志没有符号化？

如果你在分发期间上传了 dSYM，ASC 崩溃日志应该会自动符号化。dSYM 文件包含调试符号，可将内存地址映射回函数名称和行号。

验证 dSYM 是否已上传：

1. Xcode → Window → Organizer → Archives → 选择构建版本
2. 右键点击 → “Show in Finder” → 右键点击 .xcarchive → “Show Package Contents”
3. 检查 dSYMs/ 文件夹中是否包含 .dSYM 包

手动符号化工作流：

# 1. Download .ips file from ASC (Crashes → signature → Download Logs)

# 2. Find the binary UUID from the crash report
grep --after-context=2 "Binary Images" crash.ips
# Look for: 0x100000000 - 0x100ffffff MyApp arm64 <UUID>

# 3. Locate matching dSYM on your machine
mdfind "com_apple_xcode_dsym_uuids == <UUID>"

# 4. Symbolicate an address
atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp \
     -l 0x100000000 0x100045abc
# Output: -[UserManager currentUser] (UserManager.m:42)

常见的符号化失败情况：

症状	原因	解决方法
所有地址都未符号化	未上传 dSYM	从 Xcode Organizer 重新上传
只有你的代码未符号化	dSYM UUID 不匹配	从同一提交重新构建
系统框架未符号化	对特定设备而言属于正常情况	使用 atos 和设备支持文件
Bitcode 构建版本未符号化	Apple 重新编译了二进制文件	从 ASC 下载 dSYM：Xcode → Organizer → Download Debug Symbols

请参阅 crash-analyzer Agent，了解自动解析：/axiom:analyze-crash

ASC 与 Organizer：哪个堆栈跟踪更好？

两者显示的数据相同，但：

• Organizer 与 Xcode 项目集成（点击即可跳转到代码）
• ASC 更适合团队查看和追踪历史趋势

---

使用 MetricKit 进行现场诊断

如需设备级崩溃诊断、卡顿调用堆栈，以及 ASC 汇总仪表板之外的自定义遥测数据，请参阅 axiom-metrickit-ref。

主要区别：ASC 显示汇总趋势，便于团队查看。MetricKit 提供单台设备的诊断信息，你可以将其与自己的遥测数据关联起来。

---

相关内容

技能：axiom-testflight-triage（Xcode Organizer 工作流）、axiom-asc-mcp（通过 MCP 以编程方式访问 ASC）

Agent：crash-analyzer（自动解析崩溃日志）

命令：/axiom:analyze-crash

---

资源

WWDC： 2020-10076、2020-10078、2021-10203、2021-10258

文档： /app-store-connect/api、/xcode/diagnosing-issues-using-crash-reports-and-device-logs