Deadlock Android ANR

The following is a section of the ANR log, mainly implemented in Windowmanagerservice.java and Activitymanagerservice.java.

W/windowmanager (2183): Key dispatching timed out sending to Com.android.camera/com.android.camera.camera
W/windowmanager (2183): Previous Dispatch state: {{keyevent{action=0 code=4 repeat=0 meta=0 scancode=158 mflags=8} to Wind ow{4622ad58 Com.android.camera/com.android.camera.camera Paused=false} @ 5419631 lw=window{4622ad58 Com.android.camera/com.android.camera.camera Paused=false} [email protected] fin=false gfw=true ed=true tts=0 wf=false Fp=false mcf=window{4622ad58 Com.android.camera/com.android.camera.camera Paused=false}}}
W/windowmanager (2183): Current dispatch state: {{keyevent{action=1 code=4 repeat=0 meta=0 scancode=158 mflags=8} to Windo w{4622ad58 Com.android.camera/com.android.camera.camera Paused=false} @ 5424762 lw=window{4622ad58 Com.android.camera/com.android.camera.camera Paused=false} [email protected] fin=false gfw=true ed=true tts=0 wf=false Fp=false mcf=window{4622ad58 Com.android.camera/com.android.camera.camera Paused=false}}}

The following is an error when opening the log file, so the calling process is printed out.

W/activitymanager (2183): Unable to prepare ANR traces file:/data/local/anr/traces.txt
W/activitymanager (2183): Java.io.IOException:No such file or directory
W/activitymanager (2183): at Java.io.File.createNewFileImpl (Native Method)
W/activitymanager (2183): at Java.io.File.createNewFile (file.java:1160)
W/activitymanager (2183): at Com.android.server.am.ActivityManagerService.dumpStackTraces ( activitymanagerservice.java:4801)
W/activitymanager (2183): at Com.android.server.am.ActivityManagerService.appNotResponding ( activitymanagerservice.java:4875)
W/activitymanager (2183): at Com.android.server.am.HistoryRecord.keyDispatchingTimedOut (historyrecord.java:489)
W/activitymanager (2183): at Com.android.server.windowmanagerservice$keywaiter.waitfornexteventtarget ( windowmanagerservice.java:5825)
W/activitymanager (2183): at Com.android.server.WindowManagerService.dispatchKey (windowmanagerservice.java:5367)
W/activitymanager (2183): at com.android.server.windowmanagerservice.access$1300 (windowmanagerservice.java:137)
W/activitymanager (2183): at Com.android.server.windowmanagerservice$inputdispatcherthread.process ( windowmanagerservice.java:6597)
W/activitymanager (2183): at Com.android.server.windowmanagerservice$inputdispatcherthread.run ( windowmanagerservice.java:6482)

I/process (2183): Sending signal. pid:2640 Sig:3
I/DALVIKVM (2640): Threadid=3:reacting to signal 3

The following is the CPU information when the ANR occurs

E/activitymanager (2183): ANR in Com.android.camera (com.android.camera/. Camera)
E/activitymanager (2183): Reason:keydispatchingtimedout
E/activitymanager (2183): load:0.94/0.51/0.2
E/activitymanager (2183): CPU usage from 10552ms to 14ms ago:
E/activitymanager (2183): mediaserver:10% = 9% user + 1% kernel/faults:1081 minor
E/activitymanager (2183): system_server:7% = 2% user + 4% kernel/faults:1484 minor 1 major
E/activitymanager (2183): mmcqd:3% = 0% user + 3% kernel
E/activitymanager (2183): e168.wowgallery:1% = 0% user + 0% kernel/faults:30 minor
E/activitymanager (2183): logcat:0% = 0% user + 0% kernel
E/activitymanager (2183): zygote:0% = 0% user + 0% kernel
E/activitymanager (2183): kblockd/0:0% = 0% user + 0% kernel
E/activitymanager (2183): usb_mass_storag:0% = 0% user + 0% kernel
E/activitymanager (2183): logcat:0% = 0% user + 0% kernel
E/activitymanager (2183): +.android.camera:0% = 0% user + 0% kernel
E/activitymanager (2183): +v4l2q:0% = 0% user + 0% kernel
E/activitymanager (2183): total:64% = 14% user + 14% kernel + 33% iowait + 1% SOFTIRQ
E/DALVIKVM (2640): Unable to open stack trace file '/data/local/anr/traces.txt ': No such file or directory
I/xxx (2183): Getthemefilename:cookie = 1, path:/data/system/theme/framework/res/drawable-mdpi/ic_dialog_info.png
I/xxx (2183): Getthemefilename:cookie = 1, path:/data/system/theme/framework/res/drawable-mdpi/ic_dialog_menu_ Generic.png
I/xxx (2183): Getthemefilename:cookie = 1, path:/data/system/theme/framework/res/drawable-mdpi/ic_dialog_alert.png
W/windowmanager (2183): Continuing to wait for key to be dispatched

The following documents are transferred from: http://www.cnblogs.com/xirihanlin/archive/2010/01/07/1641621.html

There may be situations where the code you write passes all the performance tests in the world, but it still makes users uncomfortable when they try to use your application. Areas where application responsiveness is not sensitive include------are unresponsive, hang or freeze for a long time, or take a long time to process input.

On Android, if your application has been unresponsive for a while, the system will show the User a dialog box called the application unresponsive (anr:application not responding) dialog box. Users can choose to keep the program running, but they do not want to process the dialog box every time they use your application. Therefore, it is important to design the response performance in the program so that the system does not show the ANR to the user.

In general, if the application does not respond to user input, a ANR is displayed. For example, when an application blocks on some I/O operations (usually network access), the application's main thread can no longer process the user's input events. After a certain amount of time, the system thinks the application has been suspended and displays the ANR to let the user choose to kill the application.

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

In both cases, the workaround is usually to create a sub-thread, and then do most of your work in the thread. This keeps the main thread (driving the UI event loop) running and prevents the system from thinking that your code has been frozen. Because these threads are usually done at the class level, you can assume that the response performance issue is a class problem. (Basic performance issues are considered method-level issues compared to basic performance)

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

This article includes these topics:

• What triggered the ANR?
• How to avoid ANR?
• Enhanced Response Agility
  

1) What caused the ANR?

In Android, the responsiveness of the application is monitored by the Activity Manager and the Window Manager system service. When it detects one of the following situations, Android displays the ANR for a specific application:

• There is no response to input events within 5 seconds (for example, press the button, touch the screen)
• Broadcastreceiver has not been executed within 10 seconds.
  

A ANR dialog box is displayed to the user

2) How to avoid ANR?

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

Android applications are typically run on a separate thread (for example, main). This means that if your application does something that takes too long in the main thread, the ANR dialog will be raised because your application does not give itself the opportunity to handle input events or intent broadcasts.

So any method that runs on the mainline thread does as little as possible. In particular, activity should create as little as possible in its critical life-cycle methods, such as OnCreate () and Onresume (). Potentially time-consuming operations, such as network or database operations, or high time-consuming computations such as changing the bitmap size, should be done in the thread of the Strand (or, in the case of database operations, through asynchronous requests). However, it does not mean that your main thread is blocking there waiting for the child thread to complete------is not called thread.wait () or Thread.Sleep (). Instead, the main thread should provide a handler for the child thread so that it can be submitted to the main thread when it is complete. Designing your application in this way will ensure that your main thread remains responsive to the input and can avoid the ANR dialog that is raised due to the timeout of the 5-second input event. This practice should be emulated in other threads that display the UI because they are affected by the same timeout.

The special limitation of intentreceiver execution time means it should: do small, trivial work in the background, such as saving settings or registering a notification. Like other methods that are called in the main thread, applications should avoid time-consuming operations or calculations in Broadcastreceiver. Instead of doing these tasks in a sub-thread (because of the short life cycle of broadcastreceiver), the application should start a Service if responding to intent broadcasts requires a time-consuming action. Incidentally, you should also avoid starting an activity in 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 the user what to do in response to intent broadcasts, you should use Notification Manager.

3) Enhanced response Agility

In general, 100 to 200ms is the time threshold in the application where the user can sense the block. So here are some extra tricks to avoid the ANR and help make your application look responsive.

• If your application is working behind the scenes in response to user input, you can show the progress of your work (ProgressBar and progressdialog are useful for this scenario).
• In particular the game, in the sub-thread to do mobile computing.
• If your application has a time-consuming initialization process, consider displaying a splash screen or quickly displaying the main picture and populating the information asynchronously. In both cases, you should display the progress you are making in order to prevent users from thinking that the application is frozen.

Deadlock Android ANR