崩溃与诊断
崩溃是用户流失与审核被拒的头号原因。App Store Connect 的「崩溃（Crashes）」与「诊断（Diagnostics）」报告，能帮你快速发现稳定性问题并定位根因。
崩溃报告里有什么
进入 App Store Connect → 选择 App → Xcode 菜单中的「XCrashes」 或 「崩溃」页面，可以查看：
| 信息 | 用途 |
|---|---|
| 崩溃堆栈 | 崩溃时的函数调用链，定位到具体代码 |
| 崩溃类型 | SIGABRT、EXC_BAD_ACCESS、SIGSEGV、内存警告等 |
| 影响版本 | 判断是回归还是历史问题 |
| 影响设备/系统 | 是否集中在特定机型或系统版本 |
| 崩溃次数与用户 | 评估影响面与优先级 |
| 会话数/崩溃率 | 稳定性整体水位 |
阅读崩溃堆栈的关键点
- 找自己的代码：系统框架栈帧可以跳过，重点找
YourApp中的最后几帧。 - 关注崩溃类型：内存类（EXC_BAD_ACCESS）多与指针/生命周期相关；SIGABRT 多是断言、
fatalError或主线程问题。 - 结合版本：若只在某版本出现，对照该版本改动（git log）通常能快速定位。
- 符号化（Symbolication）：上传 dSYM 文件后，崩溃堆栈才能还原为可读的函数名与行号；务必在 CI 中配置 dSYM 上传。
崩溃报告默认可能只显示地址而不显示函数名，这就是「未符号化」。在 App Store Connect 中配置好 dSYM，或用 Xcode Organizer 导入，即可还原为可读堆栈。
诊断数据（Diagnostics）
除崩溃外，诊断页还提供：
- 卡顿 / 无响应（Hang）：主线程长时间阻塞，影响体验。
- 电量与资源：高能耗问题。
- 磁盘写入：异常高的磁盘 I/O。
这些问题虽不致命，但会显著影响口碑与留存，建议纳入稳定性看板。
稳定性闭环
- 发现：通过崩溃率趋势、版本对比发现异常升高。
- 定位：读堆栈 + 结合版本改动 + 复现。
- 修复：修复并补充回归用例；使用 TestFlight 先验证。
- 验证：发布后观察该版本的崩溃率是否回落。
建议为团队设定稳定性目标，例如「每个版本崩溃率低于 0.5%」「P0 崩溃 24 小时内响应」。有了量化门槛，稳定性才不会沦为口号。
自检清单
- CI / Xcode 已配置 dSYM 上传与符号化
- 已按版本 / 设备 / 系统筛选查看崩溃报告
- 高频崩溃已定位根因并安排修复
- 提审前已确认当前版本无 P0 崩溃
- 已关注卡顿 / 能耗等诊断数据
常见问题
- 看不到崩溃数据？ 检查 dSYM 是否上传、App 是否发布到 TestFlight / App Store、统计是否有延迟。
- 崩溃只在真机出现，模拟器不崩？ 很多崩溃与真实内存、后台、推送相关，必须真机验证。
- 第三方 SDK 导致的崩溃怎么办？ 升级 SDK、查看其已知问题，必要时在堆栈中确认后联系 SDK 方或自行规避。
- 崩溃率高但影响用户少怎么办？ 按「崩溃用户数 × 发生频率」综合排序，而不是只看次数。