Firebase Crashlytics — 是什么，崩溃和故障诊断

什么是 Firebase Crashlytics

Firebase Crashlytics 是 Google 的一项免费服务，用于监控移动应用程序的稳定性，由 Google 于 2017 年与 Fabric 公司一起收购。Crashlytics 会自动收集有关每次应用程序故障的信息，根据堆栈签名对相同的崩溃进行分组，并根据受影响用户的数量确定优先级，在 Firebase 控制台中显示它们。

历史与演变

Crashlytics 于 2011 年作为 Fabric 平台的一部分推出，并迅速成为 iOS 崩溃报告的事实标准。在 2017 年被 Google 以约 20 亿美元（整个 Fabric）收购后，Crashlytics 被集成到 Firebase SDK 中。版本 18.0.0（2021）添加了对 Kotlin Multiplatform 的支持，版本 19.0.0（2024）添加了 Android 上无需额外配置的自动 ANR 收集。根据 Google（2026）的数据，Crashlytics 每月处理超过 100 亿次崩溃。

Crashlytics 的免费限制

Crashlytics 免费提供，每个 Firebase 项目每天限制 50 万次会话。对于大多数应用程序来说，这已经足够了 — 根据 Google（2026）的数据，95% 的项目不会超过限制。超出限制时，数据收集不会停止，但报告会停止更新，直到第二天。对于高负载项目，可以使用 Firebase 的 Spark 和 Blaze 套餐 — Crashlytics 在两个套餐中均保持免费，会话限制单独计算。

Crashlytics 如何检测和收集故障

收集机制 Crashlytics 基于在平台和运行时级别捕获异常。在 Android 上，SDK 实现了一个 UncaughtExceptionHandler，用于捕获所有未处理的 Kotlin 和 Java 异常。在 iOS 上，Crashlytics 使用 NSSetUncaughtExceptionHandler 处理 Objective-C/Swift，并使用自己的 Mach 异常处理程序处理原生代码崩溃。

捕获的故障类型

Crashlytics 区分五种类型的故障：fatal（致命崩溃）、non-fatal（手动传递的非致命异常）、ANR（Android — 应用程序无响应）、signal（操作系统信号 — SIGSEGV、SIGABRT）和 OOM（iOS 内存不足）。每种类型由单独的机制处理，并在控制台中用相应的标签显示。

故障报告格式

每份 Crashlytics 报告包含全面的信息：完整的堆栈跟踪，包括类名和行号、应用程序版本（versionName + versionCode）、设备型号、操作系统版本、可用内存量、屏幕方向和启动以来经过的时间。如果连接了 Firebase Analytics，报告还包含崩溃前用户最后 50 个事件的路径 — 这对于重现崩溃至关重要。

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

将 Crashlytics 集成到 Android 项目中

将 Crashlytics 连接到 Android 应用程序需要在 build.gradle 中添加两个依赖项并配置 Google Services 插件。SDK 会在 Firebase 初始化时自动启用崩溃报告，无需额外代码。为了正常运行，还需要 google-services 插件和来自 Firebase 控制台的 google-services.json 文件。

// build.gradle (project-level)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (app-level)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

配置 Crashlytics 插件

com.google.firebase.crashlytics 插件执行两项任务：生成唯一的构建标识符（build ID）用于映射混淆的堆栈，并自动为 Crashlytics SDK 创建资源。没有插件，崩溃将被标记为 “unmapped” — 您将只能看到混淆的类名（a.b.c），而无法找到源代码。插件将添加到根 build.gradle 和应用程序模块的 build.gradle 中。

检查集成

用于测试 Crashlytics 集成的是特殊的 forceCrash() 方法，该方法会生成一个测试异常。在生产构建中，此方法不可用。运行测试崩溃后，报告会在 1-5 分钟内出现在 Firebase 控制台中。如果报告未显示 — 请检查 google-services.json 是否与应用程序包匹配，以及 AndroidManifest 中是否有禁用数据收集的标志。

崩溃分析和报告分组

Crashlytics 控制台提供两个查看级别：按故障类型分组的所有崩溃（Issues）列表，以及每个 Issue 的详细报告，包含跟踪、统计数据和用户数据。每个 Issue 合并所有具有相同签名的崩溃 — 相同的异常类型和匹配的堆栈跟踪。

Issues 和分组

崩溃分组 — Crashlytics 的关键特性。该服务不会显示成千上万个单独的崩溃，而是根据指纹（堆栈跟踪的校验和）将它们合并到 Issues 中。一个 Issue 可以包含 1 到数百万个崩溃。每个 Issue 显示：致命情况的数量、唯一用户数、出现崩溃的应用程序版本以及遇到问题的用户百分比。

根据 Google（2026）的数据，平均 20% 的 Issues 造成了应用程序 80% 的致命崩溃（帕累托原则）。Crashlytics 根据严重性自动对 Issues 进行排序 — 受影响的用户越多，优先级越高。这使开发人员能够首先修复最普遍的问题。

按版本的统计信息

Crashlytics 单独跟踪每个应用程序版本的稳定性。crash-free users 图表显示每个版本中未遇到致命崩溃的用户百分比。如果更新时该百分比低于阈值（默认为 99%），Crashlytics 将通过电子邮件和 Firebase 控制台发送通知。这允许快速回滚有问题的版本或发布热修复。

自定义键、日志和 Breadcrumbs

Crashlytics 提供三种机制来丰富报告上下文：用于结构化数据的自定义键（keys）、用于文本跟踪的日志（logs）和来自 Analytics 的 Breadcrumbs（用户路径）。所有三种数据类型都附加到崩溃报告中，并在其详细卡片中可见。

自定义键

Custom Keys — 是随每次崩溃一起传递的键值对。每个应用程序最多 64 个键，每个键 — 长度最多为 1024 个字符的字符串。键用于标记应用程序状态：订阅级别、授权状态、上一个屏幕、VPN 是否开启。值会被覆盖 — 同名的新键将替换旧键。

事件日志记录

Custom Logs — 是 Crashlytics 存储在 64 KB 循环缓冲区中的文本消息。日志会自动附加到下一次崩溃。如果没有发生崩溃 — 日志不会传输到服务器（不消耗流量）。日志记录用于记录用户在故障前的步骤：“payment_processing_started”、“api_call_initiated”、“response_received_200”。

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

来自 Analytics 的 Breadcrumbs

如果项目中连接了 Firebase Analytics，Crashlytics 会自动接收 Breadcrumbs — 崩溃前的最后 50 个分析事件。每个 breadcrumb 包含事件名称及其参数。这允许重建导致故障的准确操作序列：用户打开屏幕 → 添加产品 → 转到支付 → 发生崩溃。Breadcrumbs 在 Issue 卡片的单独 “Logs” 选项卡中显示。

处理故障的最佳实践

Crashlytics 在正确配置上下文和 Issues 处理流程时最有效。实践表明，实施了崩溃处理规则的团队将关键错误的修复时间缩短了 60%（Google，2026 数据）。

Issues 优先级排序

并非所有崩溃都同等重要。根据用户数量和出现频率进行优先级排序有助于专注于最关键的问题。规则：在 24 小时内修复影响超过 0.1% 用户的 Issues。单次出现的 Issues（< 0.01%）可以推迟到下一个计划发布。Crashlytics 会自动标记回归 — 已修复但在新版本中再次出现的 Issues。

与 CI/CD 集成

Crashlytics API 允许通过 REST API 或 Firebase CLI 将故障报告集成到 CI/CD pipeline 中。在每个新版本中，可以自动检查 crash-free users 百分比是否超过阈值。如果超过阈值 — CI/CD 将阻止部署并向团队发送通知。Firebase CLI 支持 firebase crashlytics:builds:upload 命令用于上传 ProGuard/R8 映射文件 — 没有它们，堆栈将无法读取。

根据 Google（2026）的数据，在 CI/CD 中使用自动 crash-free 阈值检查的应用程序向生产环境发布的回归问题减少了 40%。建议的阈值：关键版本 crash-free users >= 99.5%，普通版本 >= 99.0%。