Consider the following code:
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
}
}
While not readily obvious, this code can cause cause a massive memory leak. Android Lint will give the following warning:
In Android, Handler classes should be static or leaks might occur.
But where exactly is the leak and how might it happen? Let‘s determine the source of the problem by first documenting what we know:
- When an Android application first starts, the framework creates a Looperobject for the application‘s main thread. A Looper implements a simple message queue, processing Message objects in a loop one after another. All major application framework events (such as Activity lifecycle method calls, button clicks, etc.) are contained inside Message objects, which are added to the Looper‘s message queue and are processed one-by-one. The main thread‘sLooper exists throughout the application‘s lifecycle.
- When a Handler is instantiated on the main thread, it is associated with theLooper‘s message queue. Messages posted to the message queue will hold a reference to the Handler so that the framework can callHandler#handleMessage(Message) when the Looper eventually processes the message.
- In Java, non-static inner and anonymous classes hold an implicit reference to their outer class. Static inner classes, on the other hand, do not.
So where exactly is the memory leak? It‘s very subtle, but consider the following code as an example:
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mLeakyHandler.postDelayed(new Runnable() {
@Override
public void run() { /* ... */ }
}, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
When the activity is finished, the delayed message will continue to live in the main thread‘s message queue for 10 minutes before it is processed. The message holds a reference to the activity‘s Handler, and the Handler holds an implicit reference to its outer class (the SampleActivity, in this case). This reference will persist until the message is processed, thus preventing the activity context from being garbage collected and leaking all of the application‘s resources. Note that the same is true with the anonymous Runnable class on line 15. Non-static instances of anonymous classes hold an implicit reference to their outer class, so the context will be leaked.
To fix the problem, subclass the Handler in a new file or use a static inner class instead. Static inner classes do not hold an implicit reference to their outer class, so the activity will not be leaked. If you need to invoke the outer activity‘s methods from within the Handler, have the Handler hold a WeakReference to the activity so you don‘t accidentally leak a context. To fix the memory leak that occurs when we instantiate the anonymous Runnable class, we make the variable a static field of the class (since static instances of anonymous classes do not hold an implicit reference to their outer class):
public class SampleActivity extends Activity {
/**
* Instances of static inner classes do not hold an implicit
* reference to their outer class.
*/
private static class MyHandler extends Handler {
private final WeakReference<SampleActivity> mActivity;
public MyHandler(SampleActivity activity) {
mActivity = new WeakReference<SampleActivity>(activity);
}
@Override
public void handleMessage(Message msg) {
SampleActivity activity = mActivity.get();
if (activity != null) {
// ...
}
}
}
private final MyHandler mHandler = new MyHandler(this);
/**
* Instances of anonymous classes do not hold an implicit
* reference to their outer class when they are "static".
*/
private static final Runnable sRunnable = new Runnable() {
@Override
public void run() { /* ... */ }
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
The difference between static and non-static inner classes is subtle, but is something every Android developer should understand. What‘s the bottom line? Avoid using non-static inner classes in an activity if instances of the inner class could outlive the activity‘s lifecycle. Instead, prefer static inner classes and hold a weak reference to the activity inside.
PS:
Q:
I am a little confused between static variables and static nested classes. For example why is it bad to hold a static reference to a drawable but it is a good practice to have static nested classes that reference the activity?
Also in the above example, can we have mHandler as a static instance of the Handler class like the Runnable, instead of creating a static class extending Handler?
A:
The "static" keyword has different meanings when it comes to "static variables" vs. "static classes" in Java.
A static variable is a variable that belongs to all instances of a particular class. It will not be reclaimed by the GC when a particular instance of the class is garbage collected... it will stay in memory until you explicitly set it to null. The reason why it is bad to hold a static reference to a Drawable is because a Drawable usually holds a reference to a View and that View usually holds a reference to its parent Activity. As a result, the static Drawable will force the Activity to stay in memory even after the Activity is destroyed (unless you explicitly set the static Drawable to null, of course).
Static classes in Java don‘t really have the same meaning as static variables in Java. A static class declaration gives you a way to declare an inner class as if it was declared in a separate .java file... and that‘s pretty much it. A non-static inner class on the other hand is implicitly associated with its outer class... unlike static inner classes, an instance of a non-static inner class cannot exist without an instance of its outer class as well.
To answer your second question, declaring the mHandler as static would not have the same effect as the above sample code. Making the handler static means that it would be shared by all instances of the Activity (i.e. if you rotated the screen causing the Activity to be destroyed, the same Handler object would be used by the newly created Activity instance as well). In the sample code above, the Handler is declared as non-static which means that a new Handler will be created for each new Activity that is instantiated.
The Runnable
is static so a single instance will be allocated and will be shared across all Activity instances (a new one will not be created for each new Activity that is created). I explain why it is important for the Runnable
to be static in the second to last paragraph of the post.
How to Leak a Context: Handlers & Inner Classes