Andorid Volley frame loading picture oom problem analysis

I. Introduction to the Volley framework

before this, we need to communicate with the network in the program, the general use of things like Asynctaskloader,httpurlconnection,asynctask,httpclient (Apache), Google At the I/O Conference in 2013, volley was released. Volley is a network communication library on the Android platform that makes network communication faster, simpler, and more robust.

Volley provides the request form of jsonobjectrequest, jsonarrayrequeststringrequest, etc.

Jsonobjectrequest: Return JSON object

Jsonarrayrequest: Returns Jsonarray.

Stringrequest: Returns a string so that it can handle data on its own and is more flexible

You can also inherit custom request.

Second, volley caused by the Oom project used to volley download network pictures, in the callback to get to bitmap do the corresponding operation.

Imagerequest imagerequest = new Imagerequest (url+ "--" + bmwidth+ "x" +bmwidth+ ". png", New RESPONSE.LISTENER< ;                        Bitmap> () {@Override public void Onresponse (Bitmap response) {                    Initviewwithbitmap (response);        }}, 0, 0, Bitmap.Config.RGB_565, getimageerror); Mqueue.add (imagerequest);

Initially found in this interface operation even first strong-off problem, caught log see is outofmemory caused.

Since this interface is used more bitmap, manually release bitmap in the Ondestoy () method.

Using the memory Viewer to observe the memory of the interface, and found that every time after entering the exit, the memory is not completely released, about 6M each time

Three, the problem analysis

Tools: Mat Memory Analysis Tool

Use the Mat memory analysis tool to find out why memory is not released

The discovery is that the context is not released, causing a memory leak, continuing the analysis, and finding a place where the GC is not kept by that reference

Finding the shortest GC path, it is found that volley Cachedispacher maintains a reference to the context, resulting in no GC free memory.

But how does something in the volley frame cause this problem?

The first thought was to cancel out the request that was not loaded in the OnDestroy. But no effect.

Google has a half-day, finally found the answer on the StackOverflow, the approximate meaning is to initialize the requestqueue when try to use the global context is applicationcontext.

Otherwise, no activity is required to maintain a volley request queue, as well as a distribution thread, a request thread, and a cache thread.

This results in a context reference to the activity within the volley framework, that is, when the life cycle of our activity is over, there may still be a reference to the context in volley that is still in the child thread, Causes no memory reclamation.

Iv. Methods of Solution

First, we want to keep the only volley requestqueue in the project, using a singleton pattern to implement

public class Singlerequestqueue {

    private static Requestqueue Mqueue;    Private Singlerequestqueue (Context context) {        Mqueue = volley.newrequestqueue (context);    }    public static synchronized Requestqueue Getrequestqueue (context context) {        if (mqueue = = null) {            NEW Singlerequestqueue (Context.getapplicationcontext ());        }        return mqueue;}    }

Handle network requests in a unified class.

In addition, see the online comment said when loading large network pictures when the use of volley is not recommended, I use Universalimageloader.

Recommend an article explaining the context of Android. Point here

Summarize:

The issue of context memory leaks has not been encountered before, and this problem is a good way to compensate for this gap

Through the analysis of this problem, it deepens the analysis of memory leak, and also strengthens the use of Mat memory analysis tool.

Andorid Volley frame loading picture oom problem analysis