Android avoids Memory leakage: Use getcontext () and getapplication () properly ()

The maximum heap memory used by Android applications is 16 MB (Note: The heap memory is also related to the performance of devices, and the available heap memory for devices with high performance may be 24 MB or higher ), the telephone function takes up part of the call, but developers have limited access to it. If you do not plan to use all the memory, your application should use as little memory as possible, so that other programs will not be killed at runtime. The more applications the Android system can hold in the memory, the faster the user switches between programs. As part of my work, I studied the memory leakage problem in Android applications and found that most of the cases were caused by the same problem: holding a long reference to context.

In Android, context is used in many operations, but mostly to load or access resources. This is why all widget components receive a context parameter in the constructor. For general Android applications, there are usually two kinds of Context: Activity and application. Developers usually need to select activity when context is passed between classes or methods.


This indicates that views has a reference to the entire activity. Therefore, everything in your activity will be held by views. Generally, it is held by view level and corresponding resources. Therefore, if you leak context (leakage: that is, you hold a context reference and the result stops GC from reclaiming it), you will leak some memory. If you are not careful, disclosing an activity will become very easy.

When the screen direction changes, the system saves its status by default, destroys the current activity, and creates a new one. To achieve this, Android reloads the application UI from the resource. Now, if you develop an application that contains a large number of bitmaps, you do not want to load bitmaps every time you switch the screen. The simplest method is to use static fields.


The above code is very concise, but it is also prone to errors: when the screen direction changes for the first time, the initial activity (the activity will be re-created every time the screen changes) will cause memory leakage. When a drawable object is attached to a view, the view is set as the callback on the drawable object. The code snippet above indicates that drawable has a reference to textview, while textview itself has a reference to activity (that is, context). In turn, activity also holds references to many things (depending on your code ).

The above example is the simplest case of leaking context. You can
The source code of screen (find the unbinddrawables () method) shows how we solve it: when the activity is destroyed, set the callback of the stored drawable to null. Interestingly, when you create a series of memory-exposed context, many situations may occur, and they are all bad. They quickly cause memory overflow during the running process.

There are two simple ways to avoid Memory leakage related to context. The most obvious one is to avoid context exceeding its range. The above example shows the situation of static reference: indirect reference of internal classes and external departments is very dangerous. The second solution is to use application. This context does not depend on the life cycle of the activity, but lives together with your application. If you want to hold a long-lived object that requires Context Reference, remember to use the application object. You can call context. getapplicationcontext () or activity. getapplication () to obtain it.

In general, to avoid Memory leakage related to context, remember the following:

• Do not make long-term reference to the activity (the activity inherits from the context) (a reference pointing to the activity has the same lifecycle as the activity itself );

• Try to replace activity with application;

• If you cannot control the lifecycle of internal classes and avoid using non-static internal classes, you should use static internal classes and make weak references to the activities in them. The solution to this problem is: for external classes, construct static internal classes using weakreference, and complete them at the view root, and its weakreference internal class must have an instance (weakreference ).

• Garbage collection is not an insurance method to prevent memory leakage.

From: http://blog.csdn.net/snow4dev/article/details/7555130