Reasons for Android memory leaks

1. Memory leak due to resource object not shutting down

resource objects such as (cursor,file files, etc.) often use some buffering, we should close them in time when we are not in use, so that their buffers can recover memory in time. Their buffering exists not only in the Java Virtual machine, but also outside the Java Virtual machine. If we simply set its reference to null without shutting them down, it often causes a memory leak. Because some resource objects, such as Sqlitecursor (in the destructor Finalize (), if we do not close it, it itself will close () closed), if we do not close it, the system will be recycled it also closed it, but this is too low efficiency. Therefore, when the resource object is not in use, it should call its close () function, close it, and then set it to null. Be sure that our resource objects are closed when our program exits.
The process of querying the database is often done, but there are often cases where the cursor is not closed after it has been used. If our query result set is relatively small, the memory consumption is not easy to find, only in a large number of times in the case of frequent operations to reproduce the memory problem, which will give future testing and troubleshooting difficulties and risks

Example code: [Java]cursor Cursor = Getcontentresolver (). Query (Uri ...);  if (Cursor.movetonext ()) {    ...    }  Fix example code: [Java]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 adapter, no cached Convertview is used  to construct the baseadapter of the ListView as an example, Methods are provided in Baseadapter: public view getView (int position, Viewconvertview, ViewGroup Parent) to provide the ListView with the View object required for each item. Initially, the ListView instantiates a certain number of view objects from the Baseadapter based on the current screen layout, and the ListView caches the View objects. When you scroll up the ListView, the View object that was originally on the top list item is recycled and then used to construct the newly-appearing list item. This construction process is done by the GetView () method, and the second parameter view convertview of GetView () is the view object of the cached list item (the cache does not have a view object when it is initialized, and Convertview is null.) )。 It can be seen that if we do not use Convertview, but each time in GetView () to re-instantiate a view object, that is, wasting resources is also a waste of time, will also make memory consumption more and more

<span style= "FONT-SIZE:18PX;" >[java]public view GetView (int position, Viewconvertview, ViewGroup parent) {    View view = new Xxx (...);    ... ...    return view;  }  Fix example code: [Java]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;  }  </span>

3. Bitmap object does not call recycle () to free memory when it is in use

Sometimes we will manipulate the bitmap object manually, if a bitmap object compares memory, when it is not in use, you can call the Bitmap.recycle () method to reclaim the memory occupied by the pixel of this object, but this is not required

4, try to use the context of the application to replace and activity-related context

This is a very cryptic case of a memory leak. There is an easy way to avoid context-related memory leaks. The most notable one is to avoid the context escaping from his own range. Use Application context. The life cycle of this context is as long as your application's life cycle, not the activity's life cycle. If you want to keep a long-lived object, and this object needs a context, remember to use the Application object. You can get the Context.getapplicationcontext () or activity.getapplication () by calling

5. Memory leaks due to registration not canceled

Some Android programs may refer to the objects of our Anroid program (such as the registration mechanism). Even though our Android program is over, other reference programs still have a reference to an object in our Android program, and the leaked memory is still not garbage collected. Unregisterreceiver was not called after calling Registerreceiver.

Reasons for Android memory leaks