Android combat--leakcanary detect memory leaks

This article covers the following topics:

• Objective
• Introduction to memory leaks
• Introduction to Memory Overflow
• Configuration and use of leakcanary
• Conclusion

Memory leaks may be a strange word for beginners, but they occur frequently on their own software, but they do not know it. Similarly, memory overflow is a reason. Memory leaks and memory overflows are often interview questions, so early mastery is essential

A memory leak is when an object is garbage collected at the end of its limited life cycle, and if it is also referenced by a series of references at the time of collection, the object will not be recycled, causing a memory leak. As the leak accumulates, the application will consume memory, and the application's fluency will be greatly weakened.

Common memory leaks include the following:

1. A static variable reference causes a memory leak
2. Memory leak caused by property animation not being closed in time

Memory leaks are involved, and of course the contents of memory overflow are not escaped

Memory overflow refers to the memory that is required by the program, which exceeds the range that the system can allocate, resulting in overflow. The default maximum memory value for Android apps is 16M, and if you use more memory than the maximum, it can result in an app error

Common memory overflows are:

1. Memory overflow due to large picture

Leakcanary is an artifact developed by square to detect memory leaks that can be embedded in our applications and help us automatically detect memory leaks

Adding dependencies to Leakcanary in the gradle of a project

First, you need to create a class that inherits from application, in order for us leakcanary to work in the global activity

Next, specify the application in the manifests file

Finally, we are directly configuring our leakcanary in application.

Our leakcanary has been embedded successfully, and we've left the test.

We use a static variable memory leak as our test result, creating a class that can hold an activity object into a ArrayList and keep the activity there

After the memory leak class is done, the class is used directly in our main interface and the activity of the main interface is stored in the ArrayList.

This time, we have simulated the memory leak, and then we can run the program to test

We run the program into the main interface, then the main interface activity is saved, military training experience this time is nothing, because the main interface activity is also referenced, and there will be no memory leaks. Then, we exit the main interface, according to the rationale is: Exit the main interface activity, its life cycle is ended, the activity must be collected by the system, but we also left a hand, save it, then wait for a period of time, will be in the notification bar to receive leakcanary notification message

This time, the memory leak report is out, click on the notification message, enter the memory leak report analysis

The results were analyzed as follows:

The first part (the activities variable of the Activitypool Class) results in the disclosure of Part IV (instance instance of the Leakcanaryactivity Class) due to the second part (an array in ArrayList) and the third part (an object in the array)

So that we can easily locate the part of the memory leak.

Why does it take a while for a memory leak report to wait for some time to close the activity?

The reason is that leakcanary listens to the lifecycle of all activity and adds the activity to the memory leak monitoring queue after the activity's ondestory function ends. Next, in the background thread to detect whether this reference is cleared, if no GC operation will occur (garbage collection), if the reference is still not cleared, Dump the heap memory into a. hprof file and store it in the phone system, and the app will open another process to parse the. hprof file, and finally export the leaked reference chain, return it to the application, and push the message out by pushing

The use of leakcanary is not difficult, it is important how to eliminate the problem of memory leaks, most of the problems may still need to be found in the actual combat, here is just an example, but after this, I believe you have a memory leak and overflow have a general understanding of the similar face test should be no problem

Android combat--leakcanary detect memory leaks