In Android, when using the handler, write as follows:
Private Handler Handler; @Overridepublic void OnCreate (Bundle savedinstancestate) {super.oncreate (savedinstancestate) ; handler = new Handler () {@Overridepublic void Handlemessage (Message msg) {//TODO auto-generated method Stubsuper.handlem Essage (msg);}}; Handler.sendmessagedelayed (Message.obtain (), 60000);//Just finish this activityfinish ();}
Then running the Android Lint tool will have a memory leak warning:
This Handler class should is static or leaks might occur (com.example.ta.mainactivity.1)
Issue:ensures that Handler classes does not hold on to a reference to an outer class
Id:handlerleak
In Android, Handler classes should is static or leaks might occur. Messages enqueued on the application thread ' s MessageQueue also retain their target Handler. If The Handler is a inner class, its outer class would be retained as well. To avoid leaking the outer class, declare the Handler as a static nested class with a weakreference to its outer class.
The reasons are:
When the Android app starts, it creates a Looper object that applies the main thread, and Looper implements a simple message queue, one for processing the message object inside. The main thread Looper object exists throughout the application life cycle.
When handler is initialized in the main thread, the handler and the Looper message queue are associated. A message sent to the queue of messages refers to the Handler object that sent the message, so that the system can call Handler#handlemessage (message) to distribute processing the message.
In Java, non-static (anonymous) inner classes refer to external class objects. Static inner classes do not reference external class objects.
If the external class is activity, it can cause activity disclosure.
When activity finishes, the deferred message continues to exist for 1 minutes in the main thread message queue and then processes the message. The message references the activity's handler object, and the handler references the activity. These reference objects persist until the message is processed, which prevents the activity object from being recycled, causing the activity disclosure described above.
To modify the problem, simply define the handler class as static by following the lint hint, and then keep the external activity object through WeakReference.
private static class Webviewhandler extends handler{public static final int what_pullrefreshcompleted = 1;private final We Akreference<webactivity> mactivity;public Webviewhandler (webactivity mactivity) {super (); this.mActivity = new Weakreference<webactivity> (mactivity);} @Overridepublic void Handlemessage (Message msg) {if (mactivity.get () = = null) Return;switch (msg.what) {case What_ Pullrefreshcompleted:if (Mactivity.get (). Getmpullrefreshwebview ()! = NULL)//Because the handler is static, So we call the method to get the Outer class Property Mactivity.get (). Getmpullrefreshwebview (). Refreshcomplete (); break; Super.handlemessage (msg);}}
therefore, when using internal classes in activity, it is necessary to always consider whether you can control the life cycle of the inner class, and if not, it is best to define it as a static inner class.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
This Handler class should is static or leaks might occur