Analyzing and Fixing Memory Leaks in Android DialogFragment

DialogFragment, introduced after Android 3.0, is recommended by Google to replace Dialog or AlertDialog because it better manages the dialog lifecycle and can be reused.

During usage, developers often attach listeners to the dismiss event of DialogFragment. LeakCanary frequently reports memory leaks caused by references retained in HandlerThread messages. The leak chain usually involves third‑party libraries (e.g., RxJava or AMap) that create their own HandlerThreads, not the main UI thread.

The core issue is that DialogFragment registers DialogInterface.OnCancelListener and DialogInterface.OnDismissListener in onActivityCreated . These listeners store a Message object (mDismissMessage) obtained from a handler pool. When the dialog is dismissed, a new message is obtained from the pool and sent to the target, potentially reusing a message that is still referenced by a blocked HandlerThread.

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    mDialog.setOnCancelListener(this);
    mDialog.setOnDismissListener(this);
}

The setOnDismissListener method creates mDismissMessage via mListenersHandler.obtainMessage(DISMISS, listener) . Message.obtain pulls a Message from a static pool, so the same Message instance can be reused across threads.

public static Message obtain(Handler h, int what, Object obj) {
    Message m = obtain();
    m.target = h;
    m.what = what;
    m.obj = obj;
    return m;
}

public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            m.flags = 0;
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

When the dialog is dismissed, sendDismissMessage() obtains a new Message from the pool and posts it. If the pool returns a Message that is still held by a blocked HandlerThread, the Message’s obj field still references the DialogFragment, preventing its garbage collection.

private void sendDismissMessage() {
    if (mDismissMessage != null) {
        Message.obtain(mDismissMessage).sendToTarget();
    }
}

Thus the leak originates from third‑party HandlerThreads retaining recycled Message objects that still point to the DialogFragment.

Solutions

LeakCanary suggests keeping the third‑party message queue non‑empty by continuously sending empty messages, but this requires prior knowledge of the offending library and wastes thread resources.

If dismiss and cancel listeners are not needed, avoid using DialogFragment altogether and extend Dialog directly.

Set the listeners to null in onActivityCreated . However, the superclass still registers the listeners, so the leak can persist.

Replace the strong listener references with WeakReference . By wrapping the fragment in a weak reference inside custom listener classes, the GC can reclaim the fragment even if the Message remains.

Example of a custom weak‑reference listener implementation:

public static class DialogDismissListener implements DialogInterface.OnDismissListener {
    private WeakReference
ref;
    public DialogDismissListener(LeakDialogFragment fragment) {
        ref = new WeakReference<>(fragment);
    }
    @Override
    public void onDismiss(DialogInterface dialog) {
        LeakDialogFragment f = ref.get();
        if (f != null) {
            f.onDismissDialog(dialog);
        }
    }
}

public static class DialogCancelListener implements DialogInterface.OnCancelListener {
    private WeakReference
ref;
    public DialogCancelListener(LeakDialogFragment fragment) {
        ref = new WeakReference<>(fragment);
    }
    @Override
    public void onCancel(DialogInterface dialog) {
        LeakDialogFragment f = ref.get();
        if (f != null) {
            f.onCancelDialog(dialog);
        }
    }
}

In the fragment’s onActivityCreated , set these listeners and clear them in onDestroyView :

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    mDialogDismissListener = new DialogDismissListener(this);
    mDialog.setOnDismissListener(mDialogDismissListener);
    mDialogCancelListener = new DialogCancelListener(this);
    mDialog.setOnCancelListener(mDialogCancelListener);
}

@Override
public void onDestroyView() {
    super.onDestroyView();
    mDialogDismissListener = null;
    mDialogCancelListener = null;
}

By using weak references, the Message no longer prevents the DialogFragment from being reclaimed, eliminating the leak.

Conclusion

The article starts from a DialogFragment memory‑leak case, analyzes how the dismiss listener’s Message handling leads to retained references, and proposes practical fixes such as avoiding listeners, employing weak references, or creating a custom fragment that does not rely on the default strong listener registration.

Reference: https://medium.com/square-corner-blog/a-small-leak-will-sink-a-great-ship-efbae00f9a0f