Memory leak lookup in Android with common memory leak case analysis

Common memory leak lookup methods see: http://hukai.me/android-performance-patterns/

This article is an example of Google's release of the Android performance optimization paradigm, which provides a good demonstration of rendering, memory GC, and power consumption.

Here I summarize the following, common memory leaks in Android

1. Unregisterreceiver () is not called after calling Registerreceiver in the class.

After calling Registerreceiver, if Unregisterreceiver is not called, the amount of memory it occupies is quite large.

This is often the case when we dynamically register receiver in activity or service, and the dynamically registered receiver is placed in a map in application, which is held in the lifetime of application, in which case Equivalent to holding a reference to the activity, which results in a memory leak.

2. Memory leaks due to resource object not shutting down

Typically, using the SQLite database does not release the cursor and network file IO using Inputstreamoutputstream Remember to call the Close method.

In Android, the cursor is a very common object, but in writing the code is often someone forgets to call close, or because the code logic problem condition causes close to not be called----put the close statement into the finally code.

Typically, in activity, we can call startmanagingcursor or use Managedquery to let activity automatically manage cursor objects.

However, it is important to note that the cursor will no longer be available when the activity is introduced!

If the code and UI for manipulating the cursor are out of sync (such as a background thread), there is no need to first determine if the activity has ended, or wait for the background thread to end before calling OnDestroy.

3, Bitmap not call recycle () after use

Calling recycle is not required, as described in the SDK. But in actual use, bitmap occupies a large amount of memory, so when we no longer use, try to call recycle () to release resources.

4. When constructing adapter, no cached Convertview is used

To construct the baseadapter of a ListView, for example, a method is provided in Baseadapter:

Public View GetView (int position, Viewconvertview, viewgroup parent)

To provide the ListView with the View object that each item needs. 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 the GetView () to re-instantiate a view object, that is, wasting resources is also a waste of time, it will also make memory consumption more and more. This situation is not necessarily caused by a serious memory leak, which can cause memory jitter, after all, GC Reclaim memory also requires CPU resources. The process of retrieving the View object of the list item can be viewed by the ListView:

Android.widget.AbsListView.java--Voidaddscrapview (View scrap) method.

5, 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 it by calling Context.getapplicationcontext () or activity.getapplication ().

To summarize, to avoid context-related memory leaks, keep the following in mind:

· Do not long-term references to activity's context (the lifetime of an activity reference should be the same as the life cycle of the activity)

· Try to use context about application instead of activity-related context

· If the life cycle of a acitivity non-static inner class is not controlled, then avoid using it; use a static inner class and use a weak reference to the activity in it. The solution to this problem is to use a static inner class, and have a weakreference to its outer class, just as in the case of inner class W in Viewroot.

6. Memory leak caused by object not cleaned in collection

We usually add references to some objects to the collection, and when we don't need the object, we don't clean up its references from the collection, so the collection gets bigger. If the set is static, the situation is even worse.

7, callback callback and listener timely release.

For example, if an activity passes a listener to a service, then the service holds a reference to the activity, if the service is a public service component, This activity has not been able to cause a memory leak by GC recycling.

Memory leak lookup in Android with common memory leak case analysis