Thank you very much for the reply! After reading what Fadden said
weeks ago, I happily converted my static inner handler classes to non-
Just recently, I was browsing the source code of Handler and came
across this bit of internal Android debugging:
* Set this flag to true to detect anonymous, local or member
* that extend this Handler class and that are not static. These
* of classes can potentially create leaks.
private static final boolean FIND_POTENTIAL_LEAKS = false;
There is some code further down that uses reflection to locate such
subclasses if this flag is true.
My handlers fall into the category of non-static member classes, so I
am curious how such classes could cause a memory leak. My initial
thinking was that handlers could perhaps accumulate in a collection
associated with the MessageQueue. But handlers are never placed into
collections, as far as I can tell. The reference to the handler is in
the message. Clever! (And in any case if the memory leak is due to an
ever-growing collection of handlers somewhere then that has nothing to
do with whether or not the handler class is static or not.)
Just wondering if someone can shed some light on this comment in the
Android source code.
On Mar 10, 4:08 pm, fadden <fad...@android.com
> On Mar 9, 7:17 pm, Greg Krimer <gkri...@gmail.com
> > I have been finding it convenient to extend Handler in many of my
> > activities to handle messages specific to the activity. The handler
> > sublass is an inner class of the activity and needs to access its
> > state. I am wondering if there is any performance difference between
> > making the handler subclassstaticand passing in the activity
> > explicitly in its constructor or making the subclass an "instance
> > class" and letting the vm worry about my accessing members of the
> > containing activity.
> There's no real difference between explicitly and implicitly passing
> the outer-class reference around. Your example above is essentially
> doing what javac does automatically.
> Staticinner classes have some useful properties, e.g. you know