This series of articles is dedicated to filling in gaps and preparing Android developers for interviews.

All articles are first published on the public account “JaqenAndroid” and will be updated in the long term.

Due to the author’s limited level, the summary of the answer will inevitably be wrong, welcome to point out that we study together, exchange, progress.

Memory leakage is also a common problem in the interview, which can be used to investigate whether the interviewer knows about memory leakage, how to troubleshoot and solve memory leakage problems in the work, and also can be extended to investigate the Java memory reclamation mechanism, Java object reference method, etc.

This article will start with a look at common memory leaks in Android development and their solutions.

Memory leak caused by singleton

The singleton pattern is very popular in Android development, but can cause memory leaks if used incorrectly. For example:

public class Singleton {    private static Singleton sInstance;    private Context mContext;    private Singleton(Context context) {        this.mContext = context;    }    public static Singleton getInstance(Context context) {        if (sInstance == null) {            sInstance = new Singleton(context);        }        return sInstance;    }}Copy the code

The life cycle of a singleton is as long as the life cycle of an application. If an Activity Context is passed in, the Activity’s memory cannot be reclaimed when the Activity exits because the singleton holds a reference to the Activity. This is a memory leak.

Solution:

1) Use the Application Context and have the same life cycle;

2) Change the reference mode of short-life attributes to weak references.

Memory leaks caused by non-static inner classes

Non-static inner classes hold references to outer classes, which cannot be reclaimed if an instance of the outer class has ended its life cycle but the inner class is still executing. For example, the use of custom handlers causes memory leaks. The main reason is that when the Activity exits, the Handler still holds a reference to the Activity, so the Activity cannot be reclaimed.

Solution:

1) Create a static inner class, and then use weak references for object references of the outer class;

2) Close time-consuming or delayed tasks in time, and clear messages in time when the Activity is destroyed, so as to recycle the Activity in time and avoid memory leaks.

Memory leak caused by uncanceled system service registration

System services can be obtained through context.getSystemService, which perform some background tasks or provide interfaces for hardware access. If the Context object wants to be notified when events occur within the service, it needs to register itself with the listener of the service. However, this leaves the service holding a reference to the Activity, which can leak memory if it is not released in the Activity’s onDestory() function.

Solution:

1) Replace the Activity Context with the Application Context;

2) In the Activity’s onDestory() method, call unregister release.

Memory leak caused by global collection classes

In general, collection classes do not cause memory leaks. However, if the collection is global, it is likely to cause memory leaks if it is not cleaned by remove after use. Therefore, collection elements should be cleaned in time when the collection is not needed.

Memory leak with resource not closed

Resources that use BroadcastReceiver, ContentObserver, File, Cursor, Stream, Bitmap, etc., should be shut down or unregistered when the Activity is destroyed.

Memory leak caused by WebView

WebView has a memory leak problem. Once a WebView is used in an application, the memory will not be released.

Solution:

Start an independent process for WebView and use AIDL to communicate with the main process of the application. The process where WebView is located can be destroyed at an appropriate time according to the needs of the service to achieve the purpose of normal memory release.

conclusion

In general, objects with a long life cycle hold objects with a short life cycle. As a result, objects with a short life cycle cannot be released during collection, resulting in memory leaks.

Understanding common memory leaks and their solutions can help minimize memory leaks in your development. However, it is difficult to locate and troubleshoot some memory leaks. You need to use some tools, such as LeakCanary and MAT. The troubleshooting and locating methods of memory leaks will be introduced in subsequent articles. Please continue to pay attention to them.

Long press to identify concerns