Android avoids Memory leakage

1. The database cursor is not closed.
2. No cache contentview is used to construct the adapter.
Derivative listview optimization problem: Reduce the number of objects for creating a View and make full use of contentview. You can use static classes to optimize the getView process.
3. Use recycle () to release the memory when the Bitmap object is not in use
4. The object lifecycle in the Activity is greater than that in the Activity
Mode: DDMS> HEAPSIZE> adtaobject> total size
 
 
Android applications are limited to run on 16 MB stacks, at least on T-Mobile G1. For mobile phones, this is a lot of memory, but for some developers, this is relatively small. Even if you do not plan to use all the memory, you should use as little memory as possible to ensure that other applications can run. Android retains more applications in the memory. for users, inter-program switching can be faster. As part of my (English author) work, I investigated the memory leakage of Android applications and found that most of these memory leaks were caused by the same errors, namely: references the Context for a long time.

In Android, Context is often used for many operations, and more often it is to load and access resources. This is why all widgets accept a Context parameter in their constructor. In a normal Android Application, you can see two Context types: Activity and Application. Generally, in the class and method that requires a Context, the first type is often introduced:
Java code
@ Override

Protected void onCreate (Bundle state ){

Super. onCreate (state );



TextView label = new TextView (this );

Label. setText ("Leaks are bad ");



SetContentView (label );

}
 
This means that the View has reference to the entire Activity and all the content of the Activity itself; generally, the whole View level and all its resources. Therefore, if you "leak" Context ("leak" means that you keep a reference to prevent GC garbage collection), you will leak a lot of memory. If you are not careful enough, it is easy to leak an Activity.

When the screen direction changes, the system will usually destroy the current Activity, create a new Activity, and save its status. When the system does this, Android reloads the application UI from the resource. Suppose the application you write has a large bitmap, and you don't want to reload it every time you rotate it. Here is the simplest way to save it in a static field:
Java code
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 );
}
 
This code is very efficient, but it is extremely incorrect at the same time. During the first screen direction switch, it exposes the Activity created at the beginning. When a Drawable is appended to a View, the View sets it as a callback to the Drawable. The code snippet above means that Drawable has a reference to TextView, while TextView has reference to Activity (Context type). In other words, drawable has more object references (dependent on your code ).

This is one of the examples of the most vulnerable to Context leakage. You can check how the unbindDrawables () method is searched in the source code of Home Screen: when the Activity is destroyed, set the callback of the stored Drawable to null. Interestingly, there are a series of Context leaks, which are very bad. These situations will make the application quickly run out of memory.

There are two simple methods to avoid Memory leakage related to Context. The most obvious way is to avoid extending the Context beyond its own range. The static references provided in the above example code, as well as internal classes and their external class implicit references are also very dangerous. The second solution is to use the Context type of Application. This Context has the same long life cycle as the application and does not depend on the Activity life cycle. If you want to save a long object and need a Context, remember to use the Application object. You can easily obtain the Application object by calling Context. getApplicationContext () or Activity. getApplication.

To avoid Memory leakage related to Context, remember the following:

Do not retain reference to Context-Activity for a long time (Make sure that you have the same lifecycle as Activity when referencing Activity)

Try to use Context-Application instead of Context-Activity

If you do not want to control the lifecycle of internal classes, do not use non-static internal classes in the Activity, instead use static internal classes, create a weak reference to the Activity. The solution to this problem is to use a static internal class with the WeakReference of the external class, as shown in ViewRoot and its Winner class.

GC (garbage collection) cannot solve the memory leakage problem