LeakCanary: detects all memory leaks and leakcanary leaks.
Https://corner.squareup.com/2015/05/leak-canary.html (LeakCanary is just open source by Square to find the library for Android Memory leakage)
java.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 liked OutOfMemory to crash on the registration interface of Square. We used bitmap cache to draw the customer's signature. The bitmap size is equivalent to the screen size. When we created it, we have a lot of OOM crashes.
We tried some methods, but none of them can solve the problem:
- Use Bitmap. Config. ALPHA_8 (the signature does not need color ).
- Capture OutOfMemoryError, trigger GC and retry multiple times (inspired by GCUtils ).
- We didn't think about allocating bitmaps from the Java heap. Fortunately, Fresco didn't. (Note: Fresco is an open source library used by Facebook for image caching. You can pay attention to it)
We once saw that the size of bitmap in the direction is not a problem. When the memory is about to run out, OOM can happen everywhere. They occur more when you create a large object such as Bitmap. OOM is just a symptom of a deeper problem: Memory leakage.
What is memory overflow? Some objects have limited lifecycles and will be recycled after their work is completed. If an object is still referenced in memory after its lifecycle ends, memory leakage will occur. When the leakage accumulates too much, the application will run out of memory.
For example, in Activity. after the OnDestroy () method is called, all the hierarchical views of the activity and their associated bitmaps should be recycled. If a background running thread references the activity, the memory corresponding to the activity cannot be recycled, which will eventually cause the OutOfMemoryError to crash.
Tracing memory overflow tracking memory overflow is a manual process. Raizlabs's Wrangling Dalvik has a good description of this.
The following are the key steps:
This library will complete all the above operations when you encounter OOM, so that you can focus on solving the memory overflow problem.
LeakCanary introduction LeakCanary is a Java open source library that can detect memory leakage during debugging.
Let's look at a small example:
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 design a listener object
// We expect schrodingerCat to be gone soon (or not), let's watch it.refWatcher.watch(schrodingerCat);
When a leak is detected, you automatically obtain a good leak trace:
* GC ROOT static Docker.container* references Box.hiddenCat* leaks Cat instance
We know that you are busy writing functions, so we can easily set them. Only one line of code, LeakCanary will automatically detect activity leaks:
public class ExampleApplication extends Application { @Override public void onCreate() { super.onCreate(); LeakCanary.install(this); }}
You will get a Notification and a good display interface:
Summary After LeakCanary was used, we found many memory leaks in our applications, and we even found some Android SDK memory leaks.
The results were surprising, and our OOM errors were reduced by 94%.
If you want to eliminate OOM errors, use LeakCanary now!
Original address: http://blog.csdn.net/lilu_leo/article/details/45624735 reproduced please declare.
On July 6, 2015, I started to try my public account:
