android - 为响应度而设计 - 开发文档翻译

由于本人英文能力实在有限，不足之初敬请谅解，希望大家落脚同时能指出不足。

本博客只要没有注明“转”，那么均为原创，转贴请注明链接

 

android 进程与线程 - 开发文档翻译 - 进程

android 进程与线程 - 开发文档翻译 - 线程

 

其他系列的翻译

android activity开发文档翻译 - 1 - 基础篇

android activity开发文档翻译 - 2 - 生命周期篇

 

android task与back stack 开发文档翻译 - 1

android task与back stack 开发文档翻译 - 2

android task与back stack 开发文档翻译 - 3

 

android Fragment开发文档翻译 - 1

android Fragment开发文档翻译 - 2

 

本系列并没有对原文100%翻译，可能没有100%的贴出原文

 

Designing for Responsiveness

为响应度而设计

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)对话框，向下图所示那样。

用户可以选择是让应用继续，但是每一次使用你的应用，用户不会喜欢不得不依照系统弹出的对话框做相应操作

设计较好响应性的应用是很重要的，这样系统才不会给用户显示一个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.

这个文档描述了Android系统如何决定是否一个应用是无响应并且提供直到方针来保证你的应用保持响应。

 

 

What Triggers ANR?

什么触发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

A BroadcastReceiver hasn't finished executing within 10 seconds

一个输入事件5秒内没有反馈

一个BroadcastReceiver在10秒内没有执行完毕。

 

 

How to Avoid ANR

如何避免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。

 

 

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 as onCreate() 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()或Thread.sleep()。

 

 

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内避免潜在的长时间操作或计算。

但是，如果一个潜在的长时间运行的行为需要接收一个Intent广播的响应，你的应用应该开启一个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).

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

如果你的应用正在后台工作来响应用户输入，展示那个过程（ProgressBar和ProgressDialog在这点上很有用）

尤其是对游戏来说，在子线程进行对移动的运算。

如果你的应用在初始化阶段较耗时，考虑显示一个版权页或者尽快让出主视图并且异步的填充信息。

不管是哪一种情况，你应该设法表明那个过程，免得用户觉得应用冻结了。

 

 

原文地址如下，英文水平实在有限，希望拍砖同时能给予指正。

http://developer.android.com/guide/practices/responsiveness.html

 

 

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

http://blog.csdn.net/su1216/