Android Memory leakage

Android Memory leakage

 

 

The stack size of the android application is limited to 16 MB on T-Mobile G1, which is a huge memory for a Mobile phone, but it is not enough for some developers. Even if you do not need to use so much memory space, you should try to save it as much as possible, so that you will not be killed when other applications are running. The more applications that Android can cache in the memory, the smoother the switching between applications. As part of my work, I have a deep understanding of the Memory leakage problem of Android applications, it is found that most of the cases are the same-keep a reference to a Context for a long time (keep a long_lived reference to a Context ).

In Android, Context is required for many operations. However, the vast majority of operations are resource acquisition and loading. This is why all controls need to receive a Context parameter in the constructor. Generally, we can obtain two types of Context, Activity, and Application. Developers usually pass the first Activity as a parameter.

 

@Overrideprotected void onCreate(Bundle state) {  super.onCreate(state);    TextView label = new TextView(this);  label.setText(Leaks are bad);    setContentView(label);}

This means that the view holds the reference of the entire Activity and everything in it, such as the whole view hierarchy and all resources. Therefore, if you leak Context ("leakage" means that you keep its reference so that GC cannot be recycled in time), you will leak a large portion of the memory. If you are not careful enough, it is easy to leak the entire activity.

 

When the screen direction changes, the system will default the current destroy activity, save the current status and create a new activity, that is, Android will re-load the view of the application from the resource file. Imagine that your application has a large image, but it does not reload the screen every time you rotate it. The easiest way to cache it in the memory is to declare it as static:

 

private static Drawable sBackground;@Overrideprotected 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);}

The above code runs very fast, but the practice is wrong. When the screen rotates, the whole activity is leaked. When a Drawable is associated with the view, the view is set to a callback of drawable, in the code above, this means that drawable maintains the reference of TextView, while TextView maintains the reference of the entire Activity, and almost associates with everything in the activity.

 

This example is the simplest case of Context leakage, you can see in the source code of HomeScreen how we solve this problem by setting drawable callback to null (search for the unbindDrawables () method). Interestingly, sometimes a call chain that leaks the context is created, which will consume your memory more quickly.
There are two simple ways to avoid Memory leakage related to the context. One is to prevent the context from escaping from its own scope (avoid escaping the context outside of its own scope ), the above example shows the leakage caused by static reference, but the strong reference of internal class to external class is also dangerous. Another solution is to use Application context, which will always exist until your Application exits without relying on the activity lifecycle. If you have an object that has been alive for a long time and the object has a reference to context, remember to use application context. You can easily use Context. getApplicationContext () or Activity. getApplication.
In short, to avoid Memory leakage related to context, remember the following
Do not keep reference to the activity context type for a long time (a reference to the activity should have the same lifecycle as this activity) use application context instead of activity context to avoid using non-static internal classes in an activity. If you do not care about its lifecycle, use a static internal class, then, a weak reference to the activity is maintained within the class, just like the W internal class in the ViewRoot class. Garbage collection does not guarantee Memory leakage