Cause analysis and solution of memory leak in Android

In the process of Android development, we often encounter the situation that the program suddenly crashes when we don't know why. There is one kind of log that I believe everyone has often encountered. This kind of log is the log related to oom. In addition to the bitmap operations that we know often lead to such logs, there is also a deep hidden cause: memory leak.

Cause and impact of memory leak: cause: when an object is no longer needed, it should have been recycled by GC, but it cannot be recycled normally because another object in use holds it. The object that should have been recycled cannot be recycled and is still stored in heap memory. At this time, memory leak occurs. Impact: the memory that the Android system can allocate for each application is limited. When there is too much memory leakage in an application, it will inevitably lead to the memory required by the application exceeding the limit, resulting in memory overflow and application crash. Memory leak detection method

It is recommended to use the leakcanary tool to detect memory leaks in applications. Leakcanary is a lightweight third-party memory leak detection tool open source by square. When a memory leak is detected in the program, it will tell us in the most intuitive way where the memory leak occurs and who caused the leak and cannot be recycled.

How to avoid memory leakage

1. Rational use of singleton mode.

The static nature of a singleton makes its life cycle as long as that of an application.

As shown in the figure, we first state a singleton object:

In general, it is OK to change to the following description, because the life cycle of a single instance is as long as that of the application, so as to prevent memory leakage

2. When using resources, pay attention to the closing of resources

In general, the resources prone to memory leakage are mainly: file, cursor, stream, bitmap, broadcastreceiver, etc. it is recommended to close these resources in time when they are in use. Otherwise, memory leakage will occur when these resources are not recovered in time. For the use of these resources, the following suggestions are given:

After the broadcastreceiver registers, it is necessary to unregister objects of resource types such as cursor, stream and file at an appropriate time. Therefore, when it is not in use, we should close it in time so that the cache can be recycled in time. If we only set its references to null without closing them, it will often cause memory leakage. The general recommendation is to close () first and then set it to null. When bitmap is not in use, call the recycle () method. At present, after Android version 2.3, we don't need to do this manually. Here is a simple explanation.

3. Rational use of handler to avoid memory leakage

When we use the handler, we often see the editor prompt that the handler may cause memory leakage. Generally, in this case, we can separate the handler or use a static internal class to avoid memory leakage. The reason for this is that a non static inner class will potentially hold a reference to the outer class to which it belongs, but a static inner class will not.

4. Reasonably use WeakReference to refer to member variables of external classes

We can use WeakReference to avoid many potential memory leaks, but it does not mean that WeakReference is the golden key to solve memory leaks. Whether to use WeakReference mainly depends on the current understanding of the problem, which requires our modeling idea of the problem.