ANR (Application Not Responding)　　

ANR定义：在Android上，假设你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框。这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。用户能够选择“等待”而让程序继续执行。也能够选择“强制关闭”。

所以一个流畅的合理的应用程序中不能出现anr，而让用户每次都要处理这个对话框。因此，在程序里对响应性能的设计非常重要，这样系统不会显示ANR给用户。

默认情况下。在android中Activity的最长运行时间是5秒，BroadcastReceiver的最长运行时间则是10秒。

第一：什么会引发ANR？

在Android里。应用程序的响应性是由Activity Manager和WindowManager系统服务监视的 。当它监測到下面情况中的一个时，Android就会针对特定的应用程序显示ANR：

1.在5秒内没有响应输入的事件（比如。按键按下，屏幕触摸）

2.BroadcastReceiver在10秒内没有运行完成

造成以上两点的原因有非常多。比方在主线程中做了非常耗时的操作，比方说是下载，io异常等。

潜在的耗时操作，比如网络或数据库操作，或者高耗时的计算如改变位图尺寸，应该在子线程里（或者以数据库操作为例，通过异步请求的方式）来完毕。

然而，不是说你的主线程堵塞在那里等待子线程的完毕——也不是调用 Thread.wait()或是Thread.sleep()。

替代的方法是，主线程应该为子线程提供一个Handler，以便完毕时可以提交给主线程。以这样的方式设计你的应用程序。将能保证你的主线程保持对输入的响应性并能避免因为5秒输入事件的超时引发的ANR对话框。

第二：怎样避免ANR？

1、执行在主线程里的不论什么方法都尽可能少做事情。

特别是，Activity应该在它的关键生命周期方法（如onCreate()和onResume()）里尽可能少的去做创建操作。

（能够採用又一次开启子线程的方式。然后使用Handler+Message的方式做一些操作，比方更新主线程中的ui等）

2、应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务（由于 BroadcastReceiver的生命周期短），替代的是，假设响应Intent广播须要运行一个耗时的动作的话，应用程序应该启动一个 Service。（此处须要注意的是能够在广播接受者中启动Service，可是却不能够在Service中启动broadcasereciver,关于原因兴许会有介绍。此处不是本文重点）

3、避免在Intent Receiver里启动一个Activity。由于它会创建一个新的画面，并从当前用户正在执行的程序上抢夺焦点。

假设你的应用程序在响应Intent广 播时须要向用户展示什么。你应该使用Notification Manager来实现。

总结：anr异常也是在程序中自己经常遇到的问题。基本的解决的方法自己最经常使用的就是不要在主线程中做耗时的操作，而应放在子线程中来实现，比方採用Handler+mesage的方式，或者是有时候须要做一些和网络相互交互的耗时操作就採用asyntask异步任务的方式（它的底层事实上Handler+mesage有所差别的是它是线程池）等，在主线程中更新UI。