跑monkey的anr问题解决心得

相信做Android的朋友们，大多都会面临应用的优化问题，什么内存溢出，anr等等。都是我们需要付出足够的时间去处理的。下面我想分享一下我自己在处理anr时候的心得。首先我想说的是anr在通过log定位问题原因的过程是很简单的：

1.首先通过monkey测试的anr问题，通过monkey工具是可以分析大概结论的，一般像这种格式：09-01 19:59:19.691 499 628 E ActivityManager: ANR in com.xx.app.xx
09-01 19:59:19.691 499 628 E ActivityManager: PID: 8705
09-01 19:59:19.691 499 628 E ActivityManager: Reason: Input dispatching timed out (Waiting because the touched window's input channel is not registered with the input dispatcher. The window may be in the process of being removed.)
09-01 19:59:19.691 499 628 E ActivityManager: Load: 0.0 / 0.0 / 0.0
09-01 19:59:19.691 499 628 E ActivityManager: CPU usage from 0ms to 13695ms later (2021-09-01 19:59:04.212 to 2021-09-01 19:59:17.908):
09-01 19:59:19.691 499 628 E ActivityManager: 61% 2398/com.xx.xx: 38% user + 22% kernel / faults: 2426 minor 29 major
09-01 19:59:19.691 499 628 E ActivityManager: 24% 66/kswapd0: 0% user + 24% kernel
09-01 19:59:19.691 499 628 E ActivityManager: 19% 499/system_server: 4.2% user + 15% kernel / faults: 13875 minor 126 major
09-01 19:59:19.691 499 628 E ActivityManager: 18% 1443/com.xx.xx: 15% user + 3.1% kernel / faults: 4951 minor 13 major
09-01 19:59:19.691 499 628 E ActivityManager: 18% 2251/com.xx.xx: 3.6% user + 14% kernel / faults: 7026 minor 242 major
09-01 19:59:19.691 499 628 E ActivityManager: 11% 465/surfaceflinger: 2.2% user + 9% kernel / faults: 825 minor 5 major

然后通过log可以确认基本信息：anr类型，anr时间，pid等等，实际这些信息是为了需要查看trace文件而定位的一些属性。

其实以上log在我看来有两句话是我觉得最需要的：

（1）09-01 19:59:19.691 499 628 E ActivityManager: ANR in com.xx.app.xx

（2）09-01 19:59:19.691 499 628 E ActivityManager: Load: 0.0 / 0.0 / 0.0

第一行是看anr的包名，也就是哪个应用出现的anr，再一个呢要看anr的时间点，第二行是看是不是cpu过载而导致的，如果cpu是过载的基本可以断定是cpu问题，跟模块关系就不大了。但是如果细心的人，或者说负责的人一般不会到此就结束了。因为一般monkey测试anr不止会出现一次（当然出现几次anr在结论中也能看到）。这log不一定是所有anr的问题原因。所以这个时候我们就需要在茫茫多的monkey  log中去寻找了。

 我们看到：09-01 19:59:19.691 这个时间出现的anr，有好多文章描述在这个时间点基础上一般往前5秒或者10秒（我按照这种方法查，没有查到）。其实在我看来也不是很准确的。我的经验告诉我，需要围绕这个时间点前后10秒的log都需要看。当然如果是广播，服务等发生的anr时间点还要延长。

打开log文件后就直接找anr问题的包名就可以。因为之前有的文章会说查找anr in （我在log文件，和trace文件中均没有查到）等等。我还是觉得包名最容易找，也不容易落下。然后通过文件就能定位anr发生在源码中的具体位置了。

所以最后总结一下就是先看：09-01 19:59:19.691 499 628 E ActivityManager: Load: 0.0 / 0.0 / 0.0

判断是不是cpu问题。然后再找log trace等文件定位。以上就是查找anr问题原因的步骤，其实很简单。当然这只是解决anr问题的开始。真正解决问题，优化代码才是难点。