ANR log分析 - shu1123/log- GitHub Wiki

死锁ANR； ANR----trace.txt文件的分析

ANR的分析首先要从trace.txt入手，首先明确几点：

1 产生ANR的进程，很显然是FM模块（第一行） ----- pid 12377 at 2017-11-29 08:00:14 ----- Cmd line: com.facebook.katana

2 看栈信息，最重要的第一个栈为第一现场，运气很好，我们看到了“waiting to lock ”这是一类常见的问题，也是比较好分析的一类，说明系统当时有死锁的情况。顺藤摸瓜，发现是tid=17出的问题，立即全局搜索，看一下是什么问题

ANR----logcat分析

Logcat和kmsg的分析都是结合ANR出现的时间点，对当时的场景进行分析，从而了解当时系统都在做什么操作？为什么会出现ANR？

1 找到问题时间点

anr出现的时间点在trace.txt中at 2014-08-25 04:36:17 ，那就去找这个时间的logcat往前看一点，ANR的产生是一般是超时引起，之前20S的log都有可能找到线索

2 进行场景分析

因为在trace中我们怀疑是FM的问题，可以搜索相关的关键字，发现问题。

这个过程是比较耗时的，分为3个过程

第一，大体浏览一下，Log中有没有比较明显的error

第二，搜索音频模块，audio_hw_primary, mediaplayer,auidoplayer,audioflinger,audiotrack,audiosink等，看有没有异常

第三，根据ANR中出现问题的模块搜索相关信息