1. 稳定性概述：什么是Android系统稳定性，为什么重要，常见的稳定性问题分类
1.1 到底什么是Android系统稳定性？
这个问题，我入行头三年其实也没完全想明白。
很多人觉得，手机不卡顿、不死机，就是稳定。嗯，这话对了一半。真正的系统稳定性，说白了就是系统在长时间、高负载、各种异常场景下，依然能保持可预期的、正确的行为。注意我用了「可预期」这个词——用户按了返回键，APP就该退回去；来电了，界面就该弹出来。如果这些基本行为都变得随机，那稳定性就无从谈起。
我在项目中遇到过这样一个案例：某款手机在实验室测了三个月，所有指标都过了。结果上市后，用户在地铁里刷抖音，手机突然黑屏重启。为什么？因为地铁里信号切换频繁，触发了底层modem的一个竞态条件。你看，实验室测不出来，不代表它稳定。
所以我的定义很简单：稳定性 = 系统在真实世界中的抗造能力。
1.2 为什么稳定性这么重要？
你想想看，一个APP闪退，用户顶多骂这个APP的开发者。但如果是系统死机、重启呢？用户会直接骂手机厂商。这就是稳定性的「一票否决权」。
我整理过一份数据，大家可以看看：
| 稳定性问题 | 用户容忍度 | 典型后果 |
|---|---|---|
| APP闪退 | 偶尔可接受 | 卸载APP |
| 系统ANR | 每周1-2次 | 吐槽、差评 |
| 系统死机 | 每月1次 | 退货、换机 |
| 自动重启 | 零容忍 | 品牌信任崩塌 |
你看，越往下的问题，用户容忍度越低。我曾经处理过一个线上事故：某次OTA升级后，0.5%的用户出现反复重启。就这0.5%，直接导致该机型的NPS（净推荐值）从68跌到了41。所以别小看稳定性，它直接关系到产品的生死。
核心观点：稳定性不是「锦上添花」，而是「雪中送炭」。没有稳定性，其他一切性能、功能都是空中楼阁。
1.3 常见的稳定性问题分类
做稳定性这么多年，我把问题归为四大类。每一类我都踩过坑，今天一次性说清楚。
1.3.1 ANR（Application Not Responding）
ANR，说白了就是「应用没反应」。系统给APP发了个消息，APP超过5秒（输入事件）或10秒（广播）没处理，系统就认为它挂了。
为什么会这样？我总结下来就三个原因：
- 主线程干了重活——比如在主线程做网络请求、数据库读写。这是最常见的坑。
- 锁竞争导致死锁——两个线程互相等对方释放锁，主线程被卡住。
- Binder调用超时——APP调用系统服务，系统服务响应慢了，APP也跟着卡。
我记得有一次，某视频APP在播放时频繁ANR。查了半天，发现是播放器在UI线程里做了视频解码的初始化。嗯，这其实是个很低级的错误，但就是发生了。
避坑指南：我曾经在排查ANR时发现，很多开发者不知道「SharedPreferences的commit()方法会阻塞主线程」。如果你还在用commit()，赶紧换成apply()。
1.3.2 Crash（崩溃）
Crash就是APP或系统进程突然挂了。Java层的Crash会抛异常，Native层的Crash直接段错误。
常见的Crash类型：
- NullPointerException——空指针，Java界的头号杀手
- OutOfMemoryError——内存撑爆了，尤其是加载大图的时候
- UnsatisfiedLinkError——so库没找到或者版本不匹配
- Signal 11 (SIGSEGV)——Native层访问了非法内存地址
我处理过最诡异的一个Crash：某款手机在打开相机时必崩。最后定位到是相机HAL层的一个指针在特定分辨率下被覆写了。这种问题，光看logcat根本看不出来，得配合 tombstone 文件一起分析。
1.3.3 死机（System Hang）
死机比ANR更严重。ANR至少系统还在运行，死机是整个系统像被按了暂停键——屏幕不动，按键没反应，连log都打不出来。
死机的本质，通常是内核态出了问题：
- 内核死锁——两个内核线程互相锁死，CPU空转
- 中断风暴——某个外设疯狂触发中断，CPU被中断处理占满
- 内存耗尽——系统连分配一个page都做不到，直接卡死
我印象最深的一次死机问题：用户插上某品牌耳机后，手机立刻死机。查了三天，发现是耳机插拔检测的中断处理函数里，调用了会睡眠的函数。中断上下文是不能睡眠的，这一睡，整个系统就睡过去了。
警告：死机问题最难复现，也最难定位。我的建议是：在开发阶段就打开「内核死锁检测」和「硬锁超时检测」开关。别等到量产了再查，那时候成本高10倍不止。
1.3.4 重启（Unexpected Reboot）
重启是稳定性问题的「终极大招」。用户最不能接受的就是手机自己重启——正在打游戏、正在付款、正在拍照，突然就黑屏了。
重启的原因通常分两类：
- 内核Panic——内核遇到了无法恢复的错误，主动触发重启
- 看门狗超时——硬件看门狗在规定时间内没被喂狗，强制重启
我处理过一个经典案例：某款手机在低温环境下（-10℃）频繁重启。原因是电池在低温下内阻变大，瞬间电压跌落，触发了PMIC的欠压保护，直接拉低了复位引脚。这种问题，软件层面几乎无解，只能改硬件设计。
所以你看，稳定性问题往往不是纯软件问题，它涉及硬件、驱动、内核、框架、应用五个层面。这也是为什么我常说：做稳定性，要有全栈思维。
1.4 小结
这一章我们聊了稳定性的定义、重要性，以及四大类常见问题。说白了，稳定性就是「系统在真实世界中的抗造能力」。ANR、Crash、死机、重启，这四兄弟一个比一个难缠。
下一章，我会详细讲稳定性问题的根因分析方法论。到时候我会分享一套我自己总结的「五步排查法」，保证你听完就能用。
嗯，今天就先到这儿。记住一句话：稳定性不是测出来的，是设计出来的。