关于ANR超时

Android最佳实践之响应灵敏性

可能会存在这样的情况，你写的代码通过了世界上所有的性能测试，但当用户尝试使用你的应用程序时，仍然让用户感到不爽。应用程序响应不够灵敏的地方包括——反映迟钝，挂起或冻结很长时间，或者需要花费很长的时间来处理输入。

在Android上，如果你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框，这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。用户可以选择让程序继续运行，但是，他们在使用你的应用程序时，并不希望每次都要处理这个对话框。因此，在程序里对响应性能的设计很重要，这样，系统不会显示ANR给用户。

一般说来，如果应用程序不能响应用户输入的话，系统会显示一个ANR。例如，一个应用程序阻塞在一些I/O操作上（通常是网络访问），这时，应用程序的主线程就不能再处理用户的输入事件。经过一定的时间后，系统认为应用程序已经挂起，并显示ANR来让用户选择杀死应用程序。

相似地，如果你的应用程序花费太多的时间来构建详细的内存结构，或者也许是在游戏里花费太多时间来计算下一步移动，这时，系统会认为你的应用程序已经挂起。因此，确保这些计算是高效的往往很重要，但即使是最高效的代码仍然需要花费时间来运行。

在这两种情况下，解决的方法通常是创建一个子线程，然后在线程里做你的大部分工作。这能让主线程（驱动UI事件循环）保持运行，并阻止系统认为你的代码已经冻结。因为这些线程通常是在类级别上完成的，因此，你可以认为响应性能问题是一个类的问题。（与基本性能相比而言，基本性能问题认为是方法级别的问题）

这篇文章将讨论Android系统如何判断一个应用程序处于无响应状态，并为保证应用程序的响应性提供向导。

这篇文章囊括这些主题：

• 什么引发了ANR？
• 如何避免ANR？
• 增强响应灵敏性
  

1）什么引发了ANR？

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

• 在5秒内没有响应输入的事件（例如，按键按下，屏幕触摸）
• BroadcastReceiver在10秒内没有执行完毕
  

一个ANR对话框显示给用户

2）如何避免ANR？

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

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

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

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

3）增强响应灵敏性

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

• 如果你的应用程序为响应用户输入正在后台工作的话，可以显示工作的进度（ProgressBar和ProgressDialog对这种情况来说很有用）。
• 特别是游戏，在子线程里做移动的计算。
• 如果你的应用程序有一个耗时的初始化过程的话，考虑可以显示一个Splash Screen或者快速显示主画面并异步来填充这些信息。在这两种情况下，你都应该显示正在进行的进度，以免用户认为应用程序被冻结了。
  

######################################Android ANR分析15:59:37 I/ActivityManager(130): ANR in process: com.android.email (last in com.android.email)

=>frameworks/base/services/java/com/android/server/am/ActivityManagerService.java
=>提示输出cpu信息
Annotation: keyDispatchingTimedOut
CPU usage:

=>frameworks/base/services/java/com/android/server/ProcessStats.java
=>输出cpu当前状态
=>/proc/loadavg 显示cpu负荷
=>1-分钟平均负载 / 5-分钟平均负载 / 15-分钟平均负载
Load: 4.37 / 4.55 / 3.97
=>cpu状态的时间段
CPU usage from 10987ms to 27ms ago:


  =>/proc/state读取cpu的使用情况
  =>http://linux.die.net/man/5/proc
  =>user
  =>kernel
  =>iowait
  =>irq -> 0
  =>softirq -> 0
  =>minor
  The number of minor faults the process has made which have not required loading a memory page from disk.

  =>major
  The number of major faults the process has made which have required loading a memory page from disk.

  system_server: 12% = 4% user + 7% kernel / faults: 1886 minor
  m.android.email: 12% = 6% user + 5% kernel / faults: 2716 minor
  sensorserver_ya: 7% = 0% user + 7% kernel
  breeze.launcher: 3% = 0% user + 3% kernel / faults: 94 minor
  ocess.msn.shell: 0% = 0% user + 0% kernel / faults: 38 minor
  m.android.phone: 0% = 0% user + 0% kernel
  alog: 0% = 0% user + 0% kernel
  rpcrotuer_smd_x: 0% = 0% user + 0% kernel
  rild: 0% = 0% user + 0% kernel
  alog: 0% = 0% user + 0% kernel
  events/0: 0% = 0% user + 0% kernel
  port-bridge: 0% = 0% user + 0% kernel
TOTAL: 81% = 13% user + 25% kernel + 42% iowait



15:59:37 I/ActivityManager(130): Removing old ANR trace file from /data/anr/traces.txt