Source Address: $ {Android-SDK-Windows}/docs/GUIDE/practices/design/responsiveness.html
You wroteCode It may be able to pass all the performance tests in the world, but users may go crazy when using your application. Because your application Program The user's responsiveness is too bad. For example, the user's usage is not smooth enough, the user suspends or loses the response at a critical moment, or spends too much time processing the user's input. In the Android system, when the application does not respond for a period of time, the system will detect this situation and display a dialog box to the user, this dialog box is called the "ANR" dialog box (application not responding ). At this time, you can choose to continue waiting for the program to run, or choose to force close the application. However, if the dialog box is displayed and the operation is selected every time you use this application, it is obvious that the user is not very comfortable. Therefore, it is very important to add considerations for application responsiveness in your design to prevent the system from popping up this ANR dialog box.
Normally, if the application cannot respond to user input, the ANR dialog box is displayed. For example, if an application is blocked due to I/O operations (usually accessing the network), the main thread of the application cannot process user input events. After a period of time, the system determines that the application is "Frozen", and the ANR dialog box is displayed to close the application selection. Similarly, if your application spends a lot of time building a complex data structure in the memory, or it may be computing the next mobile point in the game, at this time, the system will think that your program has been suspended. In this case, first confirm yourAlgorithmPerformance is good enough, but even the most efficient code, it takes time to run. For the two cases mentioned above, we strongly recommend that you create a sub-thread to complete these time-consuming operations in the sub-thread. In this case, because The event loop on the user interface runs in the main thread, so you can keep the main thread running to avoid the system thinking that your program is "Frozen ". Because these threads are generally completed through classes, you can think of the application response issue as a class-level problem, which corresponds to a performance issue generally at the method level. This article describes how the Android system judges that an application is unresponsive and provides a guide to improving application responsiveness.
What triggers ANR? (What triggers ANR ?) In Android, The system monitors application responsiveness through activity manager and window manager. When an application detected by the System displays the following situation, the ANR dialog box is displayed: 1. user input events (such as buttons and touch screens) are not responded within 5 seconds; 2. A broadcastreceiver cannot be processed within 10 seconds.
How to Avoid ANR (how to avoid ANR) The ANR definition is given above. Now let's take a look at why ANR appears in Android applications and how to avoid ANR in your programs. Android applications generally run in a single thread (main thread). This means that any things in your applications that take a long time to execute in the main thread will lead to ANR, because your application has no chance to process user input events or broadcast messages. Therefore, every method running in your main program thread should do as little work as possible. In particular, activities should do as little work as possible in major life cycle methods such as oncreate () or onresume. Operations that may run for a long time, such as network or database operations, or operations that consume a large amount of computing, such as recalculating the bitmap size, should be completed in sub-threads as much as possible (or, for database operations, you can consider using asynchronous requests ). However, this does not mean that your main thread should be blocked or call thread. Wait () or thread. Sleep () before the sub-thread completes running (). The main thread should provide a handler to return information when the sub-thread finishes running, rather than blocking itself to wait for the sub-thread to complete. The above method can be used to design your application to ensure the responsiveness of your application, so as to avoid the ANR dialog box caused by 5 seconds of user Event Response timeout. Other threads on the display interface should also follow the above practices, because they are also subject to this timeout rule. You can use the Android. OS. strictmode tool to find potential time-consuming operations such as database and network operations accidentally introduced in your program. For more information about the usage, see the usage instructions for the Android. OS. strictmode class. Special Constraints on intentreceiver execution time indicate that they should perform some small and discrete tasks in the background, such as saving configuration information and registering a notification. Therefore, like the method called in the main thread, the application should avoid executing some potentially time-consuming operations/calculations in broadcastreceivers. However, when you want to respond to a time-consuming broadcast message (broadcast), your application should start a service instead of completing these tasks in the Child thread, because the broadcastreceiver declaration cycle is very short. By the way, you should avoid starting an activity in an intent worker, because this will generate a new screen, so that the user's current running program will lose focus. If your application needs to display some information to the user when responding to an intent broadcast, you can consider using the notification manager ).
Reinforcing responsiveness (enhanced responsiveness) Generally,-milliseconds indicates the latency threshold of the application. Here are some tips that can make your application avoid ANR and seem responsive: --> If your application is processed in the background to respond to user input, you can use progressbar or progressdialog to display the current running progress. --> Especially for games, the computing position is moved in the Child thread; --> if your application has a time-consuming initialization step, consider using a startup screen, alternatively, you can quickly display the main view and load data information asynchronously. In either case, you should imply that the user application is being operated to avoid making the user think that the program has been frozen.
