Summary of Android Memory overflow (out of Memories)

Memory overflows are mainly caused by the following scenarios:

1. The cursor of the database is not closed.

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

3. Unregisterreceiver () is not called after calling Registerreceiver.

4. Inputstream/outputstream is not turned off.

Recycle () was not called after 5.Bitmap was used.

6.Context leakage.

The first 5 kinds of situations are easy to find and solve, as long as the shut off in a timely manner, the call method calls, there will be no too many problems, in addition Java also has soft references to help manage memory:

softreference<bitmap>new softreference<bitmap>(pbitmap); if NULL ) {ifnull &&!  null;}}

The following highlights the context leaks.

This is a very cryptic case of memory leaks. Let's look at an example from the Android website:

 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   = getdrawable (R.DRAWABLE.LARGE_BITMAP);  } label.setbackgrounddrawable (Sbackground); Setcontentview (label);}  

This code is very efficient, but at the same time extremely wrong; it leaks the activity that was created at the start of the first screen orientation. When a drawable is attached to a view, the view sets it as a callback on the drawable. The code snippet above means that drawable has a textview reference, and TextView has a reference to the activity (context type), in other words, drawable has more 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 application as the context type. This context has the same long life cycle as the application and does not depend on the activity's life cycle. If you are going to save 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 in the non-stop.

Summarize the issues you should be aware of to avoid a context leak:

1. Use application for this type of context.

2. Note that the reference to the context does not exceed its own life cycle.

3. Use the "static" keyword carefully.

4.Context if the thread, must be in OnDestroy () in time to stop.

Summary of Android Memory overflow (out of Memories)