9

So I have a strange problem, and I'm not entirely sure what all information I should provide, but I'll do my best -- just let me know if I need to add more info. I'm having an issue that when I finish my Activity and return to the previous Activity (or launch it with a new Intent -- the problem seems to be centered on finishing the Activity) the UI performance drops drastically for about six or seven seconds, then returns to normal.

From LogCat, this warning appears consistently:

07-11 22:09:42.594: W/ActivityManager(292): Launch timeout has expired, giving up wake lock!
07-11 22:09:42.601: W/ActivityManager(292): Activity idle timeout for ActivityRecord{42bf6e00 com.kcoppock.sudokubeta/com.kcoppock.sudoku.SudokuBoardActivity}

As soon as the activity times out, UI performance returns to normal. Until that point it is very sluggish. I have no code that I am aware of that could be blocking the main thread, and I've even gone so far as to comment out my entire onPause() method to see if it makes any difference, and it does not.

The Activity does not spawn any background threads, does not perform any network activity, the only disk access it has is some accessing of SharedPreferences. The previous questions I've been able to locate are about idle timeouts for HistoryRecord, not ActivityRecord.

Any ideas what would cause this? Or how I could go about determining what is blocking the UI thread, if that is what is happening?

EDIT : Okay, just tried commenting out everything except super.onCreate() and setContentView() -- the problem still persists. It doesn't occur with any other Activities but this one, but there's NOTHING TO this one. :/

Kevin Coppock
  • 133,643
  • 45
  • 263
  • 274
  • Technically it is possible to block the UI thread w/ `SharedPreferences`, but I guess it's probably not as likely as a network access or something. Have you tried removing it somehow? – Alex Lockwood Jul 12 '12 at 04:09
  • @AlexLockwood Thanks for the idea. Just tried that; removed all references to any SharedPreferences, commented out my onPause() and onResume(), but no difference. – Kevin Coppock Jul 12 '12 at 04:25
  • kcoppock also see my question http://stackoverflow.com/questions/30053090/flash-toggle-button-crash-android – Zar E Ahmer May 05 '15 at 12:43

2 Answers2

12

Oh geez. One of those things that's pretty hard to diagnose outside of trial and error, but I've figured it out. For reference, should anyone else have this problem, it came down to a custom view in my layout. I had added a ViewTreeObserver.OnGlobalLayoutListener() to do some layout modifications after the layout pass, but within that listener I modified the layout and thus caused another layout, essentially creating an infinite loop (but somehow not causing an ANR). My solution was like so:

private class BoardLayoutListener implements OnGlobalLayoutListener {
    @Override
    public void onGlobalLayout() {
        //...do stuff here

        //REMOVE this listener so that you don't repeat this forever
        ViewTreeObserver obs = SudokuBoard.this.getViewTreeObserver();
        obs.removeGlobalOnLayoutListener(this);
    }
}

This solution is quite ironic, considering my second highest rated answer on StackOverflow specifically deals with this. :P

sigh

Community
  • 1
  • 1
Kevin Coppock
  • 133,643
  • 45
  • 263
  • 274
  • 8
    hahahah... don't worry, a few weeks ago I was reading answers on SO, and one of them was particularly enlightening so I went to upvote... turns out I answered the question 1.5 years ago and I didn't remember a thing :P – Alex Lockwood Jul 12 '12 at 14:25
  • 1
    Here's why there is no AnR : https://groups.google.com/forum/?fromgroups=#!topic/android-developers/TfkPlN5b-ig (Thank you Mother Dianne) – Reno Mar 29 '13 at 06:16
1

I've had the same issue today but as it turned out to have a different cause and solution I decided to add the information here just in case it might help someone else.
In my case problem was caused because I had the following line inside my onActivityResult() method:
android.os.Debug.waitForDebugger();
I Just deleted the line and the problem was gone. This line is usually used to synchronize the debugger with the OS threads but I just figured it shouldn't be used anywhere. Oddly the problem would not appear until I had my phone disconnected from the desktop.

Regards

ulix
  • 999
  • 9
  • 13