"Android Memory Leak Detection" leakcanary usage Summary

First, what is Leakcanary?

Leakcanary is a tool used to detect memory leaks on the Android side. Ability to detect leaks in activity

What is a memory leak?

Java objects are sometimes "long dead", the GC has no way, this is a memory leak. The reason for this is that Java objects are held by a longer object in another life cycle and are accessible , which is not what we want.

From

The danger of memory leaks?

Memory leaks will eventually lead to memory overflow, that is, oom, and oom occurs in a place, does not mean that the problem is out there, just there is a memory application, when the memory is not enough to cause, relatively easy to appear in the application of relatively large memory situation. But lowering the memory for this application does not fundamentally solve the problem.

Here's a question: How to allocate memory, where to assign it, such as the allocation of bitmap, and the allocation of other objects? And the activity's possession of the object, the concept is not very clear.

Address on GitHub: https://github.com/square/leakcanary

An introduction to the principle is here:

https://www.liaohuqiu.net/cn/posts/leak-canary/

https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/

Second, what is the working principle of leakcanary?

These three are explained, and there are direct through the source to explain, the latter can be targeted at this piece, specifically for the source code research.

Http://www.jianshu.com/p/a8900eb3de12

http://www.jianshu.com/p/5ee6b471970e

http://www.jianshu.com/p/3f1a1cc1e964

Working principle is:

Leakcanary will open a service that can detect if there is a real object after an activity is ondestory, and if it does, it will attempt two confirmations if the object is not released. Will get the memory state at that time, generate a heap state file, then parse the file, calculate the object's GC root of the shortest strong reference path, determine whether the leak, if there is a leak, the leak app will have a notification bar message appears

The test flowchart is as follows:

Third, how to use

1, introduced in the Build.gradle:

Debugcompile ' com.squareup.leakcanary:leakcanary-android:1.3.1 '//or 1.4-BETA1
Releasecompile ' com.squareup.leakcanary:leakcanary-android-no-op:1.3.1 '//or 1.4-BETA1
Testcompile ' com.squareup.leakcanary:leakcanary-android-no-op:1.3.1 '//or 1.4-BETA1

Or, now the newest 1.5.1 can also be used directly:

dependencies{

Compile' com.squareup.leakcanary:leakcanary-android:1.5.1 '

}

2, at the same time, in the application method, in the OnCreate add install

public class DemoApplication extends application {
@Override public void OnCreate () {
Super.oncreate ();
Leakcanary.install (this);
}
}

3, after the addition, directly after the application of the package, installed, you will see a subsidiary application came out, named leaks

4, direct operation of the app, if there is a memory leak, then this process will have notification bar prompt, click to view, you can share the information leaked, you can also share the heap dump information (but it is possible that the heap dump does not exist)

Take a sample of the detected figure as an example:

The leakcanary memory leak hint typically contains three parts:

First Part (The sinstance variable of the Leaksingle Class) refers to the second part (the mcontext variable of the Leaksingle class), causing the third part (instance mainactivity of the instance class) to be compromised.

Below are some more detailed explanations of the principles:

1. Different ways of quoting: strong-soft-weak-virtual

2, Leakcanary here, there is a principle of the explanation is called:

Need to understand why to use WeakReference, because the GC is not to do the strong reference processing, and the soft reference is not enough memory to be recycled, and the weak reference can be recycled at any time, so you need to use WeakReference to treat the object detected by the package reference, Because it is a weak reference, after the object to be detected calls the Destory or Finish method, the life cycle of the object referenced by the weakreference ends, because this is a weak reference, it will be detected by the GC, This time the GC will add the object to Referencequeue, if the GC ends the object is not added to the referencequeue, then there may be a memory leak, in fact, to find all the end-of-life objects, filtered out will be recycled, The rest is not recycled, and then do two GC, and then still no recycling, you can find the memory state, get the different object references, get a hprof file, then can find the shortest strong reference path.

Resolve a memory leak by using the following methods:

Then we need to fix: How to get an object that is not recycled. referencequeue+weakreference+ manually invoking the GC can achieve this requirement.

• When WeakReference is created, a Referencequeue object is passed in. When the life cycle of the object referenced by WeakReference is over, once it is checked by the GC, the GC will add the object to the Referencequeue for referencequeue processing. A memory leak may exist when the object has not been joined to Referencequeue after the GC.

Get an Object that has not been recycled

• Found an object that has not been reclaimed, how can I confirm that it is a true memory leak? Here you can convert the problem to: objects that are not reclaimed, are they referenced by other objects? Find its shortest reference chain. Vmdebug + HAHA Complete the requirements.
  VMS have references to objects within the heap and can be exported as hprof files. HAHA is a square open source Android Heap Analysis library that analyzes hprof file generation snapshot objects. Snapshot the shortest reference chain used to query objects.

Parsing hprof

• After finding the shortest reference chain, locating the problem and troubleshooting the code will do more with less.

The following Swimlane graph analysis, leakcanary each module how to meet the detection purposes.

From

"Android Memory Leak Detection" leakcanary usage Summary