分析ANR之iowait偏高

解决了一个anr的bug，在此记录下；

我们首先看log 知道是哪个pid 发生的anr，再看trace文件，找到对应的，如下图；

从图我标出3块红色的地方：

1.第一个红色，看似在等待信号量，其他不懂；

2.第二个红色，应该是打开了strickmode 模式下进行的操作；

3.第三个红色才是自己的代码调用，其实只是用log4j 打印了一条日志，怎么会anr呢？还有，3和2 应该没有什么关系，因为log4j里面没有android 这块的调用；2 应该是系统自动添加打印的；

这还不够，然后仔细找log文件，发生ANR时，mmcqd 占用cpu较多，查了下，这个是和sd卡读取文件相关的进程；看来和日志写文件引发ANR符合；

再接着往下看，如下图红色，很关键，iowait 占用有点偏高了，log4j 日志写文件正是io操作，也是耗时的操作；

暴力测试来确认：

1. 打日志操作，循环执行1000次，不anr；1w次，确实发生了anr；

解决方案：

log4j 日志写文件不要放到主线程调用，另起子线程来执行；

再测试1w次，不会anr，而且打印日志线程在非UI线程完成；