Android-design for responsiveness-development document translation

Designing for Responsiveness
Designed 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.
It is possible that the written code won every one-time test, but it still makes the user angry when trying to use the application.
This is because the application does not respond quickly enough-these applications feel slow, suspended or frozen for a long time, or process input for a long time.

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.
In Android, The system monitors applications that do Not respond quickly for a period of time and displays a dialog box called Application Not Responding (ANR) to the user, as shown in.
The user can choose to continue the application, but each time you use your application, the user does not like to have to follow the system pop-up dialog box to do the corresponding operations
It is very important to design responsive applications so that the system will not display an ANR dialog box to users.

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.
Generally, if an application cannot respond to user input, the system displays an ANR.
For example, if an application is blocked in some I/O operations (often a network access), the main application thread will not be able to process user input events.
After a period of time, the system determines that the application is frozen, and then shows an ANR to give the user a choice to kill the application.

Similarly, if your application has Ds 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.
Similarly, if your application consumes too much time to build a complex structure in memory, or you may calculate the next step in the game, the system determines that your application has been suspended.
It is always important to ensure that the above techniques are effective, but even the most effective code 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 abve as a method-level concern .)
In both cases, the recommended method is to create a sub-thread to do most of your work there.
In this way, keep the main thread running and prevent the system from confirming that your code has been frozen.
Because such threads are often completed at the class level, you can consider responsiveness as a class problem.

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

What Triggers ANR?
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 special application when it detects one of the following conditions:
In Android, the application response is monitored by the system services of Activity Manager and Window Manager.
When one of the following conditions is found in Android, the ANR dialog box is displayed for a specific application.

No response to an input event (e.g. key press, screen touch) within 5 seconds
A BroadcastReceiver hasn't finished executing within 10 seconds
No feedback for one input event within 5 seconds
A BroadcastReceiver fails to be executed within 10 seconds.

How to Avoid ANR
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.
Given the definition of ANR above, let's check why these Android applications occur and how best your applications can be structured to avoid 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 applications usually run in one thread (main thread ).
This means that everything you do in your application is in the main thread, and it takes a long time to complete the ANR dialog box that may be triggered, because your application does not give it the opportunity to process user output or Intent broadcast.

Therefore any method that runs in the main thread shoshould do as little work as possible.
In particle, Activities shocould 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 shocould 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 shocould block while waiting for the child thread to complete-nor shoshould you call Thread. wait () or Thread. sleep ().
Instead of blocking while waiting for a child thread to complete, your main thread shoshould 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 shoshould be followed for any other threads that display UI, as they are also subject to the same timeouts.
Therefore, any method running on the main thread should work as little as possible.
In particular, the Activity should do as little work as possible to prepare key lifecycle methods, such as onCreate () and onResume ().
Potential long-running operations, such as network or database operations, or high-cost computing, such as adjusting the bitmap size, should be completed in a subthread.
However, this does not mean that your main thread should be blocked while waiting for the completion of the sub-thread. Your main thread should provide a Handler for the sub-thread, return the result to the main Thread upon completion-instead of calling the Thread. wait () or 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.
You can use StrictMode to help you find potential long-running operations, such as network or database operations that you may accidentally perform in your main thread.

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 shocould 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 shocould start a Service if a potentially long running action needs to be taken in response to an Intent broadcast.
As a side note, you shoshould also avoid starting an Activity from an Intent guest er, 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 shoshould do so using the Notification Manager.
IntentReceiver clearly defines the execution time constraints and emphasizes what they intend to do at that time: a small amount of work-the separation of a large amount of work in the background, such as saving a setting or registering a Notification.
Therefore, like calling other methods in the main thread, applications should avoid potential long-term operations or computing within BroadcastReceivers.
However, if a potential long-running behavior needs to receive an Intent broadcast response, your application should start a Service instead of doing some high-intensity work through the sub-thread.
As a note, you should also avoid starting an activity from an Intent filter because it will generate a new screen and steal the focus from the application currently running the user.
If your application has some content to be displayed to users as Intent broadcast feedback, it should be completed using Notification Manager.

Reinforcing Responsiveness
Enhanced response
Generally, 100 to 200 ms 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.
In general, in applications, 100 to 200 milliseconds is beyond the threshold for users to detect latency. (Each response speed is different, so there will be a range of MS-MS)
There are some additional tips you should do to avoid ANR, which will help your application become more responsive to users.

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 shoshould indicate somehow that progress is being made, lest the user perceive that the application is frozen
If your application is working in the background to respond to user input, display the process (ProgressBar and ProgressDialog are useful in this regard)
Especially for games, the mobile operation is performed in sub-threads.
If your application is time-consuming during initialization, consider displaying a copyright page or giving up the master view as soon as possible and asynchronously filling information.
In either case, you should try to indicate the process so that users do not feel that the application is frozen.