Memory leaks must be commonplace for every Android development, and everyone must have some contact with them to more or less. As we all know, every mobile phone has a certain load cap, and memory leaks in multiple places will definitely accumulate like mountains, and eventually a memory explosion OOM occurs.
And this is also a common open question that is very likely to be a common open question in Android interviews.
The root cause of memory leaks is that an object with a long life cycle holds a short life cycle object. If you have some understanding of the garbage collection mechanism, I think this problem is basically difficult for you, because if you know the principle, you will naturally not touch these minefields that are very likely to cause memory leakage.
This question focuses on accumulation, and you don’t need to memorize it by rote, just summarize it yourself.
1. Long-life cycle object holding Activity
This is basically the most common memory leak, for example
The internal class uses Handler to send delay messages at the same time, or executes time-consuming tasks in the Handler. The Activity needs to be destroyed when the task is not completed. At this time, the Activity cannot be recycled due to the strong reference of the Handler holding the Activity.
Similarly, using AsyncTask to perform time-consuming tasks in internal classes can also lead to memory leaks.
As the object with the longest life cycle, a singleton should naturally not hold an activity, which will lead to memory leakage;
In response to the above situation, there is basically no need to say more. Just don’t use internal classes or anonymous internal classes to do this. In fact, the IDE will also pop up warnings. I think everyone should still know that using static internal classes or using relevant methods to remove the processing when destroying the page.
Anonymous use of Handler in Activity actually causes the Handler inner class to hold references to the external class, and when SendMessage() is SendMessage, the enqueueMessage mechanism will cause the MeassageQueue to hold Message. Therefore, when the delay message is sent, the Message will not be traversed immediately and processed, but will block to the corresponding Message trigger time before processing. Then, during this blocking period, page destruction will definitely cause memory leakage.
2. There is no corresponding anti-registration for various registration operations
There is basically no need to say much about this. I believe that when you first started learning radio and Service, you must have had some contact with it. For example, the third-party framework EventBus, which we commonly use, is the same. When using it normally, pay attention to anti-registering in the corresponding life cycle method.
3. Don't pay attention to recycle() after using Bitmap
As a large object, you must pay attention to calling recycle() for recycling after using Bitmap. The same applies to TypedArray, Cursor, and various streams. You must call your own recycling closing method at the end.
4. Improper use of WebView
WebView is a very common control, but a little bit of attention can also lead to memory leaks. Memory leak scenario: Many people like to use layout references when using Webview, which is actually a hidden danger of memory leaks. When the activity is closed, the Webview will not be recycled immediately by the GC, but will be submitted to the transaction for queue processing, which will cause memory leakage and the Webview cannot be recycled in time.
The safest solutions currently known are:
Dynamically add WebView to the layout.
Use the following method.
override fun onDestroy() {
webView?.apply {
val parent = parent
if (parent is ViewGroup) {
(this)
}
stopLoading()
// Call this method when exiting to remove the bound service, otherwise some specific systems will report an error = false
clearHistory()
removeAllViews()
destroy()
}
}
5. Recycle reference
It is rare to cause memory leaks due to circular references. Normally, no one will write codes such as A holding B, B holding C, and C holding A, but it still needs to be paid attention to.
Overall, memory leaks are common, but there are many ways to detect them. Our Android Studio's own Monitors can help us find most memory problems. Of course, we can also use libraries such as LeakCanary to detect them.