移动开发中的崩溃报告 — 它是什么、服务以及配置

什么是崩溃报告？

崩溃报告 — 是自动收集应用崩溃技术信息并将其集中发送到服务器进行分析的过程。与日志记录不同，崩溃报告记录的是紧急情况 — 应用被系统或操作系统强制终止的时刻。

每个崩溃报告包含三个关键组件：异常类型（NullPointerException、SIGSEGV、NSInternalInconsistencyException）、带有行号的完整调用堆栈以及环境信息 — 操作系统版本、设备型号、可用内存量。根据 Sentry Engineering, 2024，正是这三个元素的组合使得 85% 的关键错误得以重现和修复。

现代崩溃报告系统将功能扩展到普通崩溃之外。Firebase Crashlytics 自动将重复崩溃分组到 issues 中，Sentry 跟踪版本之间的回归，Bugsnag 显示用户到达错误的路径。所有三个服务都支持 iOS、Android、React Native 和 Flutter。

根据 Google I/O 2024，没有崩溃报告的应用平均花费 3–5 个工作日 来诊断一个关键错误，而使用 Crashlytics 则为 15–30 分钟。每个事件的时间节省超过 90%。

崩溃报告收集系统如何工作

架构 崩溃报告系统由三层组成：安装在应用中的客户端 SDK、用于接收和处理报告的服务器 API，以及用于分析的 Web 仪表板。客户端 SDK 捕获未处理的异常，将其序列化为 JSON，并在下次启动应用时发送到服务器。

崩溃报告的发送发生在应用重启后异步进行。这是一个关键点：在崩溃时刻，应用无法保证通过网络成功发送数据。SDK 将报告保存在本地存储中，并在下次启动时通过后台线程发送。根据 Firebase Engineering, 2024，这种方法确保了 99.7% 崩溃报告的送达。

对于非致命异常（try-catch 内的 handled exceptions），SDK 会立即发送报告，因为应用继续运行。非致命报告包含与崩溃相同的数据，但不会中断用户会话。这对于跟踪 API 请求错误、数据验证和业务逻辑特别有用。

崩溃分组 — 一种服务器算法，根据最后 5–10 个堆栈帧的哈希值合并相同的崩溃。这使得开发人员可以看到的不是 1000 个单独的报告，而是一个包含 1000 次出现、涵盖不同设备和操作系统版本的问题。

Firebase Crashlytics：集成与功能

Firebase Crashlytics — 最流行的移动应用崩溃报告服务，全球超过 300 万个项目 使用。免费套餐包括无限制报告、与 Google Analytics 集成以及自动崩溃分组。

在 Android 上集成 Crashlytics

连接 在 Android 上集成 Crashlytics 非常简单：在 build.gradle 中添加依赖并在 Application.onCreate 中初始化 SDK。Crashlytics 自动设置自己的 Thread.setDefaultUncaughtExceptionHandler，捕获所有未处理的异常。

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

关键功能 Crashlytics — 自定义键和日志。开发人员可以为每个崩溃报告添加最多 64 个键值对：屏幕状态、选择的套餐、用户级别。还可以记录按时间顺序进入报告的自定义日志消息。

Velocity Alert — 自动回归检测

Velocity Alert — Crashlytics 的一项功能，跟踪特定 issue 的崩溃数量激增。如果新版本发布后崩溃数量超过阈值，团队会在用户大规模投诉前 5–15 分钟收到 推送通知 和电子邮件。

触发阈值设置：关键 issues 为 1 小时内 2 倍。根据 Google, 2024，启用了 Velocity Alert 的团队发布热修复版本的速度比依赖手动仪表板监控的团队平均快 40%。

在 iOS 上集成 Crashlytics

在 iOS 上，Crashlytics SDK 通过 CocoaPods 或 Swift Package Manager 集成。SDK 通过自己的 mach exception handler 捕获 Objective-C 异常（通过 NSSetUncaughtExceptionHandler）和操作系统信号（SIGSEGV、SIGABRT）。

根据 Apple Developer, 2024，适用于 iOS 的 Crashlytics 处理高达 98% 的所有崩溃类型，包括标准机制无法捕获的低级内存错误。这使得 Crashlytics 成为 iOS 开发的事实标准。

Sentry 和 Bugsnag：替代平台

Sentry — 开源错误监控平台，支持 80+ 语言和框架。与 Crashlytics 不同，Sentry 面向后端开发人员，但为 iOS、Android、React Native 和 Flutter 提供完整的 SDK。

Sentry 的主要优势 — 性能监控 集成在单个仪表板中。开发人员不仅看到崩溃，还看到导致崩溃的事务：慢速网络请求、UI 冻结、长时间数据库操作。根据 Sentry, 2024，40% 的崩溃存在前期的性能问题，没有这种方法将无法被察觉。

Bugsnag 的错误分组方法不同 — 它分析的是用户旅程（user journey）而非调用堆栈。每个崩溃报告包含导致错误的屏幕和用户操作序列。这对于复杂的业务流程特别有用：下单、注册、支付。

服务价格各不相同：Crashlytics 在 Firebase 框架内免费，Sentry 提供每月 5000 个事件的免费套餐，Bugsnag 起价为每月 $29。所有三个平台都提供开源 SDK。服务的选择取决于团队规模、预算和数据安全要求。

iOS 上的崩溃报告：特性与 NSException

iOS 的特性 — 多层错误处理架构。崩溃报告 SDK 必须捕获 Objective-C 异常（NSException）、Swift 错误（Error）、POSIX 信号（SIGSEGV、SIGBUS）和 mach 异常。每种类型需要单独的捕获机制。

NSException — 通过 NSSetUncaughtExceptionHandler 捕获的最简单类型。然而，根据 Apple, 2024，现代 Swift 应用中只有 30% 的崩溃是 NSException。其余 70% 是操作系统信号和 Swift 运行时错误，需要 mach exception handler 机制。

iOS 开发人员应通过不同类型的本地生成崩溃来测试崩溃报告：信号使用 __builtin_trap()，异常使用 [NSException raise:...]，Swift 使用 fatalError()。只有这样才能确保 SDK 覆盖所有崩溃类型。

Android 上的崩溃报告：ANR 和原生崩溃

Android 增加了两个在 iOS 上不存在的特定崩溃类型：ANR（应用无响应） 和 C/C++ 代码中的原生崩溃。ANR 发生在 UI 线程被阻塞超过 5 秒时 — 系统显示“应用无响应”对话框并提供关闭选项。

标准的 Thread.setDefaultUncaughtExceptionHandler 不捕获 ANR，因为它不是异常，而是来自 ActivityManager 的信号。为了跟踪 ANR，Crashlytics 和 Sentry 使用一个后台 watchdog 线程，每 5 秒检查 UI 线程的响应能力。根据 Firebase, 2024，Android 上所有问题的 15% 是 ANR，而不是崩溃。

原生崩溃 在 Android 上发生在通过 JNI（Java Native Interface）运行的 C/C++ 代码中。这些崩溃不是 Java 异常，不会被 Thread.setDefaultUncaughtExceptionHandler 捕获。它们的处理使用 Google Breakpad 或 Crashpad，它们为 SIGSEGV、SIGABRT、SIGBUS 信号安装 sigaction 处理程序。

根据 Google I/O 2024，随着游戏引擎（Unity、Unreal Engine）和计算机视觉库（ML Kit、OpenCV）的普及，原生崩溃的数量正在增长。建议混合应用的开发人员始终连接原生崩溃报告。