What happens to memory leaks __ memory leaks

1. Memory leaks caused by not shutting down resource objects

Description: Resource objects such as (cursor,file files, etc.) tend to use a number of buffers, we do not use, we should close them in time, so that their buffer in time to reclaim memory. Their buffering exists not only in the Java Virtual machine, but also outside the Java Virtual machine. If we simply set its references to null without shutting them down, this can often result in a memory leak. Because some resource objects, such as Sqlitecursor (in the destructor Finalize (), if we do not close it, it will turn close () closed), if we do not close it, the system will also close it when it is recycled, but this is too inefficient. Therefore, when the resource object is not in use, it should call its close () function, turn it off, and then null. Make sure that our resource objects are closed when our program exits. The operation of the query database is often done in the program, but there is often no shutdown after the cursor is used. If our query result set is relatively small, the memory consumption is not easy to find, only in the case of a large number of times to reproduce the memory problem, which will give future testing and troubleshooting problems and risks.

2. When constructing adapter, no cached Convertview is used

Description: For example, the baseadapter of constructing ListView is provided in Baseadapter: public View getview (int position, Viewconvertview, viewgroup parent) To provide ListView with the View object that each item requires. Initially ListView will instantiate a certain number of view objects from the Baseadapter based on the current screen layout, and ListView will cache the view objects. When the ListView is scrolled up, the View object originally located at the top of the list item is reclaimed and then used to construct the newly appearing bottom list item. This construction process is done by the GetView () method, and the second parameter view of GetView () is the view object of the cached list item (the cache does not have a view object when it is initialized Convertview is null )。 It can be seen that if we do not use Convertview, but each time in the GetView () to instantiate a view object, that is, waste resources and waste of time, will also make the memory footprint more and more big. ListView the procedure for retrieving the View object of the list item to view: Android.widget.AbsListView.java--> voidaddscrapview (View scrap) method. Sample code:

<code class= "Language-none" >public view getview (int position, Viewconvertview, ViewGroup parent) {
View view = New Xxx (...); 
... ... 
return view; 
} </code>

To fix the sample code:

<code class= "Language-none" >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; 
} </code>

3.Bitmap Object calls recycle () to free memory when used

Description: Sometimes we will manually manipulate the bitmap object, if a bitmap object is compared to 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 necessary, depending on the situation. You can look at the comments in the code:

/** free up the memory associated with Thisbitmap's pixels, and mark the bitmap as "dead", meaning itwill, throw an excep tion if getpixels () or setpixels () is called, and would drawnothing. This is operation cannot be reversed, so it should only is called ifyou are sure there are the no further for the uses. This is anadvanced call, and normally need not be called, since the normal gcprocess'll free up this memory when there Are no more references to Thisbitmap. */

4. Try to use the context of the application to substitute for activity related

This is a very vague case of a memory leak. There is an easy way to avoid context-related memory leaks. One of the most significant is to avoid the context escaping from his own range. Use the application context. The life cycle of this context is as long as the life cycle of your application, not depending on the life cycle of the activity. If you want to keep a long standing object, and the object needs a context, remember to use the Application object. You can get it by calling Context.getapplicationcontext () or activity.getapplication (). For more, see how this article avoids the Android memory leak.

5. Registration does not cancel the memory leak caused by

Some Android programs may refer to our Anroid program's objects (such as registration mechanisms). Even though our Android program is over, other references still have a reference to an object of our Android program, and the leaking memory is still not garbage collected. Unregisterreceiver is not invoked after calling Registerreceiver. For example: Suppose we want to listen to the telephony service in the system to get some information (such as signal strength, etc.) in the Lock screen Interface (lockscreen), you can define a Phonestatelistener object in Lockscreen. Register it with the Telephonymanager service at the same time. For Lockscreen objects, a Lockscreen object is created when a lock screen interface is required, and the Lockscreen object is released when the lock screen interface disappears. However, if you forget to cancel the Phonestatelistener object that we previously registered when releasing the Lockscreen object, it will cause lockscreen to be garbage collected. If the lock screen is constantly displayed and disappeared, it will eventually be due to a large number of Lockscreen objects can not be recycled to cause outofmemory, so that the system_process process hangs. Although some system programs, it seems to be able to automatically cancel registration (of course, not timely), but we should be in our program to explicitly cancel the registration, the end of the program should be all the registration canceled.

6. Memory leaks caused by no cleanup of objects in the collection

We usually add a reference to a set of objects, and when we don't need the object, we don't clean it out of the collection, so the collection gets bigger. If the set is static, the situation is even more serious.