Five common memory leaks in Android development and their solutions

An object in Android is no longer needed, but other objects still hold its reference, so it cannot be recycled, resulting in the object being temporarily stored in memory, so memory leakage occurs.

If there are too many memory leaks, the application will occupy too much memory. When the occupied memory exceeds the memory capacity allocated by the system, there will be memory overflow, resulting in application crash

After understanding the causes and effects of memory leakage, what we need to do is to master the common memory leakage and try to avoid it in future Android program development. Here are five common memory leakage problems and solutions in Android development. Let's share them with you and have a look.

1、 Memory leak caused by singleton

Everyone likes to use the single column of Android. However, the static characteristics of the singleton pattern make its life cycle as long as the application life cycle, which means that an object does not need to be used. If the singleton object still holds an object, the object cannot be released, which is a memory leak.

Typical example:

This singleton needs to pass in the context object, so the life cycle of this context is very important:

1. The context of the application is passed in: there will be no problem, because the life cycle of the single instance is as long as that of the application;

2. The context of the activity is passed in: when the activity corresponding to this context exits, because the context is as long as the life cycle of the activity (the activity indirectly inherits from the context), its memory will not be recycled when the current activity exits, because the singleton object holds the reference of the activity.

Therefore, the correct singleton should be modified as follows:

In this way, no matter what context is passed in, the application context will eventually be used, and the life cycle of the singleton is as long as that of the application, which prevents memory leakage.

2、 Memory leak caused by creating static instance of non static inner class

In order to avoid creating the same data resources repeatedly in activities that are frequently started, this method may appear:

In this way, a single instance of a non static internal class is created inside the activity, and the data of the single instance will be used every time the activity is started. In this way, although repeated creation of resources is avoided, this writing method will cause memory leakage, because the non static internal class will hold the reference of the external class by default, and a static instance is created by using the non static internal class, The life cycle of the instance is as long as that of the application, which leads to that the static instance will always hold the reference of the activity, and the memory resources of the activity cannot be recycled normally. The correct approach is:

Set the internal class as a static internal class or extract and encapsulate the internal class into a single instance. If you need to use context, please use ApplicationContext.

3、 Memory leak caused by handler

Memory leakage caused by the use of handler is the most common problem. Usually, when dealing with network tasks or encapsulating some request callbacks and other APIs, it should be handled with the help of handler. If the code for the use of handler is not standardized, it may cause memory leakage, as shown in the following example:

This way of creating a handler will cause memory leakage. Since mhandler is an instance of the non static anonymous inner class of the handler, it holds a reference to the external class activity. We know that the message queue keeps polling and processing messages in a looper thread. When the activity exits, there are still unprocessed messages or processing messages in the message queue, The message in the message queue holds the reference of the mhandler instance and the mhandler holds the reference of the activity, so the memory resources of the activity cannot be recovered in time, resulting in memory leakage. Therefore, another method is:

Create a static handler internal class, and then use weak references to the objects held by the handler, so that the objects held by the handler can also be recycled during recycling. Although activity leakage is avoided, there may still be messages to be processed in the message queue of the looper thread, so we should remove the messages in the message queue during destroy or stop of the activity, A more accurate approach is as follows:

Use mhandler. Removecallbacksandmessages (null); Yes, remove all messages and all runnable in the message queue. Of course, you can also use mhandler. Removecallbacks(); Or mhandler. Removemessages(); To remove the specified runnable and message.

4、 Memory leak caused by resource not closed

The use of braodcastreceiver, contentobserver, file, cursor, stream, bitmap and other resources should be closed or logged off in time when the activity is destroyed, otherwise these resources will not be recycled, resulting in memory leakage.

5、 Memory leak caused by thread

Memory leaks caused by threads are also common. The following two examples may be written by everyone:

The above asynchronous task and runnable are both anonymous inner classes, so they both have an implicit reference to the current activity. If the task is not completed before the activity is destroyed, the memory resources of the activity cannot be recycled, resulting in memory leakage. The correct approach is to use static inner classes, as follows:

In this way, the memory resource leakage of the activity is avoided. Of course, the corresponding task asynctask:: cancel() should also be cancelled when the activity is destroyed, so as to avoid wasting resources when the task is executed in the background.

The above are the five common memory leakage problems and corresponding solutions in Android programming. If you encounter the above leakage problems in programming, you might as well try the corresponding methods.

The above is the whole content of this article. I hope the content of this article can bring some help to your study or work. At the same time, I also hope to support a lot of programming tips!