系统重启（System Reboot）——重启类型与重启率统计
系统重启这个指标，说白了就是看你的手机有没有莫名其妙地自己重启。它跟ANR、Crash不一样，重启一旦发生，用户的所有现场全丢，体验伤害极大。我早年在做某个项目时，曾经因为一个内核驱动的小bug，导致设备每天半夜自动重启一次，线上数据一查，重启率直接翻了三倍。
嗯，指标本身并不复杂，但你要把“什么算一次重启”、“重启是意外还是正常”定义清楚，才能真正指导稳定性改进。
重启类型：正常 vs 意外
不是所有重启都是坏事。我们需要先把它分成两大类：
| 类型 | 定义 | 典型场景 |
|---|---|---|
| 正常重启 | 用户或系统主动发起的、预期内的重启 | 用户长按电源选择重启、OTA升级后自动重启、adb reboot |
| 意外重启 | 非用户意愿、非系统正常流程的突然重启 | 内核panic、watchdog超时、系统服务死锁导致重启、温度过高触发硬件保护重启 |
注意： OTA升级后的重启虽然用户可能没主动点，但属于系统设计的正常流程，应算作正常重启。我见过有人误把OTA重启也算成意外，导致重启率虚高，浪费了很多排查时间。
如何区分？我在项目中习惯通过以下几个来源做判断：
- 内核日志：
dmesg中搜索Kernel panic、Watchdog bite、oops等关键词。 - 重启原因节点：读
/sys/fs/pstore/console-ramoops或/proc/last_kmsg，里面有上次重启的发起者信息。 - 系统属性：
sys.boot.reason在 Android 8.0+ 上会记录重启原因，如kernel_panic、reboot、watchdog、cold等。
重启率统计方法
重启率的核心计算公式很简单：
重启率 = (意外重启次数) / (活跃设备数 × 统计天数) × 100%但分母和分子的取法有不少门道。我建议按以下步骤做：
- 确定统计周期：通常按「日」计算，然后聚合为周/月。例如每天凌晨统计过去24小时的数据。
- 分母：活跃设备数：只计入当天有至少一次网络连通的设备。完全离线超过24小时的设备不参与计算，否则会稀释分母，重启率看着很低但实际上并没有修复。
- 分子：意外重启次数：每个设备每天只计一次意外重启——如果设备在24小时内反复重启多次，只算一次。为什么？因为一次内核崩溃后系统反复重试，如果你计多次，一个坏设备就能拉高整个大盘。我这里曾经踩过坑，计了多次导致重启率飙升，后来才发现是同一个设备在不停重启。
最佳实践： 采用「设备维度+天维度」的计数方式：
若某设备当天至少发生一次意外重启，则该设备当天计为“1次重启事件”，
最终 重启率 = (重启设备天数) / (总活跃设备天数) × 100%
实例：从日志提取意外重启
假设我们在服务器端收集了设备上报的 boot_reason 字段，可以用一个简单的脚本做分类统计：
#!/bin/bash
# 从日志文件提取意外重启设备
awk -F',' '{
reason = $3
day = substr($1,1,10)
device = $2
if(reason == "kernel_panic" || reason == "watchdog" || reason == "hardware_reset") {
print device, day
}
}' boot_log.txt | sort -u | wc -l注意这里用了 sort -u 去重，确保同一设备同一天只计一次。我曾经就吃过这个亏——我以为每天只上报一次，结果有些设备上报了两次，导致统计翻倍。
常见陷阱与避坑指南
避坑1： 不要漏掉「正常重启」中隐藏的意外。比如用户点重启，但结果是内核panic触发的——这时用户以为是正常操作，实际在系统日志里能看到真正的重启原因是 reboot,panic 而不是 reboot,user。要结合日志判断本质原因。
避坑2： 电池耗尽关机后再次开机，算不算重启？我个人认为不算——电池耗尽属于低电关机的后续行为，属于正常开机，不应该计入重启率。但有些厂商把这种也算成冷启动，导致指标波动很大。建议在统计前过滤掉 power_key 或 low_battery 作为原因的启动。
避坑3： 重启率的分母不要用「出货总量」或「激活总量」，要用「每日活跃设备数」。否则如果产品卖了一百万台，但每天只有十万台在线，你的重启率就会偏低，掩盖真实问题。
知识结构图
下面这张图总结了系统重启指标的整体分类和统计流程，方便你理解各个要素之间的关系。
指标汇总表
| 指标项 | 建议值/标准 | 说明 |
|---|---|---|
| 日重启率（意外） | ≤ 0.05% | 即每万台设备每天不超过5台意外重启 |
| 周重启率（意外） | ≤ 0.3% | 累积7天，允许波动 |
| 正常重启占比 | 无需达标，仅用作排除 | 辅助判断是否有异常重启混入正常类别 |
写到最后我想说一句：重启率这东西，看起来就一个数字，但把类型分清楚、去重逻辑写对、分母选准，才不至于被假数据迷惑。我见过不少团队因为统计口径没对齐，两个版本明明一样的问题，一个显示0.02%，一个显示0.2%，最后扯皮浪费一周。所以从一开始就把定义和计算方式固化下来，你后面会省很多心。