需要监控、分诊、降低 App 崩溃率时用：接入…

当你要监控、分诊或降低 App 崩溃率，并评估崩溃对 App Store 排名、推荐资格和评分的影响时使用。

适用场景

解决思路

1. 将稳定性目标设为：crash-free sessions > 99.5%，crash-free users > 99%。
2. 把崩溃率当作 ASO 信号处理：高崩溃率会影响 App Store 排名、编辑推荐资格、评分与次日留存。
3. 选用 Firebase Crashlytics 获取实时崩溃、ANR、符号化堆栈；接入方式为添加 FirebaseCrashlytics pod/SPM package。
4. 用 App Store Connect 查看崩溃率趋势与每会话崩溃数，无需写代码。
5. 用 Xcode Organizer 查看来自 TestFlight + App Store 的聚合崩溃日志：Xcode → Window → Organizer → Crashes。
6. 用 MetricKit 获取设备端诊断、hang rate、启动时间；iOS 13+，自动生效。
7. 推荐组合：Crashlytics（实时告警 + 搜索）+ App Store Connect（趋势验证）。
8. iOS 在 AppDelegate 或 @main App struct 中 import FirebaseCore 和 FirebaseCrashlytics，并在 init 中调用 FirebaseApp.configure()；Crashlytics 会自动初始化。
9. 记录非致命错误：调用 Crashlytics.crashlytics().record(error: error)。
10. 设置自定义调试键：Crashlytics.crashlytics().setCustomValue(userId, forKey: "user_id")，setCustomValue(screenName, forKey: "current_screen")。
11. Android 在 build.gradle (app) 添加 implementation("com.google.firebase:firebase-crashlytics:18.x.x")；无需额外代码即可自动捕获未处理异常。
12. Android 记录非致命错误：FirebaseCrashlytics.getInstance().recordException(throwable)。
13. 按 Priority Score = Crash Frequency × Affected Users × User Segment Weight 对崩溃排序。
14. P0 — Critical：影响启动/结账/核心功能的崩溃，且 >1% sessions；今天修复。
15. P1 — High：常见流程中的崩溃，且 >0.1% sessions；本版本修复。
16. P2 — Medium：边缘场景崩溃，且 <0.1% sessions；下个版本修复。
17. P3 — Low：罕见、非阻塞崩溃，且 <0.01% sessions；放入 backlog。
18. 在 Crashlytics Dashboard 中按 Impact（受影响唯一用户数）排序，而不是按频率排序。
19. 将崩溃分组为：onboarding、checkout、core feature、background、launch。
20. 给前 3–5 个问题分配 P0/P1。
21. 在 Crashlytics 中为任何影响 >0.5% 用户的问题设置 velocity alert。
22. 阅读崩溃报告时：在 Xcode 中打开对应文件与行（如 UserProfileVC.swift:87）。
23. 检查该位置可能为 nil 的内容。
24. 结合用户上下文（OS version、device、screen）复现。
25. 修复前先写一个失败测试。
26. 确保上传 dSYMs，让 Crashlytics 自动符号化；若看到未符号化堆栈，执行：./Pods/FirebaseCrashlytics/upload-symbols -gsp GoogleService-Info.plist -p ios MyApp.app.dSYM。
27. 若构建启用 Bitcode，从 App Store Connect → Activity → Build → dSYMs 下载 dSYMs。
28. 在 App Store Connect → App Analytics → Crashes 查看每个版本的崩溃率趋势。
29. 对比每次发布前后的崩溃率。
30. 若某个特定版本出现尖峰，视为该版本引入的回归。
31. 按公式计算崩溃率：Crashes / Sessions × 100。
32. iOS 使用分阶段发布：App Store Connect → Version → Phased Release（7 天 rollout：1% → 2% → 5% → 10% → 20% → 50% → 100%）。
33. Android 使用 Play Console → Production → Managed publishing → Rollout percentage 控制发布比例。
34. 每个阶段监控 Crashlytics 24 小时；若 crash rate 增加 >0.2%，暂停 rollout。
35. 处理崩溃引发的 1 星评价：先识别出现崩溃相关 1 星的 app version。
36. 修复该崩溃。
37. 回复每条崩溃相关评论："Fixed in version X.X — please update"。
38. 更新发布后，使用 rating-prompt-strategy 恢复评分。
39. 按 Crash Audit Report 格式输出审计报告，包括：Stability Report — [App Name] v[version] ([period])、Crash-free sessions、Crash-free users、Top crash issues。
40. 在报告中列出 P0 Issues：异常类型、用户数、sessions 百分比、文件:行、原因假设、具体修复动作。
41. 在报告中列出 P1 Issues：异常类型、用户数、sessions 百分比等。
42. 给出 Action Plan：Today 修复 P0 并发布 hotfix；This week 修复 P1 并入 v[X.X]；Monitoring 设置 0.5% session 阈值 velocity alert。
43. 关联技能：整体分析看 app-analytics；修复崩溃 1 星后用 rating-prompt-strategy；回复评论用 review-management；关注崩溃对 Day 1 留存影响用 retention-optimization；崩溃率 >2% 会失去编辑推荐资格，见 app-store-featured。

适用边界 · 注意事项

• 如果目标是搭建整体分析体系（不止崩溃），应改用 app-analytics。
• 未接入 Firebase Crashlytics / App Store Connect / Xcode Organizer / Play Console 等工具时，本技能中的具体接入与分阶段发布步骤无法直接执行。
• 崩溃率不是当前优化目标，或只需通用日志采集而非 App Store/移动端稳定性时，不适用。