Summary of Android memory leaks (with memory detection tools)

Memory allocation in Java

It is mainly divided into three parts:

• Static storage area: It is allocated during compilation and exists during the entire execution of the program. It mainly stores static data and constants.
• Stack area: When a method is executed, local variables inside the method body are created in the stack memory, and the memory is automatically released after the method ends.
• Heap area: usually stores new objects and is recycled by the Java garbage collector.

Difference between stack and heap

The stack memory is used to store local variables and function parameters. It is a first-in, last-out queue, with one-to-one correspondence between in and out, no fragmentation, and high stable operating efficiency. When the scope of a variable is exceeded, the variable will be invalid, and the memory space allocated to it will be released, and the memory space can be reused.

Heap memory is used to store object instances. The memory allocated in the heap will be automatically managed by the Java garbage collector. Frequent new/delete in the heap memory will cause a lot of memory fragmentation, reducing program efficiency.

For the storage location of non-static variables, we can roughly think that:

• Local variables are located on the stack (where the object entity pointed to by the reference variable exists on the heap).
• Member variables are located on the heap. Because they belong to a class, the class is eventually newed into an object and stored on the heap as a whole.

Introduction to the four types of citations

The fundamental principle of GC releasing an object is that the object is no longer referenced (strong reference). So what is a strong reference?

Strong Reference

The most commonly used one is the strong reference, as follows:

 IPhotos iPhotos = new IPhotos();

JVM would rather throw OOM than let GC reclaim objects with strong references. When strong references are not used, you can explicitly set all references of the object to null through obj = null, so that the object can be reclaimed. As for when to reclaim, it depends on the GC algorithm, which is not discussed here.

Soft Reference

 SoftReference<String> softReference = new SoftReference<>(str);

If an object has only soft references, the garbage collector will not reclaim it if there is enough memory space; if there is not enough memory space, the memory of these objects will be reclaimed. As long as the garbage collector does not reclaim it, the object can be used.

Soft references were once often used for image caching, but Google now recommends using LruCache instead because LRU is more efficient.

In the past, a popular memory cache implementation was a SoftReference

or WeakReference bitmap cache, however this is not recommended.

Starting from Android 2.3 (API Level 9) the garbage collector is more

aggressive with collecting soft/weak references which makes them

fairly ineffective. In addition, prior to Android 3.0 (API Level 11),

the backing data of a bitmap was stored in native memory which is not

released in a predictable manner, potentially causing an application

to briefly exceed its memory limits and crash. Original text

The general meaning is: after Android 2.3, GC will be very frequent, resulting in a high frequency of releasing soft references, which will reduce its efficiency. And before 3.0, Bitmap is stored in Native Memory, and its release is not controlled by GC, so using soft reference to cache Bitmap may cause OOM.

Weak Reference

 WeakReference<String> weakReference = new WeakReference<>(str);

The difference from soft references is that objects with only weak references have a shorter life cycle. Because during GC, once an object with only weak references is found, its memory will be reclaimed regardless of whether the current memory space is sufficient or not. However, since the garbage collector is a low-priority thread, it may not necessarily find objects with only weak references quickly.

PhantomReference

As the name implies, it is virtual. Unlike other references, virtual references do not determine the life cycle of an object, and object instances cannot be obtained through virtual references. Virtual references must be used in conjunction with reference queues (ReferenceQueue). When the garbage collector is ready to recycle an object, if it finds that it still has virtual references, it will add this virtual reference to the reference queue associated with it before reclaiming the object's memory. The program can determine whether the object is about to be recycled by determining whether there is a virtual reference to the object in the reference queue.

Introduction to Android's garbage collection mechanism

There is a Generational Heap Memory model in the Android system. The system will perform different GC operations according to the different memory data types in the memory.

The model is divided into three areas:

• Young Generation
  1.eden
  2.Survivor Space
  1.S0
  2.S1
• Old Generation
• Permanent Generation
• Young Generation

Most new objects are placed in the eden space. When the eden space is full, Minor GC (lightweight GC) is executed, and the surviving objects are moved to the Survivor space (there are two: S0 and S1). Minor GC will also check the objects in the Survivor space and move them to another Survivor space, so that there will always be an empty Survivor space.

Old Generation

Store long-lived objects (objects that survive multiple Minor GCs). When the Old Generation area is full, Major GC is executed.

Before Android 2.2, the application's threads would be suspended when executing GC. Starting with 2.3, a concurrent garbage collection mechanism was added.

Permanent Generation

Storage method area. General storage:

• Information about the class to load
• Static variables
• final constant
• Property and method information

60 FPS

Here we briefly introduce the concept of frame rate to help you understand why a large number of GCs can easily cause lag.

When developing an app, the frame rate of the interface is generally pursued to reach 60 FPS (60 frames per second). What is the concept of this FPS?

• The effect of animation can be felt at 10-12 FPS;
• 24 FPS, you can feel the smooth and coherent animation effect, which is a common frame rate for movies (not pursuing 60 FPS is to save costs);
• 60 FPS achieves the smoothest effect. For higher FPS, the brain can hardly detect the difference.

Android sends a VSYNC signal every 16 ms to trigger the rendering of the UI (i.e., one frame is drawn every 16 ms). If the entire process is kept within 16 ms, a smooth picture of 60 FPS will be achieved. If it exceeds 16 ms, it will cause lag. If a large number of GCs occur during UI rendering, or GC takes too long, the drawing process may exceed 16 ms, causing lag (FPS drop, frame drop, etc.), and our brain is very sensitive to frame drops, so if memory management is not done well, it will bring a very bad experience to users.

Let me introduce the concept of memory jitter, which may be used later in this article.

Memory Thrashing

A large number of new objects in a short period of time trigger GC when the threshold of Young Generation is reached, causing the newly created objects to be recycled again. This phenomenon will affect the frame rate and cause lag.

Memory jitter is roughly manifested as follows in the Memory Monitor provided by Android:

Common memory leaks and solutions in Android

Collection Class Leak

If a collection is a global variable (for example, static), and some objects that occupy a lot of memory are directly stored in the collection (rather than stored through weak references), then as the size of the collection increases, the memory usage will continue to rise, and when the Activity is destroyed, these objects in the collection cannot be recycled, resulting in memory leaks. For example, we like to use static HashMap to do some caching, so be careful in this case. It is recommended to use weak references to access objects in the collection and consider manually releasing them when they are not needed.

Memory leak caused by singleton

The static nature of a singleton means that its lifecycle is as long as the application.

Sometimes when creating a singleton, if we need a Context object, there will be no problem if we pass in the Application's Context. If we pass in the Activity's Context object, then when the Activity lifecycle ends, the Activity's reference is still held by the singleton, so it will not be recycled. The lifecycle of the singleton is the same as that of the application, so this causes a memory leak.

Solution 1: Do not use the passed in context directly when creating a singleton. Instead, use this context to get the Application's Context. The code is as follows:

 public class AppManager {
    private static AppManager instance;
 private Context context;
    private AppManager(Context context) {
        this.context = context.getApplicationContext();//Use Application context
 }
 public   static AppManager getInstance(Context context) {
        if (instance != null ) {
            instance = new AppManager(context);
 }
 return instance;
 }
 }

The second solution: When constructing a singleton, there is no need to pass in the context. Instead, write a static method in our Application, return the context through getApplicationContext in the method, and then call this static method directly in the singleton to get the context.

Memory leak caused by non-static inner class

In Java, non-static inner classes (including anonymous inner classes, such as Handler and Runnable anonymous inner classes, which are most likely to cause memory leaks) will hold strong references to outer class objects (such as Activity), while static inner classes will not reference outer class objects.

Because non-static inner classes or anonymous classes hold references to outer classes, they can access resource attributes, member variables, etc. of the outer class; static inner classes cannot.

Because ordinary inner classes or anonymous classes depend on outer classes, you must first create the outer class and then create the ordinary inner class or anonymous class; static inner classes can be created in other outer classes at any time.

For Handler memory leaks, you can follow my other article specifically for Handler memory leaks: link

WebView Leaks

WebView in Android has a lot of compatibility issues, and some WebViews even have memory leaks. So the usual way to solve this problem is to start another process for WebView, communicate with the main process through AIDL, and the process where WebView is located can be destroyed at the right time according to business needs, so as to achieve complete memory release.

Memory leak caused by AlertDialog

 new AlertDialog.Builder(this)
        .setPositiveButton( "Baguette" , new DialogInterface.OnClickListener() {
 @Override
 public void onClick(DialogInterface dialog, int which) {
                MainActivity.this.makeBread();
 }
 }).show();

The anonymous implementation class of DialogInterface.OnClickListener holds a reference to MainActivity;

In the implementation of AlertDialog, the OnClickListener class will be wrapped in a Message object (see the setButton method of the AlertController class for details), and the Message will be copied inside it (as can be seen in the mButtonHandler of the AlertController class). Only one of the two Messages will be recycled, and the other (the Message object referenced by the member variable of OnClickListener) will be leaked!

Solution:

• This problem does not exist on Android 5.0 and above;
• Leakage of Message objects is unavoidable, but if it is just an empty Message object, it will be put into the object pool for later use, which is no problem;
• Make the DialogInterface.OnClickListener object not hold a strong reference to the external class, such as using a static class implementation;
• Dismiss dialog before exiting the Activity

Memory leaks caused by Drawable

Android 4.0 and later has solved this problem. You can skip this step.

When we rotate the screen, the current Activity will be destroyed by default, and then a new Activity will be created and the previous state will be maintained. During this process, the Android system will reload the program's UI views and resources. Suppose we have a program that uses a large Bitmap image, and we don't want to reload this Bitmap object every time the screen rotates. The easiest way is to modify this Bitmap object with static.

 private static Drawable sBackground; 
 
 @Override
 protected void onCreate(Bundle state) {
 super.onCreate(state);
    TextView label = new TextView(this);
    label.setText( "Leaks are bad" ); 
 
    if (sBackground == null ) {
        sBackground = getDrawable(R.drawable.large_bitmap);
 }
    label.setBackgroundDrawable(sBackground); 
 
 setContentView(label);
 }

However, the above method may cause memory leaks when the screen rotates, because when a Drawable is bound to a View, the View object actually becomes a callback member variable of the Drawable. In the above example, the static sBackground holds a reference to the TextView object, and the TextView holds a reference to the Activity. When the screen rotates, the Activity cannot be destroyed, which causes a memory leak.

This problem mainly occurs before 4.0, because in versions 2.3.7 and below, the implementation of the setCallback method of Drawable is direct assignment. Starting from 4.0.1, setCallback uses weak references to handle this problem, avoiding memory leaks.

Memory leak caused by unclosed resources

• BroadcastReceiver, ContentObserver, etc. are not unregistered
• Cursor, Stream, etc. are not closed
• ***The looping animation does not stop before the Activity exits
• Some others that should be released are not released, some that should be recycled are not recycled... and so on.

Summarize

It is not difficult to find that most problems are caused by static!

• Be careful when using static and pay attention to the references held by the static variable. Use weak references to hold some references when necessary.
• Also be careful when using non-static inner classes, after all, they hold references to outer classes. (Students using RxJava should also pay attention to unSubscribe when subscribing)
• Be careful to release resources at the end of the life cycle
• When using attribute animation, please stop it when not in use (especially looping animation), otherwise it will cause memory leaks (Activity cannot be released) (View animation will not)

Introduction of several memory detection tools

• Memory Monitor
• Allocation Tracker
• Heap Viewer
• LeakCanary

Memory Monitor

Located in Android Monitor, this tool can:

• Conveniently display memory usage and GC status
• Quickly determine whether the jam is related to GC
• Quickly locate whether the crash is related to excessive memory usage
• Quickly locate potential memory leaks (memory usage keeps growing)
• But the problem cannot be accurately located

Allocation Tracker

This tool is used to:

• You can locate the object type, size, time, thread, stack, and other information allocated in the code
• Can locate memory jitter problems
• Use Heap Viewer to locate memory leaks (you can find out where the leaked object was created, etc.)

How to use: There is a Start Allocation Tracking button in Memory Monitor to start tracking. After clicking Stop Tracking, the statistical results will be displayed.

Heap Viewer

This tool is used to:

• Display memory snapshot information
• Collect information once after each GC
• A powerful tool for finding memory leaks

How to use: There is a Dump Java Heap button in Memory Monitor, just click it, and select the package category in the upper left corner of the statistical report. Use the initiate GC button in Memory Monitor to detect memory leaks and other situations.

LeakCanary

Important things should be said three times:

 for ( int i = 0; i < 3; i++) {
 Log.e(TAG, "A magical tool for detecting memory leaks!" );
 }

I won't go into details about the specific usage of LeakCanary, just Google it.