Leakcanary method for detecting memory leak in Android
Recently, I want to check the memory leakage of the product. Finally, I chose leakcanary, a function library open source by square company to detect memory leakage. I searched GitHub and found that there are 1.6W stars, and Jake Wharton, the great God of Android, is also a contributor to this open source library. Then use it quickly.
First, let's talk about the pit I encountered. I directly googled it at that time, and then directly searched for an introduction to leakcanary in the rare earth nuggets. I followed their article step by step, and finally found that the library imported from their build.gradle was too old, Closed failed to resolve: com.squareup.leakcanary: leakcanary is very confusing to me who just used leakcanary.
Then I directly use the example on GitHub to introduce leakcanary https://github.com/square/leakcanary
However, another problem is that the construction project fails. GitHub also explains the address connection https://github.com/square/leakcanary/issues/815
Well, after finishing these pits, let's happily use leakcanary to detect memory leaks
1 import steps
Because you don't want such a check to be carried out in the release version officially given to users, you add it in dependencies
Next, write a custom application in your application and "Install" refwatcher in it
Remember to configure it as Android: name under the application node of androidmanifest.xml.
The above can only monitor the memory in the activity, so it is very simple to detect the memory leak in the fragment. You only need to save the global refwatcher in the application first
You also need to create a basefragment and add the following code:
OK, after the import is successful, package it with the debug version. After installation, a leak application will be automatically added to the mobile phone. When there is a memory leak, it will be displayed in it. Another problem here is that the memory leaking icon cannot appear on my 4.4 mobile phone. Select package
Icon after successful import
2. Solution to memory leakage
Here are some common solutions to memory leaks
1. Single instance context memory leak
Here we create a very simple singleton object
Then we call it in Activity. In fact, we often make such mistakes in many times. The reason for this error is very simple. After the contextleakactivity is gone, the testhelper will still hold its context. This causes a memory leak.
Context memory leak prompt diagram
2. Memory leakage caused by broadcast: after registering the broadcastreceiver, but not releasing the broadcastreceiver after the activity is destroyed, it is easy to cause memory leakage, so we need to destroy the broadcastreceiver in ondestroy().
The destruction code is as follows
Memory leak prompt diagram of broadcast
OK, it's easy to use leakleakleakcanary, but it's a little troublesome to solve some memory leaks. However, no matter what kind of memory leaks, the key point is to destroy the objects before the end of the life cycle. If you feel my article is useful to you, please give me a like, thank you
The demo download address connects to leakdemo_ jb51.rar
The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.