关于ANR的官方建议

本人博客原文

本翻译整理自： http://developer.android.com/guide/practices/responsiveness.html

参考译文： http://blog.csdn.net/su1216/article/details/7876645

Designing for Responsiveness

IN THIS DOCUMENT

1. What Triggers ANR?
2. How to Avoid ANR
3. Reinforcing Responsiveness

Figure 1. An ANR dialog displayed to the user.

It's possible to write code that wins every performance test in the world, but still sends users in a fiery rage when they try to use the application. These are the applications that aren't responsive enough — the ones that feel sluggish, hang or freeze for significant periods, or take too long to process input.

有可能写出的代码赢得了每一次性能测试，但是却仍然使得当用户尝试使用应用时，使他们处于怒火之中。这是因为应用的响应不够迅速 - 用户可能会觉的应用程序运行缓慢，应用程序被挂起，或因冻结很长时间而无反应，或者处理输入时间过长。

In Android, the system guards against applications that are insufficiently responsive for a period of time by displaying a dialog to the user, called the Application Not Responding (ANR) dialog, shown at right in Figure 1. The user can choose to let the application continue, but the user won't appreciate having to act on this dialog every time he or she uses your application. It's critical to design responsiveness into your application, so that the system never has cause to display an ANR dialog to the user.

在Android中，系统会监视那些反应不够迅速的应用。如果系统发现某个应用程序反应太慢，它会显示一个叫做Application Not Responding (ANR)的对话框给用户，如Figure 1所示。用户可以选择等待该应用程序让它继续，也可以选择强行结束该应用程序。虽然用户可以选择等待该应用程序让它继续，但是用户其实是非常不喜欢出现该对话框（ANR提示框）

因此设计具有较好响应性的应用程序是非常重要的，这样系统才不会给用户显示一个ANR对话框。

Generally, the system displays an ANR if an application cannot respond to user input. For example, if an application blocks on some I/O operation (frequently a network access), then the main application thread won't be able to process incoming user input events. After a time, the system concludes that the application is frozen, and displays the ANR to give the user the option to kill it.

一般来说，如果一个应用不能快速响应用户输入，则系统显示一个ANR。例如：如果一个应用程序的主线程因为在进行一些I/O操作而被阻塞了（经常是一个网络访问），那么该应用程序的主线程此时就没有能力处理用户的输入事件。一段时间后，系统推断出这个应用冻结了，然后显示一个ANR给用户一个选择杀死此应用或等待该应用程序操作完成后继续。

Similarly, if your application spends too much time building an elaborate in-memory structure, or perhaps computing the next move in a game, the system will conclude that your application has hung. It's always important to make sure these computations are efficient using the techniques above, but even the most efficient code still takes time to run.

相似的，如果你的应用程序的主线程消耗太多时间来建立一个复杂的内存中的结构，或者计算游戏中的下一步，系统会断定你的应用已经挂起。总是保证使用上面的技巧这些计算是有效率的是很重要的，但是即使是最有效的代码也需要时间来运行。

In both of these cases, the recommended approach is to create a child thread and do most of your work there. This keeps the main thread (which drives the user interface event loop) running and prevents the system from concluding that your code has frozen. Since such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic performance, which was described above as a method-level concern.)

这两种情况中，推荐的方法是建立一个子线程来做你在那里的大部分工作。这样保持主线程运行并且阻止系统认定你的代码已经冻结。因为这样的线程经常在类级别中完成，你可以把响应性作为一个类的问题考虑。

This document describes how the Android system determines whether an application is not responding and provides guidelines for ensuring that your application stays responsive.

What Triggers ANR?

---

In Android, application responsiveness is monitored by the Activity Manager and Window Manager system services. Android will display the ANR dialog for a particular application when it detects one of the following conditions:

在Android中，应用响应度是由Activity Manager和Window Manager系统服务监视的。Android当发现到下面其中一个条件发生的时候，会特定的应用显示ANR对话框。

• No response to an input event (e.g. key press, screen touch) within 5 seconds.一个输入事件5秒内没有反馈。 但是并不意味着花4秒时间来处理输入事件是安全的。相反对于这种主线程的回调函数，应该让其执行时间尽量的短，以避免主线程，以便主线程能处理一些更重要更紧急的事务。
• A BroadcastReceiver hasn't finished executing within 10 seconds In Android, application responsiveness is monitored by the Activity .一个BroadcastReceiver在10秒内没有执行完毕。但是并不意味着在BroadcastReceiver的OnReceiver中花9秒时间来处理事务是安全的。相反对于这种主线程的回调函数，应该让其执行时间尽量的短，以避免主线程，以便主线程能处理一些更重要更紧急的事务。

  How to Avoid ANR

  ---

  Given the above definition for ANR, let's examine why this can occur in Android applications and how best to structure your application to avoid ANR.

  通过上面的叙述，我们已经了解了什么是ANR的定义，现在让我们再次认识为什么Android应用中会ANR中发生，并且如何才能设计更好的架构来避免ANR的发生。

  Android applications normally run entirely on a single (i.e. main) thread. This means that anything your application is doing in the main thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or Intent broadcast.

  Android应用通常整个都运行在一个线程中（主线程）。这意味着，你应用中做的任何事情都在主线程，如果耗时太多就可能触发ANR对话框，因为主线程来不及处理用户输出或者Intent广播及其他回调函数。

  Therefore any method that runs in the main thread should do as little work as possible. In particular, Activities should do as little as possible to set up in key life-cycle methods such asonCreate() and onResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a child thread (or in the case of databases operations, via an asynchronous request). However, this does not mean that your main thread should block while waiting for the child thread to complete — nor should you call Thread.wait() or Thread.sleep(). Instead of blocking while waiting for a child thread to complete, your main thread should provide a Handler for child threads to post back to upon completion. Designing your application in this way will allow your main thread to remain responsive to input and thus avoid ANR dialogs caused by the 5 second input event timeout. These same practices should be followed for any other threads that display UI, as they are also subject to the same timeouts.

  因此任何在主线程中调用的函数都应该做尽量少的工作。尤其是四大组件的生命周期函数，比如Activity的生命周期函数onCreate() 和onResume().对于需要长时间运行的操作，如网络或者数据库操作，或者高代价的计算，或者调整bitmap大小，应该放在一个子线程中来执行。然而，这不意味着你的主线程应该在等待子线程完成时而阻塞，你的主线程应该为子线程提供一个 Handler ,当完成时把结果返回给主线程 - 而不该调用 Thread.wait() 或 hread.sleep()。按照这种思路来设计你的Android应用程序，你的应用程序就能对输入事件进行很好的反应，以避免因为无法在5秒内对输入事件进行响应而产生的ANR对话框。其实对于任何用于显示UI的线程都应该遵循以上原则，因为它们都面临着对输入事件不能及时响应的问题。关于Handler的更多内容请阅读《Android线程模型》和《关于Handler技术》和《Looper和Handler》

  You can use StrictMode to help find potentially long running operations such as network or database operations that you might accidentally be doing your main thread.

  你可以使用 StrictMode 来帮助你在主线程中查找潜在的耗时操作，比如对网络或数据库操作。

  The specific constraint on IntentReceiver execution time emphasizes what they were meant to do: small, discrete amounts of work in the background such as saving a setting or registering a Notification. So as with other methods called in the main thread, applications should avoid potentially long-running operations or calculations in BroadcastReceivers. But instead of doing intensive tasks via child threads (as the life of a BroadcastReceiver is short), your application should start a Service if a potentially long running action needs to be taken in response to an Intent broadcast. As a side note, you should also avoid starting an Activity from an Intent Receiver, as it will spawn a new screen that will steal focus from whatever application the user is currently has running. If your application has something to show the user in response to an Intent broadcast, it should do so using the Notification Manager.

  线程对IntentReceiver执行时间上的明确的约束，主要是为了强调它是用于执行非常少量的工作 - 只是用于分离一些在后台工作，比如保存一个设置或者注册一个Notification。因此和其他在主线程中调用的其他方法一样，在BroadcastReceivers内应该避免的长时间操作或计算。对于耗时的工作，因为BroadcastReceivers的生命周期是非常短暂的，因此你也不应该在其中开启一个子线程来做该工作，而是应该启动一个 Service,再在这个Service中创建一个子线程来做该工作。另外，你也应该避免从一个Intent过滤器启动一个activity，因为它将产生一个新屏幕，从用户当前运行的应用中偷走焦点。如果你的应用中有一些内容作为Intent广播的反馈需要显示给用户，它应该使用Notification Manager来完成。

  Reinforcing Responsiveness

  ---

  Generally, 100 to 200ms is the threshold beyond which users will perceive lag (or lack of "snappiness," if you will) in an application. As such, here are some additional tips beyond what you should do to avoid ANR that will help make your application seem responsive to users.

  一般来说，在应用中，100到200毫秒是用户能不能察觉延迟的临界值。（每个人反应速度不一样，所以会有100ms-200ms这个范围）这有一些额外的窍门是你为了避免ANR而应该做的，会帮助你的应用对用户来说看起来是很灵敏的。

  • If your application is doing work in the background in response to user input, show that progress is being made (ProgressBar and ProgressDialog are useful for this).如果你的应用正在后台工作来响应用户输入，那么给用户显示你的执行进度是个不错的选择（ProgressBar和ProgressDialog在这点上很有用）。
  • For games specifically, do calculations for moves in a child thread.对于游戏来说， 移动的运算应该在子线程中来进行。
  • If your application has a time-consuming initial setup phase, consider showing a splash screen or rendering the main view as quickly as possible and filling in the information asynchronously. In either case, you should indicate somehow that progress is being made, lest the user perceive that the application is frozen.如果你的应用在初始化阶段较耗时，考虑显示一个splash屏或者尽快让主视图快速显示处理，然后才显示其他的视图。不管是哪一种情况，你应该设法表明程序正在往前执行，以免用户觉得应用冻结了。