Eight common issues that cause APP memory leaks (top)

Baidu Search: Xiao Qiang test brand

QQ Group: 138269539

One of the benefits of a garbage-collected language like Java is that programmers do not have to manually manage memory allocations. This reduces the flicker caused by segment errors (segmentation fault), and also reduces heap space bloat caused by memory leaks, which makes writing code more secure. However, a memory leak can still occur in Java. So your Android APP still has the potential to waste a lot of memory, even as memory exhaustion (OOM) results in a flashback.

Traditional memory leaks are caused by forgetting to release allocated memory, while logical memory leaks are caused by forgetting to release references to objects when they are no longer in use. If an object still has a strong reference, it cannot be garbage collected by the garbage collector. In the Android platform, the problem of leaking Context objects is particularly serious. This is because a Context object like activity references a lot of memory-intensive objects, such as the View hierarchy, and other resources. If a memory leak occurs in the Context object, all of the objects it references are leaked. Most Android devices have limited memory, and if a large number of such memory leaks occur, the memory will quickly run out.

If the reasonable life cycle of an object is not clearly defined, then it is a matter of opinion to judge the logical memory leak. Fortunately, activity has a clear definition of life cycle, so that we can clearly determine whether the activity object is memory leaks. The OnDestroy () function is invoked when the activity is destroyed, whether the programmer actively destroys the activity or the system destroys it in order to reclaim the memory. If the activity object is still strongly referenced by the heap root after execution of the OnDestroy, the garbage collector will not be able to reclaim it. So we can define activity that is still being referenced after the end of the life cycle as a leaked activity.

Activity is a very heavyweight object, so we should try to avoid preventing the system from recycling it. However, there are many ways that we can inadvertently disclose the activity object.

There are two types of situations that can lead to activity leaks, such as the use of process Global (Process-global) static variables, which will persist regardless of the state of the APP, and they hold strong references to activity that lead to memory leaks. The other is a thread whose life cycle is longer than the activity, forgetting to release a strong reference to the activity causing a memory leak. Let's take a detailed look at these scenarios that could lead to activity leaks.

Static Activity

The simplest way to leak activity is to define a static variable in the activity class and point it to a running activity instance. If the life of the activity

Before the end of the cycle, the reference is not cleared and it will leak. This is because the class object of the activity (for example, mainactivity) is static, and once loaded, it is

The APP runs permanently in memory, so if the class object is not unloaded, its static members are not garbage collected.

Static View

Another similar scenario is to implement a singleton pattern for frequently initiated activity, so that its resident memory allows it to recover quickly. However, as mentioned earlier, it is very dangerous and unnecessary to not follow the system-defined activity life cycle, so we should try to avoid it.

But what if we have a very time-consuming View that stays the same activity for a different life cycle? So let's implement a singleton pattern for it, just like this code. Now, once the activity is destroyed, we should release most of the memory.

Memory leaks out! Because once the view is added to the interface, it holds a strong reference to the context, which is our activity. Because we quoted the view through a static member, we also quoted the activity, so the activity was compromised. So be sure not to assign the loaded view to a static variable, and if you really need to, ensure that it is removed from the view level before the activity is destroyed.

Inner class

Now let's define a class within the activity, which is the inner class. There are many reasons for this, such as increased encapsulation and readability. If we create an object of an inner class and have a reference to the activity through a static variable, an activity leak can also occur.

Unfortunately, the advantage of having an inner class referencing the members of an external class is achieved by holding a reference to an external class, which is why the activity leaks.

Anonymous class

Similarly, anonymous classes hold references to objects that define them. Therefore, if an anonymous Asynctask object is defined within the activity, a memory leak may occur. If Asynctask is still executing after the activity is destroyed, the garbage collector is organized to reclaim the activity object, causing a memory leak until the execution is over to reclaim activity.

Eight common issues that cause APP memory leaks (top)