Responsive Design of official Android documents

(If you translate it by yourself, please note it. Thank you. I will fix the missing image, typographical issues, and invalid links. Please check the androidsdk documentation before)

Even if you writeCodeWith all the performance tests in the world, your application may still drive users into a rage. LackResponsiveness-Applications that are slow in response, slow in some cases, and very long in processing input can achieve this.

In Android, the system displays an "Application No response (ANR)" dialog box to defend against applications that have not been responded to for a period of time. You can choose to continue your application in this dialog box, but you do not like to always see this dialog box when using your application. Therefore, designing responsiveness in your application is very important, and the system will not pop up ANR for users.

In general, when the application does not have a corresponding user input, the system displays ANR. For example, if an application is blocked in some input/output operations (such as frequent network requests), the main thread of the application will not continue to respond to user input events. After a period of time, the system will think that the application has been scrapped, so an ANR will pop up to allow users to choose whether to forcibly close the application.

Similarly, if your applications spend too much time building a sophisticated data structure or computing game's next step, the system will think your applications are useless. It is very important to use the technologies mentioned below to make your computing more efficient, but even the most efficient code will still consume time.

In both cases, creating a sub-thread to complete the work is a common repair method. In this way, the main thread (response to the UI event loop) will continue to run, and the system will not think your code is dead. Generally, threads belong to the class level, so you can think that responsiveness isClassLevel issues. (Compared with the basic behavior, the basic behavior is described as follows, which isMethodLevel .)

An ANR dialog displayed to the user.

This document describes how the Android system determines whether an application is unresponsive and provides guidance to ensure code responsiveness.

This document contains the following content:

• What is ANR triggered?
• How to Avoid ANR?
• Enhance responsiveness.

What is ANR triggered?

In Android, application responsiveness is monitored by activitymanager and windowmanager. For an application, Android will pop up ANR in the following two cases:

• The input event (buttons, click on the screen, and so on) does not match within 5 seconds.
• OneBroadcastreceiverThe execution time exceeds 10 seconds.

How to Avoid ANR

Through the ANR definition given above, Let's see why Android apps do not respond and how to avoid this.

Generally, Android applications run in a single thread (main thread. This means that in the main thread, any action that takes a long time to complete will trigger the ANR dialog box because your application has no chance to process the input event or broadcast intent.

Therefore, any method that works in the main thread should do the least. Activity key lifecycle methods, suchOncreate ()AndOnresume ()To do as little as possible. Potential time-consuming operations, such as network or database operations, or a large number of mathematical operations such as scaling bitmaps, should be performed in subthreads. (For database operations, you can use an Asynchronous Method without putting it into another thread ). This does not mean that your main thread should block waiting for the sub-thread, whether throughThread. Wait ()OrThread. Sleep (). Your main thread should provideHandlerTo return results after the sub-thread ends. By designing your application, your main thread can maintain a response speed of less than 5 seconds to the input, thus avoiding the ANR dialog box. If other threads involve displaying the UI, the same practice should be followed.

The execution time of intentreceiver indicates that the tasks it should do are small-scale tasks in the background, such as saving settings or registering notification. Therefore, like the main thread method, applications should avoid potential time-consuming operations or operations in broadcastreceiver. In addition to processing a large number of intensive tasks in sub-threads (because broadcastreceiver has a short life cycle ). When a potentially time-consuming operation needs to return a broadcast intent, your application should startService. Additionally, you should avoid starting the activity from an intentreceiver. This will jump out of a new interface and interrupt the work that the user is doing. If your application needs to display the content to users after receiving the broadcast intent, it should useNotification Manager.

Enhanced responsiveness

Generally, 100 to 200 milliseconds is the threshold for users to feel "stuck. The following are some suggestions for avoiding ANR and accelerating your application response.

• If your application needs to wait for the results of background work to show its progress. (AvailableProgressbarOrProgressdialog)
• For games, a large amount of Computing should be placed in sub-threads.
• If your application initialization takes a long time, consider using a splashscreen or entering the main interface as soon as possible and then filling it in asynchronously. In both cases, you should provide the user with a progress bar or something like this, indicating that your application is not dead yet.

 

To http://blog.csdn.net/sirdonker/article/details/5647805