crash-analytics

崩溃分析

帮助你排查、确定优先级并减少应用崩溃，同时了解崩溃率如何影响 App Store 的发现率和评分。

为什么崩溃率是 ASO 指标

• App Store 排名 — Apple 的算法会降低崩溃率高的应用的排名
• App Store 推荐 — 崩溃率高的应用不符合编辑推荐的资格
• 评分 — 崩溃是导致 1 星评价的首要原因
• 留存率 — 首次会话中发生崩溃会严重损害 Day 1 留存率

目标： 无崩溃会话 > 99.5% | 无崩溃用户 > 99%

工具

工具	提供内容	设置
Firebase Crashlytics	实时崩溃、ANR、符号化堆栈跟踪	添加 FirebaseCrashlytics pod/SPM package
App Store Connect	崩溃率趋势、每次会话的崩溃次数	内置，无需代码
Xcode Organizer	来自 TestFlight 和 App Store 的汇总崩溃日志	Xcode → Window → Organizer → Crashes
MetricKit	设备端诊断、卡顿率、启动时间	iOS 13+，自动启用

推荐： Crashlytics（实时提醒和搜索）+ App Store Connect（验证趋势）

Crashlytics 设置

iOS（Swift）

// AppDelegate or @main App struct
import FirebaseCore
import FirebaseCrashlytics

@main
struct MyApp: App {
    init() {
        FirebaseApp.configure()
        // Crashlytics is auto-initialized
    }
}

非致命错误（跟踪错误但不导致崩溃）

// Log a non-fatal error
Crashlytics.crashlytics().record(error: error)

// Log a custom key for debugging context
Crashlytics.crashlytics().setCustomValue(userId, forKey: "user_id")
Crashlytics.crashlytics().setCustomValue(screenName, forKey: "current_screen")

Android（Kotlin）

// build.gradle (app)
implementation("com.google.firebase:firebase-crashlytics:18.x.x")

// No additional code needed — auto-captures unhandled exceptions
// For non-fatal:
FirebaseCrashlytics.getInstance().recordException(throwable)

排查框架

并非所有崩溃都同等重要。请按影响确定优先级：

优先级分数 = 崩溃频率 × 受影响用户数 × 用户群体权重

优先级	标准	响应时间
P0 — 严重	启动、结账或核心功能时崩溃；影响 >1% 的会话	今天修复
P1 — 高	常见流程中崩溃；影响 >0.1% 的会话	本次发布修复
P2 — 中	边缘情况崩溃；影响 <0.1% 的会话	下次发布修复
P3 — 低	罕见、不阻断使用的崩溃；影响 <0.01% 的会话	纳入待办

Crashlytics 信息中心排查

1. 按 “Impact”（受影响的独立用户数）排序，而非按频率排序
2. 分组：onboarding、checkout、core feature、background、launch
3. 为排名靠前的 3–5 个问题分配 P0/P1 优先级
4. 在 Crashlytics 中设置速率提醒，监控任何影响 >0.5% 用户的问题

阅读崩溃报告

Fatal Exception: com.example.NullPointerException
  at com.example.UserProfileVC.loadData:87
  at com.example.HomeVC.viewDidLoad:45

Keys:
  user_id: 12345
  current_screen: "home"
  app_version: "2.3.1"
  os_version: "iOS 17.3"

调试步骤：

1. 在 Xcode 中打开对应文件和行（UserProfileVC.swift:87）
2. 检查该位置哪些值可能为 nil
3. 根据用户环境（OS 版本、设备、屏幕）复现问题
4. 修复前先编写一个失败测试

符号化

上传 dSYM 后，Crashlytics 会自动进行符号化。如果看到未符号化的跟踪信息：

# Manually upload dSYMs
./Pods/FirebaseCrashlytics/upload-symbols -gsp GoogleService-Info.plist -p ios MyApp.app.dSYM

对于启用了 Bitcode 的构建版本，可从 App Store Connect → Activity → Build → dSYMs 下载 dSYM。

App Store Connect 崩溃数据

• App Store Connect → App Analytics → Crashes — 各版本的崩溃率趋势
• 比较每次发布前后的崩溃率
• 某个特定版本出现峰值 = 该版本存在回归问题

崩溃率公式： 崩溃次数 / 会话数 × 100

尽量缩小影响范围的发布策略

使用分阶段发布，在全面推出前发现崩溃问题：

iOS： App Store Connect → Version → Phased Release（7 天逐步发布：1% → 2% → 5% → 10% → 20% → 50% → 100%）

Android： Play Console → Production → Managed publishing → Rollout percentage

规则： 在每个阶段监控 Crashlytics 24 小时。如果崩溃率上升 >0.2%，暂停发布。

应对崩溃导致的 1 星评价

1. 找出出现崩溃相关 1 星评价的应用版本
2. 修复崩溃问题
3. 回复每条崩溃相关评价：“已在版本 X.X 中修复 — 请更新”
4. 更新发布后，使用 rating-prompt-strategy 恢复评分

输出格式

崩溃审计报告

Stability Report — [App Name] v[version] ([period])

Crash-free sessions: [X]%  (target: >99.5%)
Crash-free users:    [X]%  (target: >99%)
Top crash issues:

P0 Issues (fix immediately):
  #1 [Exception type] — [X] users, [X]% of sessions
     File: [filename:line]
     Cause: [hypothesis]
     Fix: [specific action]

P1 Issues (this release):
  #2 [Exception type] — [X] users, [X]% of sessions
     ...

Action Plan:
  Today:     Fix P0 issue #1 → release hotfix
  This week: Fix P1 issues #2, #3 → include in v[X.X]
  Monitoring: Set velocity alert at 0.5% session threshold

相关技能

• app-analytics — 完整的分析技术栈；Crashlytics 是其中一部分
• rating-prompt-strategy — 修复崩溃导致的 1 星评价后恢复评分
• review-management — 回复崩溃相关评价
• retention-optimization — Day 1 崩溃会损害留存指标
• app-store-featured — 崩溃率 > 2% 不符合编辑推荐的资格