How to Avoid Android Memory leakage

At least the size of memory allocated by the Android app on T-Mobile G1 on the stack is limited to 16 Mb. For mobile phones, this is not a small memory, but it is still far from meeting the needs of some developers. However, even if you do not plan to use all the memory space, you should use as little memory as possible so that other applications can run rather than be killed. Because android can maintain more applications in the memory, the faster the user switches the application. As part of my work, I am also prone to memory leakage when developing Android applications. Most of the time, memory leakage is due to the same error: A reference of context is held for a long time.

On Android, context can be used for many operations, but most of the time it is used to load and use resources. This is why all widgets accept a context parameter in their constructor. In general Android applications, you usually have two kinds of Context: Activity and application. Normally, when our classes and methods need to use context, we pass the context of activity:

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

This means that views has a reference to the entire activity, that is, to reference everything that your activity has. Normally, this refers to the complete view hierarchy and all its resources. Therefore, if you leak a context ("leak" means that you keep a reference of it so that it cannot be recycled by the garbage collection mechanism ), it means that you have leaked a lot of memory. If you are not careful, it is really easy to leak all the resources of an activity.

When the screen direction changes, the system will destroy the current activity by default and create a new activity while maintaining the original state. At this time, Android reloads the application UI from the resource. Now, imagine that you have written an application that has a large bitmap. You don't want to reload it every time you rotate it. The simplest way to make bitmap continue to function and not reload in every direction is to put it into a static domain:

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);}

This code is fast, but the error is also very serious: it leaks the first activity, the activity created when the screen changes for the first time. When a drawable is associated with a view, this view is equivalent to a callback set on the drawable. In the code snippet above, this indicates that drawable has a reference to textview, and this textview has a reference to the activity (context ), the activity References almost everything in sequence (depending on your code ).

This example shows the simplest context leakage. You can see in the source code of home screen how we solve this problem (find the unbinddrawables () method ), this is to set the callback of drawables to null when the activity is destroyed. Interestingly, you may create many context leaks, which are very bad. They will cause your memory overflow quickly.

There are two simple methods to avoid Memory leakage related to context. The most notable one is to prevent context from escaping from its own range. The above example shows the use of static references, and the implicit references of internal classes and their external classes are equally dangerous. The second method is to use application context. The life cycle of this context is as long as that of your application, rather than depending on the life cycle of the activity. If you want to keep a long-lived object that requires a context, remember to use the application object. You can call context. getapplicationcontext ()
Or activity. getapplication.

To avoid Memory leakage related to context, remember the following points:
· Do not reference the context of an activity for a long time (the reference lifecycle of an activity should be the same as that of the activity)
· Try to use the context of application to replace the context related to activity.
· If the lifecycle of an acitivity non-static internal class is not controlled, avoid using it. Use a static internal class and use a weak reference for the activity. The solution to this problem is to use a static internal class and have a weakreference for its external class, as in the internal class W of viewroot, this is an example.
· The Garbage Collector cannot protect against memory leaks.