移动端崩溃治理体系：从口径、归因到灰度闭环

崩溃率是移动端最硬的质量指标，但多数团队的治理是「哪里炸修哪里」，修了三年崩溃率还是降不下来。真正有效的治理是一套体系：统一采集口径 → 自动归因 → 分级处置 → 灰度验证。这篇按这套链路展开，适用于 Android（Android 17 / API 37 时代）与 iOS（iOS 26/27 时代）双端。

一、口径先行：崩溃率怎么算，决定了治理动作

推荐口径：崩溃率 = 当日发生崩溃的设备数 / 当日活跃设备数（按设备去重，而不是按次数）。同时把崩溃拆成四类分开统计，因为处置方式完全不同：

• Java/Kotlin 未捕获异常（Android）与 NSException/Swift Error fatal（iOS）——常规 bug，修代码即可；
• OOM——不是传统 crash，常被系统标记为 killed，需要内存水位与页面轨迹还原；
• ANR / Watchdog——主线程阻塞，需要看主线程堆栈与消息队列；
• Native Crash——so/dylib 符号还原是关键，删除符号表前务必归档对应版本。

二、采集：信息不全的崩溃日志等于没有

崩溃日志的最低配置：完整线程堆栈 + 设备/系统/版本/构建号 + 内存水位 + 页面路径（崩溃前访问的页面序列）+ Breadcrumbs（崩溃前最近的用户动作与网络请求摘要）。双端官方工具链：Android Studio 调试与 ANR 工具、Xcode Organizer 与 MetricKit。接第三方 APM 时注意一点——自建符号表服务或确认厂商符号表上传流程，混淆/ stripping 后没有符号还原，堆栈就是天书。

三、归因与分级：Top 1% 的崩溃占 80% 的量

聚合时按「堆栈签名」聚类（取堆栈最深的 app 包帧做指纹），而不是按错误消息。然后按影响面分级：

「新增崩溃」是治理的灵魂指标：每个版本发出去之前，对比上一版本，新引入的崩溃签名必须清零或给出豁免理由，这是崩溃率长期下降的唯一保障。

四、防复发：把稳定性做进流程

1. 灰度发布：新版本按 1% → 5% → 20% → 全量推进，每个台阶盯 24 小时崩溃率，异常自动暂停放量；
2. 启动路径重点保护：启动链路上的崩溃影响最大，这段代码的变更要求更高测试覆盖与更激进的容错（try-catch 兜底 + 功能降级）；
3. 三方 SDK 隔离：SDK 崩溃往往占了 Top 榜一大截，升级 SDK 视同代码变更，进灰度流程；
4. OOM 专项：图片按需解码、大图下采样、页面退出时释放资源监听——OOM 无法从崩溃堆栈直接归因，必须靠内存水位曲线 + 页面轨迹回放。

「启动路径容错」的一个具体形态——初始化隔离，任何一个三方 SDK 炸了都不影响主流程：

object SafeInitializer {
    fun initAll() {
        // 逐个隔离初始化：单个 SDK 失败只记埋点，不中断启动
        listOf(::initAnalytics, ::initPush, ::initPay).forEach { init ->
            try {
                init()
            } catch (t: Throwable) {
                CrashMonitor.record("init:" + init.javaClass.name, t)
            }
        }
    }
}

一句话总结：崩溃治理不是修 bug 的速度问题，而是口径、归因、分级、灰度四件事是否成为团队默认动作的问题。新崩溃清零 + 灰度自动熔断，坚持两个版本周期就能看到崩溃率结构性下降。