Analysis of Android Memory Overflow and Memory Leak Causes

Memory overflow (Out Of Memory): Every application in Android system can apply to the system for a certain amount of memory. When the applied memory is not enough, memory overflow occurs.

Memory leak: When an object is no longer used, that is, when no variables refer to it, the memory occupied by the object will be reclaimed by the system. When an object is no longer in use, but it is still referenced by variables in other objects, the memory occupied by the object cannot be reclaimed by the system, resulting in a memory leak.

When there are too many memory leaks, the available memory space will decrease, and the application will not have enough memory to apply for, which will lead to memory overflow.

Memory overflow reason:

1. Too many memory leaks.

2. The amount of data loaded in memory exceeds the available amount of memory.

3. The collection class (used to store references to objects) has references to objects, which are not emptied after use.

4. There is not enough memory requested.

5. An infinite loop or loop produces too many object instances, resulting in a large amount of memory being consumed.

. . .

Memory leak reason:

1. The resource object is not closed:

(1) The unregisterReceiver () method was not called to unregister the broadcast receiver after it was registered.

(2) After opening the file stream, the close () method is not called to close the file stream.

(3) After the database cursor cursor is used, the close () method is not called to close the cursor.

(4) The recycle () method is not called to recycle the picture resource Bitmap after it is used up.

. . .

2. Objects with long lifecycle hold references to objects with short lifecycle, which leads to the memory of objects with short lifecycle not being recycled:

(1) The life cycle of singleton schema or static member variable is equal to the life cycle of application program. When Context needs to be referenced, if Context of Activity is passed in, Activity cannot be recycled when it needs to be destroyed. The workaround is to pass Context into Application, because the Context lifecycle of Application equals the lifecycle of the application.

(2) Non-static inner classes (anonymous inner classes, Handler, etc.) hold references to external classes by default. If the object instance life cycle of non-static inner classes is longer than that of external classes (for example, the non-static inner classes define a static object instance), the external classes cannot be recycled by the system when they log out, resulting in memory leakage. The solution is to adopt static inner class + weak reference.

Summary: There are two main reasons for memory leakage: One is that the resource object is not closed after use. The other is that the object with long life cycle references the object with short life cycle, which leads to the object with short life cycle being unable to be recycled by the system even if it is no longer used. The root cause is that the memory resources that need to be reclaimed have not been reclaimed by the system.