第1章 Crash治理概述
1.1 什么是Crash
说白了，Crash就是程序突然挂了。用户正刷着视频，突然闪退回到了桌面；或者你正用App付款，屏幕一黑，什么都没了。从技术角度看，Crash是进程因未捕获的异常、信号或系统级错误而非正常终止。
我个人的习惯是把Crash分成几类：
- 原生Crash —— C/C++层段错误、空指针、内存访问越界。
- Java/Kotlin异常 —— NullPointerException、IndexOutOfBoundsException等未捕获异常。
- ANR（应用无响应） —— 主线程阻塞超过5秒，系统弹出“应用未响应”对话框。
- 系统级Crash —— 资源耗尽、信号SIGKILL、驱动异常等。
小提示： 很多人只盯着Native Crash，其实Java层的Exception和ANR对用户伤害一点也不小。我在项目里见过因为一个空指针导致的线上崩溃率飙到3%，排查了两天才找到是某个第三方SDK版本升级后接口返回值变了。
1.2 为什么Crash治理这么重要
你想想看，一个App如果三天两头闪退，用户会怎么做？大概率直接卸载，顺便给个一星差评。Crash的影响是实打实的商业损失：
| 影响维度 | 具体表现 |
|---|---|
| 用户体验 | 闪退打断操作，降低满意度，增加用户流失 |
| 业务收入 | 支付流程Crash导致订单丢失，广告展示失败 |
| 品牌口碑 | 应用商店评分下跌，负面传播 |
| 开发效率 | 线上Crash需要紧急修复，打断正常迭代节奏 |
我记得有一次负责支付模块，上线后Crash率突然从0.2%跳到7%。当时正是双十一大促，每多一秒钟都有一堆订单在流失。团队通宵排查，最后发现是一个低版本Android系统上Bitmap复用带来的段错误。那一次让我深刻意识到：Crash治理不只是技术活，更是RMB活。
核心观点： Crash率每降低0.1%，次日留存可能提升0.5%～1.5%。这在我们公司的A/B实验中反复验证过。
1.3 治理目标：我们到底想要什么
很多人一上来就喊“零Crash”，我觉得不现实。纯Native代码、复杂多线程、低端机型，Crash永远不可能彻底消灭。我们的目标应该是：
- 快速发现 —— 线上Crash发生后，监控系统能在几分钟内报警。
- 精准定位 —— 根据堆栈、日志、设备信息，能直接定位到问题代码行。
- 高效修复 —— 热修复、灰度发布、配置下发，做到小时级止血。
- 持续防御 —— 通过静态检查、自动化测试、覆盖率分析，在上线前就拦截Crash。
避坑指南： 我曾经犯过一个错——把治理目标定成“零Crash”，然后拼命压死所有异常捕获。结果导致大量静默吞异常，用户操作失败但App没挂，问题却更难排查了。后来我明白了：Crash治理不是掩盖问题，而是要让问题暴露得更早、更准确。
1.4 本章知识体系总览
下面这张图概括了Crash治理的核心知识闭环：从理解Crash本质，到认识治理重要性，再到设定明确目标，最后通过工具集成和自动化手段落地。整个课程都会围绕这个闭环展开。
一句话总结： Crash治理不是查一个修一个，而是建立从“发生”到“预防”的持续改进体系。后面的29章，我们会把每个环节的工具和自动化方法讲透。