Android ANR Problem Analysis

This may happen. The code you write passes all the performance tests in the world, but it still makes users feel uncomfortable when they try to use your application. Some areas where the application is not responsive include: slow response, long suspension or freezing, or a long time to process input.

On Android, if your application is not responsive for a period of time, the system will display you a dialog box called ANR: application not responding. You can choose to keep the program running, but they do not want to process this dialog box every time they use your application. Therefore, the design of response performance in the program is very important, so that the system will not display ANR to the user.

Generally, if the application cannot respond to user input, the system displays an ANR. For example, if an application blocks some I/O operations (usually network access), the main thread of the application cannot process user input events. After a certain period of time, the system considers the application has been suspended and displays ANR to allow the user to choose to kill the application.

Similarly, if your application spends too much time building a detailed memory structure, or maybe it takes too much time in the game to calculate the next move, then, the system will think that your application has been suspended. Therefore, it is often important to ensure that these computations are efficient, but even the most efficient code still takes time to run.

In both cases, the solution is to create a sub-thread and then perform most of your work in the thread. This keeps the main thread (driving the UI event loop) Running and prevents the system from believing that your code has been frozen. Because these threads are generally completed at the class level, you can consider the response performance issue as a class issue. (Compared with basic performance, basic performance problems are considered as method-level problems)

This article will discuss how the Android system judges that an application is unresponsive and provides a wizard to ensure the responsiveness of the application.

This article covers these topics:

What triggers ANR?
How to Avoid ANR?
Enhanced Response Sensitivity

1) what triggers ANR?

In Android, the responsiveness of applications is monitored by the system services of activity manager and window manager. When it detects one of the following situations, Android displays ANR for specific applications:

Events that do not respond to input within 5 seconds (for example, pressing a button or touching the screen)
Broadcastreceiver is not executed within 10 seconds.

An ANR dialog box is displayed to the user.

2) How to Avoid ANR?

Considering the above ANR definition, let's take a look at why it occurs in Android applications and how to best build applications to avoid ANR.

Android applications usually run in a separate thread (for example, main. This means that if your application takes too long in the main thread, the ANR dialog box will be triggered, because your application does not have the opportunity to handle input events or intent broadcasts.

Therefore, any method running in the main thread should do as little as possible. In particular, the activity should do as few creation operations as possible in its key lifecycle methods (such as oncreate () and onresume. Potential time-consuming operations, such as network or database operations, or high-time computing such as bitmap size change, should be in the Child thread (or take database operations as an example, through asynchronous request). However, it does not mean that your main thread is blocked and waits for the completion of the sub-thread-or it does not call thread. Wait () or thread. Sleep (). The alternative is that the main thread should provide a handler for the sub-thread so that it can be submitted to the main thread upon completion. Designing your application in this way will ensure that your main thread is responsive to the input and avoid the ANR dialog box caused by 5 seconds of input event timeout. This approach should be followed in other display UI threads because they are all affected by the same timeout.

The special restrictions on intentreceiver execution time mean that it should do: do small, trivial work in the background, such as saving settings or registering a notification. Like other methods called in the main thread, applications should avoid time-consuming operations or calculations in broadcastreceiver. Instead of doing these tasks in the Child thread (because broadcastreceiver has a short life cycle), the alternative is that if you need to perform a time-consuming action in response to the intent broadcast, the application should start a service. By the way, you should also avoid starting an activity in the intent receiver because it creates a new screen and grabs the focus from the program that the current user is running. If your application needs to show users what they want to respond to intent broadcast, you should use notification manager.

3) enhanced response sensitivity

In general, 100 to MS is the time threshold for the user to perceive the block in the application. Therefore, here are some additional tips to avoid ANR and help make your application look responsive.

If your application is working in the background for the response user input, the progress of the work can be displayed (progressbar and progressdialog are useful in this case ).
Especially for games, mobile computing is performed in sub-threads.
If your application has a time-consuming initialization process, you can display a splash screen or quickly display the main screen and asynchronously fill in the information. In both cases, you should display the progress in progress so that users do not think the application is frozen.