If you define an internal handler class in activity, the following code:
public class MainActivity extends Activity { private Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { //TODO handle message... } }; @TargetApi(11) @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mHandler.sendMessageDelayed(Message.obtain(), 60000); //just finish this activity finish(); }}
Then run the android lint tool with a memory leak warning:
This Handler class should be static or leaks might occur (com.example.ta.MainActivity.1)Issue: Ensures that Handler classes do not hold on to a reference to an outer classId: HandlerLeakIn Android, Handler classes should be static or leaks might occur. Messages enqueued on the application thread’s MessageQueue also retain their target Handler. If the Handler is an inner class, its outer class will 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 reason is:
- When the Android Application Starts, A logoff object of the main application thread will be created first. logoff implements a simple message queue to process the message objects one by one. The logoff object of the main thread exists throughout the application lifecycle.
- When handler is initialized in the main thread, the handler is associated with the logoff message queue. The message sent to the Message Queue references the handler object that sends the message, so that the system can call handler # handlemessage (Message) to distribute and process the message.
- In Java, non-static (anonymous) Internal classes reference external class objects. Static internal classes do not reference external class objects.
- If the external class is activity, it will cause activity leakage.
After the activity is finished, the delayed message will continue to exist in the main thread message queue for one minute, and then process the message. The message references the handler object of the activity, and then the handler references the activity. These referenced objects are retained until the message is processed. As a result, the activity object cannot be recycled, leading to activity leakage.
To modify this issue, you only need to define the handler class as static as prompted by lint, and then use weakreference to keep external activity objects.
private Handler mHandler = new MyHandler(this);private static class MyHandler extends Handler{ private final WeakReference<Activity> mActivity; public MyHandler(Activity activity) { mActivity = new WeakReference<Activity>(activity); } @Override public void handleMessage(Message msg) { System.out.println(msg); if(mActivity.get() == null) { return; } }}
Therefore, when you use an internal class in an activity, you must always consider whether you can control the lifecycle of the internal class. If not, you 'd better define it as a static internal class.
Original: http://blog.chengyunfeng.com /? P = 468
[Switch] internal handler class causes memory leakage