应用崩溃：是什么、崩溃原因以及追踪方法

什么是应用崩溃

崩溃 — 由代码未处理的异常情况导致的意外程序终止。在移动操作系统中，崩溃会导致应用立即关闭并显示"应用已停止"屏幕或返回主屏幕。

崩溃分为两大类。 已处理的错误 — try/catch 块捕获异常，应用继续运行，可能丢失部分功能。未处理的崩溃 — 异常上升到操作系统级别，系统终止进程。第二种类型特别危险，因为用户无法保存数据。

拥有 200 万用户和 0.1% 崩溃率的系统每次发布会失去 2,000 名用户 。根据 Google Play Console (2024)，崩溃率超过 1.5% 的应用将被排除在推荐之外，并损失高达 30% 的自然流量。

移动应用中闪退的主要原因

NullPointerException (NPE) — Java/Kotlin 中的崩溃之王。尝试对空对象调用方法。在 Kotlin 中，由于 null safety，NPE 较少发生，但在使用 !! 运算符或与 Java 代码交互时仍可能出现。Google (2024) 估计：NPE 占所有 Android 应用崩溃的 25%。

IndexOutOfBoundsException — 使用不存在的索引访问列表元素。常见原因：数据以意外格式从服务器到达，UI 尝试显示不存在的位嬝。解决方案 — 在通过索引访问之前始终检查集合大小。

ANR (Application Not Responding) — Android 特有的问题。UI 线程被阻塞超过 5 秒。主要原因：在主线程上进行网络请求、繁重计算、与数据库同步。StrictMode 在 Android 中 有助于在开发阶段检测 UI 线程阻塞。

OutOfMemoryError (OOM) — 应用超出内存限制。在具有 2–4 GB RAM 的移动设备上，处理大图像或无分页的无限列表时常出现 OOM。解决方案 — Glide/Coil 用于加载图像，LruCache 用于缓存，RecyclerView 中的 ViewHolder。

运行时异常和致命错误

Runtime exceptions — 编译器在构建阶段不检查的错误。它们仅在特定设备上使用特定数据执行代码时出现。在 Java 中，这些是 RuntimeException 及其子类：NullPointerException、IllegalArgumentException、ArithmeticException。

致命错误 (FATAL) — 不是运行时，而是系统故障。Signal 11 (SIGSEGV) — 本机代码中的内存段违规。Signal 6 (SIGABRT) — 应用自身通过 abort() 引起的紧急终止。此类崩溃难以诊断，因为堆栈跟踪通常不显示可理解的上下文。

在 iOS 中，主要原因包括 NSInvalidArgumentException (参数中出现意外的 nil) 和 EXC_BAD_ACCESS（访问已释放的内存）。与 Objective-C 相比，Swift 减少了崩溃次数，但 ObjC 运行时和 C 库中的错误仍会导致故障。

崩溃日志的监控和收集

Firebase Crashlytics — 移动应用的标准。自动收集堆栈跟踪，添加日志、用户 ID 和设备元数据。按签名（错误类 + 行）对崩溃进行分组。Real-time alerts — 当崩溃率超过设定阈值（例如 >0.1%/小时）时发出通知。

Sentry — 功能更灵活的替代方案。允许创建自定义上下文、添加 breadcrumbs、配置应用内过滤以排除不重要错误。Source maps 适用于 Kotlin 和 Swift，可以查看源代码，而不是混淆后的名称。

Best practices 日志最佳实践：在执行危险操作前发送关键元数据。添加自定义键（API 版本号、最后屏幕、输入数据大小）。这可以将无用的堆栈跟踪转化为可操作的信息。

示例：在 Android 中配置 Crashlytics

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

undefined

Optional binding 和 null safety — 在 Kotlin 中使用 `?` 表示可空类型，`let` 和 `?:` 进行安全的 null 处理。在 Swift 中 — optionals 和 guard let。Modern Kotlin (2024) 添加了 Contract 注释：@ContractsDsl 可以声明函数不返回 null，编译器会检查这一点。

Error handling 在网络中 — 每个网络请求都必须处理超时、解析错误和服务器拒绝。Retrofit 使用 Result 类型 — 保证错误将被处理的密封类。No Exception 风格：使用 sealed Result 替代 try/catch 以显式处理成功和错误。

Feature flags — 无需发布新版本即可远程禁用有问题的功能。Firebase Remote Config 允许在不发布到商店的情况下更改应用行为。

逐步发布 — 将新版本发布给 5% 的用户并监控崩溃率。如果崩溃率保持在目标以下（通常 <0.1%），则扩展到 25%、50%、100%。Google Play Console 和 App Store Connect 支持分阶段发布，以便在超出阈值时自动停止。

发现错误时的行动计划

1: 分类 — 确定严重性：Critical（超过 1% 用户崩溃）、High（0.1–1%）、Medium（<0.1%）。对于 Critical 崩溃 — 立即响应。Google Play Console 根据受影响用户数量自动分类崩溃。

2: 堆栈跟踪分析 — 在 Crashlytics 中打开日志，查看确切的故障位置。检查自定义键：哪个屏幕、哪些数据、操作系统版本。与上次部署比较 — 崩溃通常由代码中影响意外使用场景的最新更改引起。

3: 重现 — 尝试在具有类似参数的设备或模拟器上重现崩溃。如果不成功，检查崩溃日志的模式：特定型号 (Samsung A10)、Android 版本 (API < 26)、locale。解决方案 — 添加覆盖场景的保护条件。

4: 修复和监控 — 优先发布热修复。发布后确保此类型的崩溃率降至零。编写回归测试 覆盖崩溃场景。没有测试，同样的错误可能在下次重构时再次出现。