Introduction to LeakCanary, a Java memory leak detection library, understand?

LeakCanary: A memory leak detection library for Android and Java.

java.lang.<a href="http://javakk.com/tag/outofmemoryerror" title="查看更多关于 OutOfMemoryError 的文章" target="_blank">OutOfMemoryError</a>
        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)

No one likes **OutOfMemoryError** crash

In the square register, we draw the client's signature on the bitmap cache. This bitmap is the size of the device's screen, and a lot of out of memory (OOM) crashes occurred when we created it.

We tried several methods, but none of them solved the problem:

• Use Bitmap.Config.ALPHA_8 (signature does not require color).
• Catch OutOfMemoryError, trigger GC and retry several times (inspired by GCUtils).
• We have not thought about allocating bitmaps from the Java heap. We are not lucky yet.

We got it wrong

Bitmap size is not a problem. When the memory is almost full, OOM can happen anywhere. This situation is more likely to happen where large objects (such as bitmaps) are created. OOM is a symptom of a deeper problem: **memory leak**.

What is a memory leak?

Some objects have a limited lifespan. When their work is completed, they will be garbage collected. If a reference chain saves an object in memory after its expected lifetime ends, this will cause a memory leak. When these vulnerabilities accumulate, the memory of the application will be exhausted.

For example, when Activity.onDestroy() is called, its view hierarchy and its associated bitmap should be garbage-collectable. If a thread running in the background holds a reference to the activity, the corresponding memory cannot be reclaimed. This eventually caused the OutOfMemoryError to crash.

Locate memory leaks

Finding memory leaks is a manual process, the following are the key steps:

1. Learn about OutOfMemoryError crashes through Bugsnag, Crashlytics or the developer console.
2. Try to reproduce the problem. You may need to buy, borrow, or steal the specific device that crashed. (Not all devices will leak!) You also need to figure out what navigation sequence triggered the leak, which may be caused by violence.
3. Dump the heap when OOM occurs.
4. Use MAT or YourKit to search around the garbage dump and find an object that should be garbage collected.
5. Calculate the shortest path from strong references.
6. Find out references that shouldn't exist in the path, and fix memory leaks.

What if a library can do all of this before you reach OOM, allowing you to focus on fixing memory leaks?

Introduce LeakCanary

LeakCanary is an open source Java library used to detect memory leaks in debug versions.

Let's look at an example of a cat:

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 an instance of RefWatcher and specify the objects to be monitored:

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

When a leak is detected, you will automatically get a leak trace:

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

We know you are busy writing features, so we are easy to set up. With just one line of code, LeakCanary will automatically detect active leaks:

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

You will get a notification and a nice display out of the box:

in conclusion

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

The results are amazing. Now, crashes caused by OOM errors have been reduced by 94%.

If you want to eliminate OOM crashes, install LeakCanary now!