Solve the memory leak problem caused by Android using handler

1、 What is a memory leak?

Java uses the directed graph mechanism to automatically check the objects in memory through GC (when to check is determined by the virtual machine). If GC finds that one or a group of objects are unreachable, it will recycle the objects from memory. In other words, if an object is not pointed to by any reference, the object will be recycled when discovered by GC; In addition, if a group of objects contains only references to each other, but no references from outside them (for example, two objects a and B hold references to each other, but no external object holds references to a or b), it is still unreachable and will also be recycled by GC.

Causes of memory leakage caused by using handler in Android

The above is a simple use of handler. When using internal classes (including anonymous classes) to create a handler, the handler object will implicitly hold a reference to an external class object (usually an activity) (otherwise, how can you operate the view in the activity through the handler?). The handler usually appears with a time-consuming background thread (such as pulling pictures from the network). After the task is completed (such as downloading pictures), the background thread notifies the handler through the message mechanism, and then the handler updates the pictures to the interface. However, if the user closes the activity in the process of network request, under normal circumstances, if the activity is no longer used, it may be recycled during GC check. However, since the thread has not finished executing at this time, and the thread holds the reference of the handler (otherwise, how can it send a message to the handler?), and the handler holds the reference of the activity, the activity cannot be recycled (i.e. memory leak) until the end of the network request (e.g. image download). In addition, if you execute the handler's postdelayed() Method, which will load your handler into a message and push the message to the messagequeue. Then, before the delay you set arrives, there will be a chain of messagequeue - > message - > handler - > activity, resulting in your activity being referenced and unable to be recycled.

2、 Harm of memory leakage

The harm of memory leakage is that the virtual machine will occupy too much memory, resulting in oom (memory overflow) and program errors.

For Android applications, your users open an activity and close it after use, resulting in memory leakage; Open, close and leak again; After several times, the memory occupied by the program exceeds the system limit, FC.

3、 Solution

Solution to memory leak caused by using handler

Method 1: protect through program logic.

1. Stop your background thread when closing the activity. When the thread stops, it is equivalent to cutting off the line between the handler and the external connection. Naturally, the activity will be recycled at the right time.

2. If your handler is referenced by the message of delay, use the removecallbacks () method of the corresponding handler to remove the message object from the message queue.

Method 2: declare the handler as a static class.

PS: in Java, both non static internal classes and anonymous internal classes implicitly hold references to their external classes. Static internal classes do not hold references to external classes.

Static classes do not hold objects of external classes, so your activity can be recycled at will. Because the handler no longer holds the reference of the external class object, the program does not allow you to operate the object in the activity in the handler. So you need to add a weak reference to the activity in the handler.

The code is as follows:

PS: what is WeakReference?

WeakReference weak reference is opposite to strong reference (that is, we often say reference). Its feature is that GC ignores weak reference during recycling, that is, even if there is a weak reference pointing to an object, as long as the object is not pointed to by strong reference (in fact, there is no soft reference in most cases, but the concept of soft reference here can be ignored), The object will be recycled when it is checked by GC. For the above code, after the user closes the activity, even if the background thread has not ended, since only a weak reference from the handler points to the activity, the GC will still recycle the activity during inspection. In this way, the problem of memory leakage will not occur.

4、 Summary

Many memory leaks in Android are caused by the use of non static internal classes in activity. We must pay special attention when using non static internal classes. If the life cycle of the instance object of the static internal class is greater than that of the external object, memory leaks may occur. It is recommended to use the static classes and weak references described above to solve this problem.

The above is what Xiaobian introduced to you about the memory leak caused by Android using handler and its solutions. I hope it will be helpful to you. If you have any questions, please leave me a message, and Xiaobian will reply to you in time. Thank you very much for your support for the programming tips website!