1. Android稳定性概述与重要指标
1.1 到底什么是“稳定性”？
做了这么多年Android，经常有人问我这个问题。
说白了，就是App别动不动就崩溃、别卡住不动、别黑屏、别莫名其妙退到后台。
用户打开你的应用，想下单就下单，想刷视频就刷视频，全程不用焦虑。这就是稳定性。
我个人的理解：稳定性不是功能，而是所有功能的载体。UI做得再好看，一打开就闪退，等于零。
核心定义： Android App稳定性，是指App在多机型、多系统版本、多网络环境下，持续提供正确、流畅、无异常服务的能力。
刚入行那会儿，我写过一个支付模块。有个边界的空指针没处理，结果线上用户付了款，积分没到账。用户投诉如潮水般涌来，我们紧急排查了一整天才定位到问题。那个月的绩效，惨不忍睹。
从那以后，我对稳定性有了执念。
其实稳定性不止是崩溃。你想想看，用户打开一个页面，等了三秒才加载出来，这也算稳定性问题。更常见的，比如数据同步异常、状态错乱、界面卡死，这些都属于稳定性的范畴。
嗯，这里要分清楚：稳定性 ≠ 无崩溃。无崩溃只是及格线。
1.2 核心指标全景
既然稳定性这么重要，那怎么衡量它？
不能靠感觉，得靠数据说话。
在业界，我们通常重点关注以下几个核心指标。它们就像汽车的仪表盘，每一项都反映了系统的健康状况。
| 指标名称 | 定义 | 计算公式 | 参考阈值 |
|---|---|---|---|
| 崩溃率 (Crash Rate) | App因未捕获异常而退出的比例 | 崩溃次数 / 启动次数 × 100% | < 0.3% |
| ANR率 (ANR Rate) | 主线程无响应超过5秒的占比 | ANR次数 / 活跃用户数 × 100% | < 0.05% |
| 卡顿率 (Jank Rate) | 单帧渲染时间超过16.67ms的占比 | 卡顿帧数 / 总渲染帧数 × 100% | < 5% |
| 重启率 (Reboot Rate) | 进程被系统或用户异常杀死的占比 | 非正常退出次数 / 启动次数 × 100% | < 1% |
这四个指标是互相关联的。ANR多了，用户可能会主动重启；重启多了，崩溃率也可能异常升高。
我习惯每天早上到公司的第一件事，就是打开稳定性看板，观察这几个指标的波动。一旦出现异常抖动，立刻拉群排查。
1.3 稳定性对用户体验的影响
指标是冷冰冰的数字，但用户是活生生的人。
一次偶然的崩溃，用户可能选择重试。但如果让他遇到了下面的情况，后果就很严重了。
- 下单支付时崩溃： 用户不知道钱扣了没有，极度缺乏安全感。大概率会卸载并给差评。
- 滑动列表时掉帧卡顿： 用户会觉得App很“重”，体验廉价。
- 点击按钮无响应： 用户会怀疑手机坏了，或者App是“假”的。
我记得有次线上发布了一个版本，引入了一个隐蔽的死锁。用户操作到个人中心时，线程池被占满，整个App卡死。那天下午，差评量是平时的10倍，日活掉了5%。
那是血淋淋的教训。
从那以后，我定了个规矩：稳定性问题优先级永远排第一。任何可能影响稳定性的代码，必须经过严格的Review和测试才能合入。
我的经验： 用户体验是个漏斗。最底层是稳定，中间是流畅，上面是功能。底层不稳，上面再好也没用。
另外，稳定性还直接影响商业指标。一旦App频繁崩溃，用户会毫不犹豫地转向竞品。
1.4 如何衡量与观测这些指标
光知道指标还不够，你得有办法拿到它们。
目前业界主流的方式有这么几种：
- 本地开发日志（Logcat）： 用于开发阶段自测，线上基本不可用。
- 第三方平台（Bugly、Firebase Crashlytics）： 接入简单，适合中小团队快速建立监控体系。
- 自研APM（应用性能管理平台）： 大厂标配。可以做到全量采集、精准告警、链路追踪。
我个人习惯采用自研APM + Bugly兜底的策略。自研负责核心链路的全量监控，Bugly作为补充，兜底采集那些自研遗漏的异常。
要测量崩溃率，最基础的做法是注册一个全局异常处理器。
// 我个人喜欢在Application中这样处理
public class MyApp extends Application {
@Override
public void onCreate() {
super.onCreate();
Thread.UncaughtExceptionHandler previousHandler =
Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
// 收集堆栈并上报到我们的APM平台
ApmManager.reportCrash(throwable);
// 注意：不要吃掉异常，让系统继续处理
if (previousHandler != null) {
previousHandler.uncaughtException(thread, throwable);
}
});
}
}避坑指南： 我曾经为了“降低”崩溃率，要求开发在所有地方都包上try-catch。结果呢？崩溃率是降了，但业务逻辑全乱了。用户下单一直失败，却没有任何异常上报，因为我们把错误都吞掉了。千万不要掩盖问题，要暴露问题。
嗯，这里要特别注意：埋点不是越多越好。全量埋点会导致性能损耗，也会增加包体积。一定要选关键路径来埋。我个人建议先覆盖启动、登录、支付、核心页面跳转这些场景。
1.5 本章小结
这一章我们聊了稳定性的本质，以及为什么它如此重要。
记住四个核心指标：崩溃率、ANR率、卡顿率、重启率。它们就像四根柱子，支撑着用户体验这座大厦。
衡量和观测，是稳定性的第一步。别想着一口吃成胖子。先把核心路径的监控建起来，后面再慢慢优化细节。