崩溃现场
1. 崩溃信息
- 进程名、线程名
- 崩溃类型和堆栈信息
2. 系统信息
- Logcat
- 机型、系统、厂商、CPU、ABI、Linux 版本等
- 设备状态：是否 root、是否模拟器、是否有 Xposed 或多开软件造成
3. 内存信息
- 系统剩余内存 通过读取 /proc/memoinfo 获得，MemTotal 表示除了系统本身需要留下可用的总内存，MemFree 表示系统尚未使用的内存
- 应用使用内存 包括 Java 内存、，RSS 和 PSS 可以通过 proc/self/smaps 获取
- 虚拟内存
4. 资源信息
- 文件句柄fd
- 线程数 线程数量超过400个就比较危险
- JNI
5. 应用信息
- 崩溃场景（哪个界面，具体业务）
- 关键操作路径
- 其它自定义信息（播放的音乐、打开的网站、运行时间、是否打了补丁等）
- 磁盘空间、电量、网络使用等
崩溃分析
第一步，确定重点
1. 确认严重程度
2. 崩溃基本信息
- Java 崩溃，查看错误栈，OOM查看日志中的“内存信息”和“资源信息”
- Native 崩溃，观察 singal、code、fault addr 等内容，以及崩溃时的 Java 堆栈
- ANR， 先查看主线程堆栈，是否因为锁等待导致，接着看 ANR 日志确定是 IO 问题、CPU 竞争问题还是大量 GC 导致卡死。
3.Logcat
当从一条崩溃日志中无法看出问题的原因，或者得不到有用信息时，不要放弃，建议查看相同崩溃点下的更多崩溃日志。
4.各个资源情况
内存与线程相关的信息都需要特别注意
第二步，查找共性
机型、系统、ROM、厂商、ABI等等，应用信息也可以作为聚合维度，如打开的链接、播放的视频、国家、地区等
第三步，尝试复现
疑难问题：系统崩溃
1. 查找可能的原因
通过共性归类、操作路径和日志等查找怀疑点
2. 尝试规避
3. Hook 解决
补充
获取 Logcat 的方法
- 通过 logcat 命令获取
- hook liblog.so 实现
- 自定义获取代码
获取 Java 堆栈
- Thread.getAllStackTraces();
- hook libart.so
课后作业
通过 hook 解决 TimeoutException
问题背景可以参考
- TimeoutException 是由系统的 FinalizerWatchdogDaemon 抛出来的，原因是有对象的 finalize 方法的运行时间超过了 10 秒（由 Rom 决定）
- 调用 Stop 方法在 Android 6.0 之前存在线程安全问题，是由于调用 thread.interrupt 方法没有加锁
- 最终的 hook 方案是把 FinalizerWatchdogDaemon 的 thread 设置为 null，这样 isRunning() 方法就会返回 false，而 runInternal 方法中是一个依赖 isRunning 方法的死循环，所以就 stop 掉了。