I’m instantiating my Handler for the UI thread in one of my Activity’s onCreate() method. (To avoid memory leak risks, the Handler is not an inner class, it is a normal class.)
Since one Handler corresponds to one Thread, but one Thread can have more handlers (as far as I can see), each call to onCreate() will instantiate a new Handler instance. So if my activity is recreated
again (after onDestroy, but without any process kill in the meantime), onCreate() will add another Handler while the old one is not removed. (In Android source, the Handler only asks for the Thread’s Looper and obtains a reference to its message queue.)
What is the optimal solution? Shall I instantiate a Handler to a static variable, and then in onCreate(), I can check if it’s null or not. If it’s nonnull, then there is no need to instantiate a new one, right?
(Needless to say, in onDestroy(), I set the Activity reference in my Handler instance to NULL, so the Handler is not leaking the Activity or anything related — and my handler’s processing method checks if it’s null, and discards messages if needed. But my question is that the Handler is still kept for the thread for the reasons detailed in the previous paragraphs I guess, so the more onCreate calls, the more Handler instances attached to the UI thread. Is my static solution correct for
this? If it’s not crucial, then how does Android detect that a Handler associated with the current thread should be GC-d?)
The Handler isn’t referenced by the Thread, the Looper or anything else. The Handler is just a convenient way for you to put stuff in the Looper’s message queue.
If you instantiate a Handler in onCreate() and assign this to a member (instance) variable in your activity, when your activity is garbage-collected the Handler will also be garbage-collected because there is nothing that references it.
So creating Handler objects in onCreate() won’t cause any memory leaks.