LeakCanary: detect all memory leaks

Original text: LeakCanary: Detect all memory leaks!

 ava.lang.OutOfMemoryError
        at android.graphics.Bitmap.nativeCreate(Bitmap.java:- 2 )
        at android.graphics.Bitmap.createBitmap(Bitmap.java: 689 )
        at com.squareup.ui.SignView.createSignatureBitmap(SignView.java: 121 )

Nobody likes OutOfMemoryError

During Square's sign-up process, we draw a user's signature on a bitmap. This bitmap is the same size as the device's screen, and when creating it, I encountered a considerable number of OOM-related crashes.

We have tried several approaches, none of which solved our problem:

• Use Bitmap.Config.ALPHA_8 (the signature does not require color)

• Catch OutOfMemoryError, trigger garbage collection and retry a few times (inspired by GCUtils)

• We didn't consider allocating bitmaps outside of heap memory, as Fresco hadn't appeared yet.

The way we look at the problem is wrong

The size of the bitmap itself is not a problem. When the memory is almost full, OOM can happen at any time. It is especially likely to happen when creating large objects, such as bitmaps. OOM usually represents a deeper problem: memory leak.

What is a memory leak?

Some objects have a limited lifespan. When their job is done, they are garbage collected. If a series of references to an object are still being held when its lifespan should have ended, this can lead to a memory leak. As leaks accumulate, your app will run out of memory.

For example, after Activity.onDestroy() is called, the view tree and the associated bitmap should be garbage collected. If a running background thread continues to hold a reference to the Activity, the associated memory will not be reclaimed, which will eventually lead to an OutOfMemoryError crash.

Finding memory leaks

Finding memory leaks is a manual process that is well described in the Wrangling Dalvik series by Raizlabs.

Here are the key steps:

1. Learn about OOM via Bugsnag, Crashlytics, or Developer Console

2. Actively reproduce the problem. You may need to buy, borrow or steal a special device that is experiencing the crash (not all devices will have a memory leak!). You also need to figure out what chain of events caused the memory leak.

3. Dump the heap when OOM occurs (here's how to do it).

4. Use MAT or YourKit memory detection tools to detect memory changes and find out which objects should be garbage collected;

5. Infer the shortest strong reference path from that object to GC roots;

6. Find non-existent references in the path and fix the memory leak;

It would be nice if there was a library that could do all that for you, allowing you to focus on fixing memory leaks.

Introduction to LeakCanary

LeakCanary is an open source Java library for detecting memory leaks in debug versions.

Let's look at an example of cait:

 class Cat {
 }
 class Box {
 Cat hiddenCat;
 }
 class Docker {
 static Box container;
 } 
  
 // ...   
  
 Box box = new Box();
 Cat schrodingerCat = new Cat();
 box.hiddenCat = schrodingerCat;
 Docker.container = box;

Create a RefWatcher instance and give it an object to watch:

 // We expect schrodingerCat to be gone soon (or not), let's watch it.  
 refWatcher.watch(schrodingerCat);

When a leak is detected, you automatically get a nice leak clue:

 * GC ROOT static Docker.container
 * references Box.hiddenCat
 * leaks Cat instance

We know your time is valuable, so we made it very easy to set up. With just a few lines of code, LeakCanary can automatically detect leaks in your Activity:

public   class ExampleApplication extends Application {
 @Override   public   void onCreate() {
 super .onCreate();
    LeakCanary.install( this );
 }
 }

When memory is low, there will be a notification and a nice display interface:

in conclusion

After enabling LeakCanary, we found and fixed many memory leaks. We even found some leaks in the Android SDK.

The results are pretty amazing, we now have a 94% reduction in OOM crashes.

If you want to put an end to OOM crashes, install LeakCanary now!