Yep! And a 'long time' can mean different things. If you need to have a smooth UI experience (and you should), keep the processing for any UI-event (i.e. any method called on the main UI thread) under 100ms (1/10th of a second). And that's pushing it.
On button clicks, when the user moves from one screen to another, and similar events, the processing-time for UI-events can be a bit longer, but 1 second is pushing it. When you get the ANR, it means that your UI-event processing took waaaaaaaaaaay too long. The goal is to make the UI experience as pleasant as possible. Even if you don't get an ANR, your UI experience may already appear to be slow. On Oct 21, 9:41 am, lbcoder <[email protected]> wrote: > ANR means that you have something holding up the UI thread for longer > than the specified time. > > For example; > You have a button on the screen. The button runs a network request > that takes 30 seconds to process. This network request is within the > same thread as the button, so the button's click listener doesn't > return control to the UI thread for a long time. ANR. To fix this, > have the button start a new THREAD and run the network request from > within this thread, that way the button returns immediately and the UI > thread continues to function while the long process happens in the > background. > > IN GENERAL, anything that can potentially take a "long time" (such as > networking or data processing) should be done in a new thread. > > On Oct 21, 2:06 am, Manohar Mahapatra <[email protected]> wrote: > > > > > Hi , > > > I am interested to know the nitty gritty of ANR dialogs and How to analyse > > ANRs with the info I get , A typical ANR looks like this( see below) but I > > cant figure out much Info from this . > > Also I want to know what info should I look for in /data/anr/traces.txt to > > compliment my analysis of such a log and pin point the root cause . > > I want to know what these the parameters in RED mean > > > 01-01 01:43:05.313: WARN/WindowManager(1834): Key dispatching timed out > > sending to > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > 01-01 01:43:05.318: WARN/WindowManager(1834): *Dispatch state*: > > {{KeyEvent{action=1 > > code=4 repeat=0 meta=0 scancode=212 mFlags=8} to Window{435c7df8 > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > paused=false} @ 1104543391080 lw=Window{435c7df8 > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > paused=false} lb=android.os.binderpr...@43502ae0 fin=false gfw=true ed=true > > tts=0 wf=false fp=false mcf=Window{4355bf08 > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > paused=false}}} > > 01-01 01:43:05.323: WARN/WindowManager(1834):* Current state*: {{null to > > Window{4355bf08 > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > paused=false} @ 1104543785321 lw=Window{4355bf08 > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > paused=false} lb=android.os.binderpr...@43539ea8 fin=false gfw=true ed=true > > tts=0 wf=false fp=false mcf=Window{4355bf08 > > com.android.settings/com.android.settings.bluetooth.BluetoothSettings > > paused=false}}} > > 01-01 01:43:05.438: INFO/ActivityManager(1834): ANR (application not > > responding) in process: com.android.settings > > 01-01 01:43:05.438: INFO/ActivityManager(1834): Annotation: > > keyDispatchingTimedOut > > 01-01 01:43:05.438: INFO/ActivityManager(1834): CPU usage: > > 01-01 01:43:05.438: INFO/ActivityManager(1834): Load: 0.46 / 1.05 / 1.26 > > 01-01 01:43:05.438: INFO/ActivityManager(1834): CPU usage from 5421ms to > > 94ms ago: > > 01-01 01:43:05.438: INFO/ActivityManager(1834): system_server: 5% = 3% > > user + 2% kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): qt5480_work_que: 1% = 0% > > user + 1% kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): events/0: 0% = 0% user + > > 0% kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): akmd2: 0% = 0% user + 0% > > kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): btld: 0% = 0% user + 0% > > kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): com.android.phone: 0% = 0% > > user + 0% kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): drexe: 0% = 0% user + 0% > > kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): com.wssyncmlnps: 0% = 0% > > user + 0% kernel > > 01-01 01:43:05.438: INFO/ActivityManager(1834): TOTAL: 7% = 3% user + 3% > > kernel > > 01-01 01:43:05.443: INFO/ActivityManager(1834): Removing old ANR trace file > > from /data/anr/traces > > > I did go through the > > *http://developer.android.com/guide/practices/design/responsiveness.html* > > but that gives a very good head start , I request if anybody has documented > > more on the ANR analysis / case studies , please share the link/blog . > > > I wanted to know what causes the WindowManager/ActivityManager to trigger an > > ANR. I want to understand from a Design/Code perspective as how ANR dilaog > > is formed. > > > Thanks > > AndUzer- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
