Android Memory leakage: android Memory leakage

Android Memory leakage: android Memory leakage
1. Memory leakage caused by resource object not being closed
Resource objects, such as Cursor and File files, usually use some buffer. When they are not used, they should be closed in time so that their buffer can be recycled in time. Their buffering not only exists in the Java virtual machine, but also exists outside the Java Virtual Machine. If we only set its reference to null without shutting them down, it will often cause memory leakage. Because there are some resource objects, such as SQLiteCursor (in the Destructor finalize (), if we didn't close it, it will call close () itself). If we didn't close it, the system also disables it when it is recycled, but this is too inefficient. Therefore, when the resource object is not used, it should call its close () function, close it, and then set it to null. make sure that our resource object is closed when our program exits.
The program usually queries the database, but it often does not close after using the Cursor. If our query result set is small, memory consumption is not easy to find. Memory problems can be reproduced only when a large number of operations are performed at a regular time, this will cause difficulties and risks for future testing and troubleshooting.
Sample Code:
Cursor cursor = getContentResolver (). query (uri ...);

If (cursor. moveToNext ()){
......
}
Corrected sample code:
Cursor cursor = null;
Try {
Cursor = getContentResolver (). query (uri ...);
If (cursor! = Null & cursor. moveToNext ()){
......
}
} Finally {
If (cursor! = Null ){
Try {
Cursor. close ();
} Catch (Exception e ){
// Ignore this
}
}
}
2. When constructing the Adapter, the cached convertView is not used
The following describes how to construct the BaseAdapter of a ListView:
Public View getView (int position, ViewconvertView, ViewGroup parent)

To provide ListView with the view object required by each item. Initially, the ListView will instantiate a certain number of view objects from the BaseAdapter based on the current screen layout, and the ListView will cache these view objects. When you scroll up the ListView, the view object originally located in the top list item will be recycled and then used to construct the bottom list item that appears. This construction process is completed by the getView () method, getView () the second View convertView parameter is the view object of the cached list item. (convertView is null if no view object is cached during initialization ). From this we can see that if we don't use convertView, but re-instantiate a View object in getView () every time, it will be a waste of resources and time, which will also increase the memory usage. You can view the process when ListView recycles the view object of list item:
Android. widget. AbsListView. java-> voidaddScrapView (View scrap) method.
Public View getView (int position, ViewconvertView, ViewGroup parent ){

View view = new Xxx (...);
......
Return view;
}
Corrected sample code:
Public View getView (int position, ViewconvertView, ViewGroup parent ){
View view = null;

If (convertView! = Null ){
View = convertView;
Populate (view, getItem (position ));
...
} Else {
View = new Xxx (...);
...
}
Return view;
}
3. Call recycle () to release memory when the Bitmap object is not in use
Sometimes we will manually operate Bitmap objects. If a Bitmap object occupies memory, when it is not in use, we can call Bitmap. the recycle () method recycles the memory occupied by pixels of this object, but this is not necessary, depending on the situation. Let's take a look at the comments in the Code:
/**
• Free up the memory associated with thisbitmap's pixels, and mark
• Bitmap as "dead", meaning itwill throw an exception if getPixels () or
• SetPixels () is called, and will drawnothing. This operation cannot be
• Reversed, so it shoshould only be called ifyou are sure there are no
• Further uses for the bitmap. This is anadvanced call, and normally need
• Not be called, since the normal GCprocess will free up this memory when
• There are no more references to thisbitmap.
*/
4. Try to use the context about the application to replace the context related to the activity.
This is an obscure memory leak. There is a simple method to avoid Memory leakage related to context. The most notable one is to prevent context from escaping from its own range. 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 obtain it by calling Context. getApplicationContext () or Activity. getApplication.

5. Memory leakage caused by registration not canceled
Some Android programs may reference the objects of our Anroid program (such as the registration mechanism ). Even though our Android program has ended, other reference programs still reference an object of our Android program, and the leaked memory cannot be recycled. UnregisterReceiver is not called after registerReceiver is called.
For example, if we want to listen to the telephone service in the system to obtain some information (such as signal strength) on the LockScreen interface, we can define a PhoneStateListener object in LockScreen, register it with the TelephonyManager service. For LockScreen objects, a LockScreen object is created when the screen lock interface needs to be displayed. When the screen lock interface disappears, the LockScreen object is released.
However, if you forget to cancel the previously registered PhoneStateListener object when releasing the LockScreen object, LockScreen cannot be reclaimed. If the screen lock interface is constantly displayed and disappears, a large number of LockScreen objects cannot be recycled, causing OutOfMemory and causing the system_process process to crash.
Although some system programs can automatically cancel registration (of course not timely), we should explicitly cancel registration in our program, when the program ends, all registration should be canceled.

6. Memory leakage caused by uncleanup of objects in the collection
We usually add some object references to the collection. When we don't need this object, we didn't clear its references from the collection, so this set will become larger and larger. If the set is static, the situation is more serious.