推荐文章：Android 开发高手课
线上稳定性监控，主要分为几个步骤。
采集层（客户端）
上报层（客户端）
处理层（服务端）
展示层（前端）
报警层（短信报警，责任人分发等）
稳定性保障的几个阶段：开发阶段 => 测试阶段 => 合码阶段 => 发布阶段 => 运维阶段
线上Crash监控
监控维度
Crash率（UV/PV）
用户使用时长（启动就Crash的比较严重）
Crash发生的时机（前台还是后台，后台可能用户是无感知的）
Carsh是否是新增的Crash
Crash上报的信息
- 堆栈、设备、OS版本、进程、线程名、Logcat
- 前后台、使用时长、App版本、小版本、渠道
- CPU架构、内存信息、线程数、资源包信息、用户行为日志
- Crash现场信息
- Crash Top机型、OS版本、分布版本、区域
Java Crash信息采集
Thread.setDefaultUncaughtExceptionHandler()；
这个钩子是针对单个进程而言的，在多进程的APP中，监控哪个进程，就需要在哪个进程中设置一遍ExceptionHandler。
获取主线程的堆栈信息：
Looper.getMainLooper().getThread().getStackTrace();
获取当前线程的堆栈信息：
Thread.currentThread().getStackTrace();
获取全部线程的堆栈信息：
Thread.getAllStackTraces();
建议直接使用三方库，bugly去做线上异常的收集。
Native Crash信息采集
用第三方库吧。
自己采集大致方向是监听一些信号量。
线上ANR监控
线上监控
使用FileObserver监听 /data/anr/traces.txt的变化
高版本ROM需要root权限。
利用Handler机制，监控消息队列的运行时间
只能说明APP发生了UI阻塞，需要进行二次校验。
校验的方式就是等待手机系统出现发生了Error的进程，并且Error类型是NOT_RESPONDING（值为2）。
在每次出现ANR弹框前，Native层都会发出signal为SIGNAL_QUIT（值为3）的信号事件，也可以监听此信号。
发生ANR的原因
Activity onCreate方法或Input事件超过5s没有完成；
BroadcastReceiver前台10s，后台60s；
ContentProvider 在publish过超时10s；
Service前台20s，后台200s。
主线程有耗时操作
复杂布局
IO操作
被子线程同步锁block
被Binder对端block
Binder被占满导致主线程无法和SystemServer通信
得不到系统资源（CPU/RAM/IO）
线上OOM监控
线下可以基于LeakCanary进行内存泄漏分析。
线上主要通过dump HPROF文件来处理，需要注意的是，dump文件本身是一个耗时，耗性能的事情，所以需要注意时机。
抖音 Android 性能优化系列：Java 内存优化篇
Probe：Android线上OOM问题定位组件
快手开源自研 OOM 解决方案 KOOM
西瓜视频稳定性治理体系建设一：Tailor 原理及实践
线上卡顿监控
常见问题
- 你们APP的Crash率是多少，线上的稳定性保障是怎么做的？
- 除了代码的稳定性，业务的稳定性是怎么保障的？
- 线上出现稳定性问题后怎么处理？
- 你都参与过那些稳定性优化？
