Android Memory leak optimization Rollup

Android Memory leak optimization Summary blog Category: Android
Android Memory overflow OutOfMemoryError.
The memory allocations for Android mobile apps are generally 8 Catherine, which incorrectly assumes handling memory handling is very easy to create outofmemoryerror. Our product is the most common error is the OutOfMemoryError anomaly,
In solving this anomaly, I found a lot of information about OutOfMemoryError on the Internet.
OutOfMemoryError is mainly caused by the following conditions:
1. The cursor of the database is not closed.
When you manipulate the SQLite database, the cursor is a collection of each row in the database table, and the cursor provides a number of ways to easily read the values in the database.
Ability to base indexes. The column name, etc. gets the value in the database, which can be called by a cursor to move to the next line MoveToNext ()
When we have finished working with the database. Be sure to call Close () of the cursor object to dismiss the cursor and release the resource.

2. The construction adapter does not use the cache contentview.

When inheriting Baseadapter, let's rewrite the getview (int position, View Convertview, ViewGroup Parent) method.
The second parameter, Convertview, is the reusable object we're going to use.

Java code
[Email protected]
2.public view GetView (int position, view Convertview, ViewGroup parent) {
3. Viewholder vholder = null;
4.//Assume that the Convertview object is empty to create a new object, not NULL to reuse
5. if (Convertview = = null) {
6. Convertview = Inflater.inflate (..., null);
7.//Create Viewhodler Object
8. Vholder = new Viewholder ();
9. vholder.img= (ImageView) Convertview.findviewbyid (...);
vholder.tv= (TextView) Convertview
One by one: Findviewbyid (...);
12.//save Viewhodler to tag
Convertview.settag (Vholder);
.} else {
15.//When the Convertview is not empty, the view is obtained by Gettag ()
Vholder = (Viewholder) convertview.gettag ();
17.}
18.//Assign a value to the object. Change the displayed value
VHolder.img.setImageBitmap (...);
VHolder.tv.setText (...);
. return Convertview;
22.}
23.//Package The displayed view into a class
24.static class Viewholder {
TextView TV;
ImageView img;
27.}
@Override
Public View GetView (int position, View Convertview, ViewGroup parent) {
Viewholder vholder = null;
Create a new object if the Convertview object is empty, or reuse it for null
if (Convertview = = null) {
Convertview = Inflater.inflate (..., null);
Create a Viewhodler object
Vholder = new Viewholder ();
Vholder.img= (ImageView) Convertview.findviewbyid (...);
vholder.tv= (TextView) Convertview
. Findviewbyid (...);
Save Viewhodler to Tag
Convertview.settag (Vholder);
} else {
When Convertview is not empty, the view is obtained by Gettag ()
Vholder = (Viewholder) convertview.gettag ();
}
Assigning values to objects, changing the displayed values
VHolder.img.setImageBitmap (...);
VHolder.tv.setText (...);
return convertview;
}
Wrap the displayed view into a class
Static Class Viewholder {
TextView TV;
ImageView img;
}
Here is just the usage, detailed performance test article see:
The principle of GetView in the ListView + How to place multiple item in the ListView
Http://www.cnblogs.com/xiaowenji/archive/2010/12/08/1900579.html
Android development for the ListView adapter (Adapter) optimization
http://shinfocom.iteye.com/blog/1231511
3. Unregisterreceiver () is not called after calling Registerreceiver ().
Broadcast receivers (Broadcastreceiver) are often used in applications. Ability to send broadcast notification UI updates after multi-threaded tasks, and to receive system broadcasts for some functions
The ability to register by code:
Intentfilter postfilter = new Intentfilter ();
Postfilter.addaction (Getpackagename () + ". Background.job");
This.registerreceiver (receiver, postfilter);
When we use the Registerreceiver () method in our activity, we register the Broadcastreceiver. Be sure to call the Unregisterreceiver () method during the activity's life cycle to cancel the register
This means that the registerreceiver () and Unregisterreceiver () methods must appear in pairs, and usually we can rewrite the activity's Ondestory () method:

Java code
[Email protected]
2.protected void OnDestroy () {
3. This.unregisterreceiver (receiver);
4. Super.ondestroy ();
5.}
@Override
protected void OnDestroy () {
This.unregisterreceiver (receiver);
Super.ondestroy ();
}
4. Inputstream/outputstream is not turned off.
This is not much to say, we finished the input and output stream to close the flow
Recycle () was not called after 5.Bitmap was used.

Bad image processing is another number one cause of memory overflow, (also reflected in our products),

After we have finished processing the picture, we can retrieve the picture object by calling the Recycle () method.


Java code
1.if (!bitmap.isrecycled ())
0.9
3. Bitmap.recycle ()
4.}
if (!bitmap.isrecycled ())
{
Bitmap.recycle ()
}

Besides:
Using ImageView directly shows that bitmap consumes more resources. Especially when the picture is large, it can cause a crash.
Using Bitmapfactory.options to set up insamplesize, this reduces the need for system resources.
The property value insamplesize indicates that the thumbnail size is one of a fraction of the original picture size, that is, assuming that the value is 2, the width and height of the thumbnails taken are all 1/2 of the original picture, and the image size is 1/4 of the original size.
Bitmapfactory.options bitmapfactoryoptions = new Bitmapfactory.options ();
Bitmapfactoryoptions.injustdecodebounds = true;
Bitmapfactoryoptions.insamplesize = 2;
Be sure to set it back to false, because we set it to true before
After setting Injustdecodebounds to True, DecodeFile does not allocate space, that is. Bitmapfactory decoded bitmap is null, but can calculate the length and width of the original image
Options.injustdecodebounds = false;
Bitmap bmp = Bitmapfactory.decodefile (Sourcebitmap, Options);
6.Context leakage.

This is a very vague case of outofmemoryerror. Let's look at an example from an Android website:

Java code
1.private static drawable Sbackground;
[Email protected]
3.protected void OnCreate (Bundle state) {
4. Super.oncreate (state);
5.
6. TextView label = new TextView (this);
7. Label.settext ("Leaks is bad");
8.
9. if (Sbackground = = null) {
Sbackground = getdrawable (R.drawable.large_bitmap);
11.}
Label.setbackgrounddrawable (Sbackground);
13.
Setcontentview (label);
15.}
private static drawable Sbackground;
@Override
protected void OnCreate (Bundle state) {
Super.oncreate (state);

TextView label = new TextView (this);
Label.settext ("Leaks is bad");

if (Sbackground = = null) {
Sbackground = getdrawable (R.drawable.large_bitmap);
}
Label.setbackgrounddrawable (Sbackground);

Setcontentview (label);
}

This code is very efficient, but at the same time it is extremely wrong.
It leaks the activity that was created at the start of the first screen orientation switch. When a drawable is attached to a view,
View will set it as a callback to drawable.

The code snippet above. means that drawable has a textview reference,
TextView also has a reference to the activity (context type). In other words, drawable has a lot of other object references. Even if the activity is destroyed, the memory is still not released.
In addition, a reference to a context that exceeds its own life cycle can also lead to a context leak. So try to use a context type like application.
Such a context has the same long life cycle as the application and does not depend on the activity's life cycle.

Suppose you're going to keep a long-time object,
And it needs a Context, remember to use the Application object. You can easily get application objects by calling Context.getapplicationcontext () or activity.getapplication ().
Recently encountered a situation caused a context leak, that is, when the activity is destroyed, there are other threads do not stop.
Summarize the issues you should be aware of to avoid a context leak:
1. Use a context type such as application.

2. Note that the reference to the context does not exceed its own life cycle.
3. Use the "static" keyword with caution.
4.Context is assumed to be a wired thread. Be sure to stop in OnDestroy () in time.

7.statickeyword
When a class member variable is declared static, it belongs to the class and not to the object. Suppose we would have a very large resource object (Bitmap. Context wait) declares static. Then these resources will not be recycled by the recycling target.
It will always be there. Therefore, use STATICKEYWORD member variable definitions with caution.

Android Memory leak optimization Rollup