While my inner classes could be wrong, I have a bigger suspect. It seems one of my custom views has a background thread that waits for work requests and communicates back through a handler. When the activity ends and restarts, the thread is still alive, waiting for a work request. Since that thread references a Handler, which references a View which has a context, so the activity stays alive even as a new one is created.
I believe what I should do is in MyActvity.OnDestroy, propagate the message down the chain such that the worker thread exists gracefully. I suppose I should also make it a daemon thread - since it is one, but that will only help when the process exits and not when there are other activities or services running. Nathan On Jun 17, 8:43 pm, Nathan <[email protected]> wrote: > Since I seem to have caught two activity references in a heapdump, > where the Activity is set to singleTask. > > Romain's advice on avoiding memory leaks includes: > > "Avoid non-static inner classes in an activity if you don't control > their life cycle, use a static inner class and make a weak reference > to the activity inside" > > What does this mean exactly? I can't find any examples, positive, or > negative for this rule. > > I do have some non static inner classes in my activity. > > Most of them are anonymous inner classes like this one. I see hundreds > of them in the samples: > > button.setOnClickListener(new Button.OnClickListener() { > public void onClick(View v) { > progressHorizontal.incrementSecondaryProgressBy(-1); > // Title progress is in range 0..10000 > setSecondaryProgress(100 * > progressHorizontal.getSecondaryProgress()); > } > }); > > Are anonymous inner classes okay? > > I also see something like this in the samples: > > private OnClickListener mStopRepeatingListener = new > OnClickListener() { . . . > > Are member variables points to a non static anonymous inner class > okay? I might think so because a member variable's lifecycle is > controlled by the activity's lifecycle. > > Or do I assume that all the API samples leak a lot of contexts? > > Thanks for any insights > > Nathan -- You received this message because you are subscribed to the Google Groups "Android Developers" 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-developers?hl=en
