Shulou(Shulou.com)06/03 Report--

Android memory leak attention points, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Memory leaks must be common to every Android developer, and everyone must have had some contact more or less. As we all know, every mobile phone has a certain load limit, many memory leaks will pile up, and eventually there will be a memory explosion OOM.

This is also a common open question in the Android interview.

The root cause of memory leakage is that an object with a long life cycle holds an object with a short life cycle. If you know anything about garbage collection mechanisms, I think this problem basically won't bother you, because if you know the principle, you won't touch these minefields that can easily lead to memory leaks.

This question focuses on accumulation, there is no need to memorize, you can sum up more.

1. Long lifecycle objects hold Activity

This is basically the most common memory leak, such as

The inner class form uses Handler to send delayed messages at the same time, or to execute time-consuming tasks in Handler, and the Activity needs to be destroyed before the task is completed. At this time, the Activity cannot be recycled because Handler holds a strong reference to Activity.

Similarly, using AsyncTask to perform time-consuming tasks in the form of inner classes can also lead to memory leaks.

As the object with the longest life cycle, the singleton should not hold Activity, which leads to memory leak.

In view of the above situation, basically needless to say, do not use internal classes or anonymous internal classes to do such processing, in fact, IDE will also pop up a warning, I think everyone should still know to use static internal classes or use relevant methods to remove processing when destroying pages.

The anonymous use of Handler in Activity actually causes the Handler inner class to hold references to the external class, while the Message holds the Handler,enqueueMessage mechanism when SendMessage () causes the MeassageQueue to hold the Message. So when a delay message is sent, the Message will not immediately traverse it for processing, but will block it until the corresponding Message trigger time before processing. Then page destruction during this period of blocking is bound to cause memory leaks.

two。 There is no corresponding anti-registration for various registration operations.

There is no need to say much about this. I believe you must have been in touch with it when you just started to learn about broadcasting and Service, and then it is the same with our commonly used third-party framework, EventBus. When you use it, you should pay attention to the anti-registration in the corresponding lifecycle method.

3. Do not pay attention to recycle () after using Bitmap.

Bitmap as a large object, be sure to call recycle () for recycling after using it. TypedArray, Cursor, and all kinds of streams are the same. Be sure to call your own recycling method to close the process at the end.

4. Improper use of WebView

WebView is a very common control, but a little carelessness can lead to memory leaks. Memory leak scenario: many people prefer to use layout references when using Webview, which is also a hidden danger of memory leaks. When Activity is turned off, the Webview is not immediately reclaimed by GC, but is committed to the transaction for queue processing, which results in a memory leak and prevents Webview from being reclaimed in time.

The safer solutions known so far are:

Dynamically add WebView to the layout.

Use the following method.

Override fun onDestroy () {webView?.apply {val parent = parent if (parent is ViewGroup) {parent.removeView (this)} stopLoading () / / call this method when exiting to remove the bound service, otherwise some specific systems will report an error settings.javaScriptEnabled = false clearHistory () removeAllViews () destroy ()}

5. Circular reference

Memory leaks caused by circular references are relatively rare. Normally, no one will write code such as A holding B, B, C, C and A, but always need to pay attention.

Generally speaking, memory leaks are common, but there are many ways to detect them. The Monitors that comes with our Android Studio can help us find most of the memory problems, but we can also use libraries such as LeakCanary to detect them.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.