Android源码探究：深入理解ANR

对于Android开发人员来说，ANR是一个既熟悉又陌生的问题。之所以说熟悉，因为基本每个开发人员都能说出关于ANR的一些概念，但也只是处于似是而非，懵懵懂懂的阶段。而为什么说陌生，则是因为随着Android系统的不断发展，除了主动去尝试不合理的代码，一般工作中很少机会能碰到ANR问题。但即便如此，我们也要试着去研究分析这个影响用户体验的东西。

那我们先从大家都能脱口而出的几点入手：什么是ANR？ANR是Application Not Responding，用中文解释就是应用程序在一段时间内无响应。为什么会有ANR？根本原因是APP的主线程被阻塞了。怎样会导致ANR？触摸事件/广播/ContentProvider/Service等在各自特定时间内无法处理完成事件。怎样定位ANR问题？每次发生ANR，系统都会清空traces文件，重新写入发生ANR的信息，所以我们可以通过跟踪traces文件进行分析。如何避免ANR问题？尽量不要在主线程中进行耗时操作，如网络请求，操作数据库，读写文件等应该采用异步操作。UI线程只做与UI相关的工作。使用Handler来处理UI线程与其他线程的交互等等等等。

好了文章到此结束。什么？有点对不起标题，我也觉得，那就多讲点叭。

绝大多数人对产生ANR的印象只停留在主线程处理耗时任务或者CPU繁忙。事实上，ANR是Android系统的一套完善的消息处理超时监控机制。相比起app崩溃闪退，ANR弹出一个对话框的处理方式更加“温柔”，用户可以选择“等待”或者“强行关闭”，其实也更像是app的慢性自杀OVO

为了符合标题，我们就来深入探究在不同场景下的ANR：

Service

说起Service，很多人都会认为Service处理后台任务，因此可以长时间运行。其实不然，Service是一个应用组件，虽然长时间在后台运行，不需要与用户交互。但是Service还是运行在主线程中的，因此，如果需要执行耗时任务，还应该新开一个线程。

 

本质上，ANR是在主线程中处理耗时操作并且超出了限制时间，因此系统会认为主线程失去了响应其他操作的能力。