恼人的ANR

早先年用Android的时候，就连很多知名的app也总是莫名其妙崩溃，好像手机快的时候会崩溃，手机卡的时候app会卡死。卡死的时候会弹出来一个框，询问是要结束app还是继续等待。这就是ANR(Application Not Responding)无疑了。

ANR一般有三种类型：

1. KeyDispatchTimeout(5 seconds) – 按键或触摸事件在5秒内无响应

2. BroadcastTimeout(10 seconds) – BroadcastReceiver在10秒内无法处理完成

3. ServiceTimeout(20 seconds) – Service在20秒内无法处理完成

第一种类型很常见，就是你在UI线程里做了很多耗时的工作，导致UI阻塞住超过5秒，这个时候用户一定很气恼准备砸手机卖肾了，Android系统也会认为你的app做得实在是太烂了，赶紧提示用户把app结束掉，别让用户以为是安卓太烂了的缘故。

第二种也是一样，你刚刚接收到一个低电量的广播，要么赶紧弹一个框出来让用户注意电量(前台)，要么赶紧开一个Service默默地杀掉耗电的app(后台)，但是你若是在BroadcastReceiver里磨磨蹭蹭犹豫不决，Android系统也会认为你这个app简直是天秤座附体，赶紧回家纠结吧，别占着广播台了。

第三种比较少见，但也会出现，比如处理一些数据的时候算法不够优化，写大量文件啊，等等。

处理办法

• 1和3的处理办法就是：开线程、开线程、开线程，然后用上一课我们学到的Handler去异步处理UI。
• 2的话和上文提到的一样，要么转换成1的问题或者3的问题，不要停留在Broadcast里。

防患于未然

耗时的操作主要是I/O操作：

• 网络请求

  当你准备进行网络操作的时候，想都不要想，一定要开线程。在Android2.x的时候还允许你在主线程里进行网络请求(只要不超过ANR的5秒限制)，现在的Android4.x就不要想了，连ANR的机会都不会给你，直接报异常退出。

• 文件读写

  当你用java的File操作的时候当然会警觉，会想到要开线程。但是有些坑你未必就能注意到：

1. 数据库操作，尤其是可能会有大量批量的数据库操作的时候。

   （我表示曾经被坑过，即便你是开了线程，在大量数据库操作时的超级慢也会让人受不了，你需要搜索一下“SQLite的事务处理”，症结在这儿。

   ps：不只是SQLite，数据库在批量操作的时候都需要“事务处理” 。）

2. 注意SharedPreferences，由于SharedPreferences封装的很好，所以很多时候往往会忘记这东西本质上是在读写xml文件啊！

   虽然一般用这种方式存储是很少的数据量，但依然不可小觑。还有个小细节也要改变一下以往的习惯：

1
2
3
4
5

SharedPreferences sp=context.getSharedPreferences("xxx",context.MODE_PRIVATE);
SharedPreferences.Editor editor=sp.edit();
editor.putInt("num",1);
// editor.commit(); 没错，旧方法是使用commit()，它是直接操作文件的
editor.apply();    //推荐使用新方法apply()，它是异步的

• 计算密集型操作

  没啥说的，异步，然后优化算法吧。如果计算结果不是急需要的话可以托管给服务端来处理嘛！

一些参考数据增加你的经验

• 100到200ms是用户能感知阻滞的时间阈值

• /data/anr/traces.txt里记录了你的应用程式发生过的ANR的一些信息

  有兴趣可以动手试试，traces.txt能提供很多很多有用的数据

1
2
3
4
5

$chmod 777 /data/anr
$rm /data/anr/traces.txt
$ps
$kill -3PID
adbpull data/anr/traces.txt ./mytraces.txt

用这些命令可以有助于你清晰地查看traces.txt

参考资料：http://mzh3344258.blog.51cto.com/1823534/804237

#总结

总而言之，ANR的存在就是在不断提醒你，优化，优化，再优化。优化效率，优化视觉，优化体验。