4. 稳定性度量指标
在智能座舱Android稳定性工程中，度量指标是判断系统是否“稳”的唯一客观依据。没有指标，稳定性治理就会退化为“凭感觉修Bug”；有了指标，才能把模糊的“偶发卡死”转化为可追踪、可对比、可验收的工程数据。本章围绕崩溃率、ANR率、重启率、可用性、MTBF、MTTR六个核心指标，讲清定义、采集口径与落地方法。
一、核心指标定义与计算口径
六个指标可分为三类：故障频度类（崩溃率、ANR率、重启率）、可用性类（可用性）、时间类（MTBF、MTTR）。它们共同构成稳定性度量的“频度—时长—可用”三角。
| 指标 | 定义 | 计算公式 | 典型采集来源 |
|---|---|---|---|
| 崩溃率 | 单位使用量内发生崩溃的次数 | 崩溃次数 / 使用时长或启动次数 | Crash日志、tombstone、Bugly/Firebase |
| ANR率 | 单位使用量内发生ANR的次数 | ANR次数 / 使用时长或启动次数 | /data/anr/traces.txt、DropBox |
| 重启率 | 单位使用量内系统或应用重启次数 | 重启次数 / 运行时长 | bootlog、sys.boot_completed、Watchdog |
| 可用性 | 系统可正常服务的时间占比 | 可用时长 / 总时长 × 100% | 心跳探针、健康检查 |
| MTBF | 平均无故障工作时间 | 总运行时长 / 故障次数 | 故障事件表 + 运行时长 |
| MTTR | 平均故障恢复时间 | 总恢复耗时 / 故障次数 | 故障工单、恢复时间戳 |
二、指标采集方法与数据链路
指标不是算出来的，而是采出来的。智能座舱的采集链路通常分为端侧埋点、日志落盘、上报聚合、看板呈现四层。下图展示了六个指标从故障发生到指标呈现的完整数据流。
采集实现上，崩溃可通过Thread.setDefaultUncaughtExceptionHandler捕获Java异常，Native崩溃依赖tombstone；ANR由系统在/data/anr/traces.txt写入堆栈，也可通过ActivityManager监听；重启则通过sys.boot_completed属性变化或BootCounter计数。以下是一个简化的崩溃埋点示例：
public class CrashCollector implements Thread.UncaughtExceptionHandler {
@Override
public void uncaughtException(Thread t, Throwable e) {
// 1. 记录时间戳、进程名、版本号
CrashEvent event = new CrashEvent(
System.currentTimeMillis(),
Process.myPid(),
BuildConfig.VERSION_NAME,
Log.getStackTraceString(e));
// 2. 落盘到本地队列，避免上报失败丢失
CrashStore.enqueue(event);
// 3. 交给默认处理器，保留系统行为
defaultHandler.uncaughtException(t, e);
}
}三、典型场景：从指标异常到根因定位
某座舱项目在OTA后崩溃率从0.3次/千小时升至1.8次/千小时，ANR率同步上升。团队按指标链路排查：先看崩溃率的分进程分布，发现集中在com.android.systemui；再看ANR traces，主线程阻塞在Binder调用；最终定位为新增的车辆信号订阅接口在熄火场景下未释放，导致Binder线程池耗尽。修复后崩溃率回落至0.25，MTTR从平均45分钟降至12分钟。
这个案例说明：指标异常是入口，不是结论。崩溃率告诉你“变差了”，ANR traces告诉你“卡在哪”，MTBF和MTTR告诉你“影响多大、恢复多快”。三者结合才能形成闭环。
四、指标目标设定与复盘要点
指标需要目标值才有治理方向。建议按阶段设定：
- 崩溃率：量产阶段目标 ≤ 0.5次/千小时，开发阶段可放宽至2次/千小时用于暴露问题。
- ANR率：量产目标 ≤ 0.3次/千小时，重点监控主线程Binder与IO阻塞。
- 重启率：系统级重启 ≤ 0.1次/千小时，应用级重启单独统计。
- 可用性：座舱核心服务可用性 ≥ 99.9%，即每月不可用不超过43分钟。
- MTBF：目标 ≥ 500小时，反映系统长期稳定能力。
- MTTR：目标 ≤ 30分钟，含故障发现、定位、恢复全流程。
复盘时需注意三点：一是口径一致性，跨版本对比前确认统计窗口和分母相同；二是样本量，低样本下的指标波动大，需结合置信区间判断；三是归因准确性，重启率上升可能源于Watchdog误杀而非真实故障，需结合bootlog区分“计划内重启”与“异常重启”。