Android中的ANR

一. 概念

在Android上，如果你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框，这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。用户可以选择“等待”而让程序继续运行，也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr，而让用户每次都要处理这个对话框。因此，在程序里对响应性能的设计很重要，这样系统不会显示ANR给用户。默认情况下，在android中Activity的最长执行时间是5秒，BroadcastReceiver的最长执行时间则是10秒.

如图:

崩溃和未响应是我们开发过程中经常会碰到，而且是很不希望碰到的问题，像这样： 
（崩溃）

或者是这样？

通常，我们主线程被阻塞的时候会出现未响应的情况，而某些异常出现却为被处理会出现系统的崩溃。

二. 一般何时会出现?

—主线程 (“事件处理线程” / “UI线程”) 在5秒内没有响应输入事件

—BroadcastReceiver 没有在10秒内完成返回

—主线程被IO操作（从4.0之后网络IO不允许在主线程中）阻塞。 
       —主线程中存在耗时的计算 
       —主线程中错误的操作，比如Thread.wait或者Thread.sleep等

系统通常会如何告知用户？

系统就会弹出一个ANR对话框，用户可以自行选择继续等待亦或者是停止当前程序。

三. 如何避免

考虑上面的ANR定义，让我们来研究一下为什么它会在Android应用程序里发生和如何最佳构建应用程序来避免ANR。

 

Android应用程序通常是运行在一个单独的线程（例如，main）里。这意味着你的应用程序所做的事情如果在主线程里占用了太长的时间的话，就会引发ANR对话框，因为你的应用程序并没有给自己机会来处理输入事件或者Intent广播。

 

因此，运行在主线程里的任何方法都尽可能少做事情。特别是，Activity应该在它的关键生命周期方法（如onCreate()和onResume()）里尽可能少的去做创建操作。潜在的耗时操作，例如网络或数据库操作，或者高耗时的计算如改变位图尺寸，应该在子线程里（或者以数据库操作为例，通过异步请求的方式）AsyncTask来完成。然而，不是说你的主线程阻塞在那里等待子线程的完成——也不是调用Thread.wait()或是Thread.sleep()。替代的方法是，主线程应该为子线程提供一个Handler，以便完成时能够提交给主线程。以这种方式设计你的应用程序，将能保证你的主线程保持对输入的响应性并能避免由于5秒输入事件的超时引发的ANR对话框。这种做法应该在其它显示UI的线程里效仿，因为它们都受相同的超时影响。

 

IntentReceiver执行时间的特殊限制意味着它应该做：在后台里做小的、琐碎的工作如保存设定或者注册一个Notification。和在主线程里调用的其它方法一样，应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务（因为BroadcastReceiver的生命周期短），替代的是，如果响应Intent广播需要执行一个耗时的动作的话，应用程序应该启动一个Service。顺便提及一句，你也应该避免在Intent Receiver里启动一个Activity，因为它会创建一个新的画面，并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广播时需要向用户展示什么，你应该使用Notification Manager来实现。

 

一般来说，在应用程序里，100到200ms是用户能感知阻滞的时间阈值。因此，这里有一些额外的技巧来避免ANR，并有助于让你的应用程序看起来有响应性。

 

如果你的应用程序为响应用户输入正在后台工作的话，可以显示工作的进度（ProgressBar和ProgressDialog对这种情况来说很有用）。

特别是游戏，在子线程里做移动的计算。

如果你的应用程序有一个耗时的初始化过程的话，考虑可以显示一个Splash Screen或者快速显示主画面并异步来填充这些信息。在这两种情况下，你都应该显示正在进行的进度，以免用户认为应用程序被冻结了。

总结如下:

—使用AsyncTask处理耗时IO操作。 
      —使用Thread或者HandlerThread时，调用Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)设置优先级，否则仍然会降低程序响应，因为默认Thread的优先级和主线程相同。 
      —使用Handler处理工作线程结果，而不是使用Thread.wait()或者Thread.sleep()来阻塞主线程。 
      —Activity的onCreate和onResume回调中尽量避免耗时的代码 
      —BroadcastReceiver中onReceive代码也要尽量减少耗时，建议使用IntentService处理。

通常100到200毫秒就会让人察觉程序反应慢，为了更加提升响应，可以使用下面的几种方法

—如果程序正在后台处理用户的输入，建议使用让用户得知进度，比如使用ProgressBar控件。 
      —程序启动时可以选择加上欢迎界面，避免让用户察觉卡顿。 
     —使用Systrace和TraceView找出影响响应的问题