Android / Java - Memory leaks (April 2018)
By: Dennis Lang - Dec 2017

The following is a custom layout which has several circular references. By breaking these in the destroy LIFE state onDetachFromWindow() method the object memory leaks are reduced.

// Example custom layout which implements onDetachFromWindow() 
// to avoid oject (memory) leaks.
// 
// Example has Listener (callbacks) and Containers (ArrayList) which
// hold Anonymous classes causing circular references. 
// 
// Class also has a Handler which may have pending messages.
//

public class LeakLayout extends FrameLayout {

    OnClickListener mClickListener;
    
    private final List<SwipeListener> mSwipeListeners = new ArrayList<>();
    private final Map<View, Rect> mViewBoundCache = new HashMap<>();

    private final Handler mHandler = new Handler();
    public final int MSG_SWIPE_LEFT = 1;
    public final int MSG_SWIPE_RIGHT = 2;
    
    public interface SwipeListener {
        void onOpen(LeakLayout layout);
        void onClose(LeakLayout layout);
    }

    public LeakLayout(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    @Override
    public void setOnClickListener(OnClickListener listener) {
        // Store listener in parent and in our private container.
        // Note - clear both in destroy LIFE state to avoid leaks.
        
        super.setOnClickListener(listener);
        mClickListener = listener;
    }
    
    public void addSwipeListener(SwipeListener listener) {
        // Note - clear container in destroy LIFE state to avoid leaks.
        
        mSwipeListeners.add(listener);
    }
    
    public void postMessage(int what, int when) {
        // Note - any pending messages will need to be removed
        // in destroy LIFE state to avoid leaks.
        mHandler.obtainMessage(what, when).sendToTarget();
    }
    
    /**
     * Get children's bounds.
     */
    private void captureChildrenBound() {
        for (int idx = 0; idx < getChildCount(); idx++) {
            View child = getChildAt(idx);
            mViewBoundCache.put(child, child.getClipBounds());
        }
    }

    @Override
    protected void onAttachedToWindow() {
        super.onAttachedToWindow();
        
        // Create anonymous classes - creating circular references to parent.
        
        if (mClickListener == null) {
            setOnClickListener(new OnClickListener() {
                @Override
                public void onClick(View v) {
                    // performAdapterViewItemClick();
                }
            });
        }
    
    }

    @Override
    protected void onDetachedFromWindow() {
        // Destroy LIFE state - avoid memory leaks by:
        //  1. Remove all pending messages or runnables (always do first)
        //  2. Clear callbacks: unregister or set callbacks to null
        //     ** Depending on case, this may be redundant with step#3
        //  3. Set all objects with extra memory references to null.
        //     Setting to null may be enough to break multiple refs, making step#2 optional.
        //  4. Callup to super

        mHandler.removeMessages(MSG_SWIPE_LEFT);
        mHandler.removeMessages(MSG_SWIPE_RIGHT);
        
        setOnClickListener(null);
        setOnLongClickListener(null);
        
        mSwipeListeners.clear();
        mViewBoundCache.clear();

        super.onDetachedFromWindow();
    }
}
        

General Notes

If an object has an array of listener callbacks and the object is held by multiple users, you may have to remove ALL of the listener callbacks. But if the object is only held by one object, only that object has a reference, so you either need to remove its associated listener callback OR set the object to null inside the object.

// Owner creates circular reference when addChild is called.
class Owner {
    Child mChild;
    
    public void addChild(Child child) {
        mChild = child;
        mChild.addOnClickListener(new View.OnClickListener() {
            @Override public void onClick(View v) {
                // do something special
            }
        });
    }
}

// Worker creates a one-to-many circular reference.
class Worker {
    Child mChild = new Child();
    List<Owner> owners = new ArrayList();

    public void addOwners(Owner owner) {
        owners.add(owner);
        owner.addChild(mChild);
    }
}
    

In the above case every Owner instance has a pointer to a Child object which in turn has a clickListener which has a pointer to the Owner (anonymous class has pointer to outer class). Assuming addOnClickListener is storing the listeners in a list we have a single Child instance which is causing every Owner instantance to leak until the circular references are broken.

To free the memory either remove listener from every Owner or clear the Child in every Owner. Assuming the Child view object is also in a layout, clearing the Child from the Owner will not release the memory until the Child is released from its parent layout. The first solution will allow immediate release of the Owner objects once Worker clears its list or goes out of scope.

// Updated - to provide ways to cleanup and avoid leaks.

// Owner creates circular reference when addChild is called.
class Owner {
    Child mChild;
    View.OnClickListener mListener;  // Save listener to use in remove
    
    public void addChild(Child child) {
        mChild = child;
        mListener = new View.OnClickListener() {
            @Override public void onClick(View v) {
                // do something special
            }
        });
        mChild.addOnClickListener(mListener);
    }
    
    // Required for cleanup option #2
    public void removeChild() {
        mChild = null;
    }
    
    // Required for cleanup option #3, use previously saved listener
    public void removeListener() {
        mChild.removeOnClickListener(mListener);
    }
}
class Worker {
    Child mChild = new Child();
    List<Owner> owners = new ArrayList();

    public void addOwners(Owner owner) {
        owners.add(owner);
        owner.addChild(mChild);
    }
    
    public void onDestroy() {
        // or option #1  (if a remove All is available)
        mChild.removeAllListeners();
        
        // or option #2, remove child from Owners
        // Memory not freed until Child view also released from parent layout.
        for (Owner owner : owners) {
            owner.rmoveChild();
        }
        
        // or option #3
        for (Owner owner : owners) {
            owner.removeListener();
        }
    }
}
    

1. Use a static inner or external class as Listener to Child. The anonymous class is causing the circular reference so a static class will avoid this unless you add a variable in the static class which points to the parent.
2. Remove a local copy of Child from Owner. This is only leak-free if there are no other circular references. If the Child view object is in a layout and the layout is held in a variable by the owner, you are back to a circular reference.

   
   // Owner does not hold a copy of Child to avoid circular reference.
   class Owner {
       public void addChild(Child child) {
           child.addOnClickListener(new View.OnClickListener() {
               @Override public void onClick(View v) {
                   // do something special
               }
           });
       }
   }
   

Don't chain calls to LIFE cycle methods

For example, if you customize a Layout and you have some member View objects which are also stored in the Layout. You can set your member view objects to null but don't call onDetachFromWindow() on them because the Android LIFE cycle will perform the same task. Double calling these methods can create side effects.

@Override
protected void onDetachedFromWindow() {
    // Chaining LIFE cycle into children is NOT recommended. 
    mCustomView.onDetachedFromWindow();

    // Clearing Listener (callbacks) is recommend.
    mCustomView.setOnClickListenern(null);

    // Setting complex objects to null is recommend.
    mCustomView = null;

    // Callup up to super is mandatory. 
    super.onDetachedFromWindow();
}
        

Avoid pending or delayed Messages or Runnables

On a Handler you have to remove the messages by object instance or by what value. Handler removeMessage(int what). You can use remove CallbacksAndMessages(null) to remove pending anonymous Runnables.

void update() {
    // Example of delayed messange and post
    mUIHandler.sendEmptyMessageDelayed(MSG_ON_ITEM_CHANGED, ON_ITEM_CHANGED_DELAY);
    
    mRecyclerView.postDelayed(new Runnable() {
            @Override
            public void run() {
                mRecyclerView.smoothScrollToPosition(position);
            }
        }, 200);
}

@Override
protected void onDetachedFromWindow() {
    // Example of cleanup
    mUIHandler.removeMessages(MSG_ON_ITEM_CHANGED);
    
    // Remove pending anonymous Runnables.
    mUIHandler.removeCallbacksAndMessages(null);
        
    mRecyclerView.cancelPendingInputEvents();
    mRecyclerView = null;
}
    

Avoid private Handlers

See also:

• Android Handler Internals by Jag Suand
• Android source code for Handler class

Pair construction with destruction

void init() {
    // Creation - 
    //   1. Setup click on button
    //   2. Add Listener to media player.
    
    mButton1 = findViewById(R.id.at_button1);
    mButton1.setOnClickListener(new View.OnClickListener() {
        @Override public void onClick(View v) {
            // do something special
        }
    });
    mMediaPlayer = new ExoMediaPlayer(RendererBuilderFactory.createRendererBuilder(getContext(), new Media(mUri), true), mUri);
    mMediaPlayer.addListener(playerListener);
}

@Override
protected void onDetachedFromWindow() {
    // Example of cleanup, reverse construction
    //   1. Clear anonymous click listener
    //   2. Remove Media Player listener
    
    mButton1.setOnClickListener(null);
    
    mMediaPlayer.removeListener(playerListener);
    mMediaPlayer.release();
    mMediaPlayer = null;
}
    

ViewTreeObserver listeners are hard to clear

• ViewTreeObserver.removeGlobalOnLayoutListener(listener)

1. Create object which has ViewTreeObserver
2. Add listener (goes in 2nd list)
3. ViewTreeObserver performs action on list, calls start() causing 2nd list to replace main list.
4. Remove listener (2nd list created and remove executed on 2nd list, primary list still holds listener being removed)
5. View object is nolong used resulting in possible memory leak if listener has anonymous class or non-static inner class.

// Example ViewTreeObserver leaking listener
HorizontalScrollView mScrollView;
    
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    mFragmentView = inflater.inflate(R.layout.fragment, container, false);
    mScrollView = (HorizontalScrollView)mFragmentView.findViewById(R.id.console_card_list_horz);

    mScrollView.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // Do something...
        }
    });

// Example trying to avoid memory leak by removing listener (still leaks due to flaw in ViewTreeObserver)
HorizontalScrollView mScrollView;
ViewTreeObserver.OnGlobalLayoutListener mGlobalListener;
    
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    mFragmentView = inflater.inflate(R.layout.fragment, container, false);
    mScrollView = (HorizontalScrollView)mFragmentView.findViewById(R.id.console_card_list_horz);

    mGlobalListener = new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // Do something...
        }
    };
    mScrollView.getViewTreeObserver().addOnGlobalLayoutListener(mGlobalListener);
    
     
@Override
public void onDestroyView() {
    // Still leaks because of flaw in Android with latency on releasing listener.
    
    mScrollView.getViewTreeObserver().removeOnGlobalLayoutListener(mGlobalListener);
}                

The above leaks due to the internal flaw in ViewTreeObserver and the only fix is to call the appropriate dispatch method for your listener to cause the internal lists to update.

// Example which does not leak ViewTreeObserver listener.
@Override
public void onDestroyView() {
    // Leaks because of flaw in Android with latency on releasing listener.
    mScrollView.getViewTreeObserver().removeOnGlobalLayoutListener(mGlobalListener);
    
    // Force internal custom concurrent list to switch to new list and free listener.
    // Listener is now gone, breaking circular reference, avoiding memory leak.
    mScrollView.getViewTreeObserver().dispatchOnGlobalLayout();
}   

//
//  Code extracted from ViewTreeObserver API 25 
//  ** Custom concurrent CopyOnWriteArray with two lists **
//

/**
 * Copy on write array. This array is not thread safe, and only one loop can
 * iterate over this array at any given time. This class avoids allocations
 * until a concurrent modification happens.
 *
 * Usage:
 *
 * CopyOnWriteArray.Access<MyData> access = array.start();
 * try {
 *     for (int i = 0; i < access.size(); i++) {
 *         MyData d = access.get(i);
 *     }
 * } finally {
 *     access.end();
 * }
 */
static class CopyOnWriteArray<T> {
    private ArrayList<T> mData = new ArrayList<T>();
    private ArrayList<T> mDataCopy;    // <--- Latency due to this 2nd list

    private final Access<T> mAccess = new Access<T>();

    private boolean mStart;

    static class Access<T> {
        private ArrayList<T> mData;
        private int mSize;

        T get(int index) {
            return mData.get(index);
        }

        int size() {
            return mSize;
        }
    }

    CopyOnWriteArray() {
    }

    private ArrayList<T> getArray() {
        if (mStart) {
            if (mDataCopy == null) mDataCopy = new ArrayList<T>(mData);
            return mDataCopy;
        }
        return mData;
    }

    // Replace active list with the temporary list. 
    Access<T> start() {
        if (mStart) throw new IllegalStateException("Iteration already started");
        mStart = true;
        mDataCopy = null;
        mAccess.mData = mData;
        mAccess.mSize = mData.size();
        return mAccess;
    }

    void end() {
        if (!mStart) throw new IllegalStateException("Iteration not started");
        mStart = false;
        if (mDataCopy != null) {
            mData = mDataCopy;
            mAccess.mData.clear();
            mAccess.mSize = 0;
        }
        mDataCopy = null;
    }

    int size() {
        return getArray().size();
    }

    // Create temporary list from active list, perform add on temporary list.
    void add(T item) {
        getArray().add(item);
    }

    // Create temporary list from active list, perform add on temporary list.
    void addAll(CopyOnWriteArray<T> array) {
        getArray().addAll(array.mData);
    }

    // Create temporary list from active list, perform remove on temporary list.
    void remove(T item) {
        getArray().remove(item);
    }

    void clear() {
        getArray().clear();
    }
}

// -----------------------------------------------------------------------------------------
// Code fragment of ViewTreeObserver 
class  ViewTreeObserver {

    // Non-recursive listeners use CopyOnWriteArray
    // Any listener invoked from ViewRootImpl.performTraversals() should not be recursive
    private CopyOnWriteArray<OnGlobalLayoutListener> mOnGlobalLayoutListeners;

    private boolean mAlive = true;

    /**
     * Register a callback to be invoked when the global layout state or the visibility of views
     * within the view tree changes
     *
     * @param listener The callback to add
     *
     * @throws IllegalStateException If {@link #isAlive()} returns false
     */
    public void addOnGlobalLayoutListener(OnGlobalLayoutListener listener) {
        // checkIsAlive();

        if (mOnGlobalLayoutListeners == null) {
            mOnGlobalLayoutListeners = new CopyOnWriteArray<OnGlobalLayoutListener>();
        }

        mOnGlobalLayoutListeners.add(listener);     // <--- listener added to temporary internal list.
    }

    /**
     * Remove a previously installed global layout callback
     *
     * @param victim The callback to remove
     *
     * @throws IllegalStateException If {@link #isAlive()} returns false
     *
     * @see #addOnGlobalLayoutListener(OnGlobalLayoutListener)
     */
    public void removeOnGlobalLayoutListener(OnGlobalLayoutListener victim) {
        // checkIsAlive();
        if (mOnGlobalLayoutListeners == null) {
            return;
        }
        mOnGlobalLayoutListeners.remove(victim);    // <--- listener removed from temporary internal list only.
    }

    /**
     * Notifies registered listeners that a global layout happened. This can be called
     * manually if you are forcing a layout on a View or a hierarchy of Views that are
     * not attached to a Window or in the GONE state.
     */
    public final void dispatchOnGlobalLayout() {
        // NOTE: because of the use of CopyOnWriteArrayList, we *must* use an iterator to
        // perform the dispatching. The iterator is a safe guard against listeners that
        // could mutate the list by calling the various add/remove methods. This prevents
        // the array from being modified while we iterate it.
        final CopyOnWriteArray<OnGlobalLayoutListener> listeners = mOnGlobalLayoutListeners;
        if (listeners != null && listeners.size() > 0) {
            CopyOnWriteArray.Access<OnGlobalLayoutListener> access = listeners.start(); // <--- use temporary list. 
            try {
                int count = access.size();
                for (int i = 0; i < count; i++) {
                    access.get(i).onGlobalLayout();
                }
            } finally {
                listeners.end();
            }
        }
    }

}

Threads and AsyncTasks

// Example of possible leaking thread if it never completes
// or runs longer then you expect. 

ImageView imageView = (ImageView)parent.findViewById(R.id.image1);
String image_url = "http//www.gotimages.com/nice.jpg"
new Thread(new Runnable() 
{
    @Override
    public void run() {
        try {
            final Bitmap bitmap = BitmapFactory.decodeStream((InputStream) new URL(image_url).getContent());
            imageView.post(new Runnable() {
                @Override
                public void run() {
                   imageView.setImageBitmap(bitmap);
                }   
            }); 
        } catch (Exception ex)  {
            // TODO: handle exception
        }
    }
}).start();
    

// AVOID leaking thread by keeping hold of thread in a variable, 
// so you can stop execution and cleanup.

void update() {
    ImageView imageView = (ImageView)parent.findViewById(R.id.image1);
    String image_url = "http//www.gotimages.com/nice.jpg"
    mWorkerThread = new Thread(new Runnable() 
    {
        @Override
        public void run() {
            try {
                final Bitmap bitmap = BitmapFactory.decodeStream((InputStream) new URL(image_url).getContent());
                imageView.post(new Runnable() {
                    @Override
                    public void run() {
                       imageView.setImageBitmap(bitmap);
                    }   
                }); 
            } catch (Exception ex)  {
                // TODO: handle exception
            }
        }
    });
    mWorkerThread.start();
}

@Override
protected void onDetachedFromWindow() {
    mImageView.cancelPendingInputEvents();
    mWorkerThread.interrupt();
    mWorkerThread = null;
    mImageView = null;
}

    

Switching threads - can occur after object is destroyed

How to find memory leaks

I used the built-in memory monitor in Android Studio to visualize the active allocate memory heap and the Heap Profiler view to see the outstanding active object counts and size. Once I found and fixed a leak I used dumpsys meminfo <package name> to capture a memory report before (with the leak) and after (leak removed) to verify the changes.

Dumpsys MemInfo is a nice way to get a summary of the current state of memory resources in your package.

    Syntax:
    adb shell dumpsys meminfo <package-name> > save-results.txt

    Example:
    adb shell dumpsys meminfo com.wmur.android.weather  > wmur.txt
    
    On Unix/Linix/OSX you can continuously monitor using the 'watch' command:
    watch "adb shell dumpsys meminfo com.wmur.android.weather"
    
    A DOS/Windows version of watch can be found here:
    llwatch
    

Sample reported generated from dumpsys meminfo.
The key spots I monitor are the Native Heap Alloc, Java Heap summary and Views count.

Applications Memory Usage (kB):
Uptime: 99778973 Realtime: 780584992

** MEMINFO in pid 24644 [com.wmur.android.weather] **
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap    28618    28572        0        0    46336    40903     5432
  Dalvik Heap    22969    22896        0        0    41688    27812    13876
 Dalvik Other     2752     2752        0        0                           
        Stack     1440     1440        0        0                           
       Ashmem     1060     1016        0        0                           
      Gfx dev    22688    20776        0        0                           
    Other dev       12        0       12        0                           
     .so mmap    19402      284    12196        0                           
    .apk mmap     2177        0     1716        0                           
    .ttf mmap      251        0      216        0                           
    .dex mmap    21717       32    18296        0                           
    .oat mmap     2948        0     1224        0                           
    .art mmap     1895     1344      292        0                           
   Other mmap      878       16      444        0                           
   EGL mtrack    45520    45520        0        0                           
      Unknown    10940    10940        0        0                           
        TOTAL   185267   135588    34396        0    88024    68715    19308
 
 App Summary
                       Pss(KB)
                        ------
           Java Heap:    24532
         Native Heap:    28572
                Code:    33964
               Stack:     1440
            Graphics:    66296
       Private Other:    15180
              System:    15283
 
               TOTAL:   185267      TOTAL SWAP (KB):        0
 
 Objects
               Views:      316         ViewRootImpl:        1
         AppContexts:        6           Activities:        1
              Assets:        7        AssetManagers:        5
       Local Binders:       64        Proxy Binders:       37
       Parcel memory:       42         Parcel count:      172
    Death Recipients:        5      OpenSSL Sockets:        7
 
    

Using egrep (enhance grep, or grep with -E) you can limit the output of meminfo to the key parts.

    adb shell dumpsys meminfo com.wmur.android.weather | egrep '(Heap|Views)'
    
    
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
  Native Heap    28594    28548        0        0    47872    40205     7666
  Dalvik Heap    29137    29064        0        0    43954    38224     5730
           Java Heap:    30700
         Native Heap:    28548
               Views:      316         ViewRootImpl:        1
    

List of Android Memory Tools:

• Investigating Your RAM Usage
• Heap Profiler Memory Allocation Tracker
• Eclipse Memory Analyzer (MAT)