Reputation: 705
I'm using volley to get a JsonObject from a URL. My problem is that often I get an OutOfMemory Exception. I used to MAT to analyze the memory leaks and I see that the whole object on response after downloaded and used it is still on memory. What I'm doing wrong?
Volley Code
JsonObjectRequest jsonObjReq = new JsonObjectRequest(Request.Method.GET,
url, null,
new Response.Listener<JSONObject>() {
@Override
public void onResponse(JSONObject response) {
item = parser.parse(response);
updateLayout();
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
bar.setVisibility(View.GONE);
if(!isNetworkAvailable()){
Toast.makeText(act, "No Internet Connection.", Toast.LENGTH_SHORT).show();
}
else{
Toast.makeText(act, "The Server Is Down. Try Again.", Toast.LENGTH_SHORT).show();
}
}
});
// Adding request to request queue
VolleySingleton.getInstance().addToRequestQueue(jsonObjReq);
MAT screenshot
Upvotes: 2
Views: 2060
Reputation: 155
After finising my app leak search, I finally understand why volley keeps request in memory . In my case, I use volley singleton mode. Volley has 4 threads do network dispatch, and each thread keeps a request.
when you do more than 4 times request, there will always be 4 requests keep in memory. without other leak problem ,request would not raise . Usually, we use new Anonymous Inner Class request , which will keep a strong reference to outer class . so we will see Activity not GC after onDestory().
As a result, Volley not have big problem, if you do not want request Keep strong reference to your class ,so use weakReference. Your OOM problem must be something else caused.
Upvotes: 1
Reputation: 18977
Ok i think your problem is here:
Network dispatcher is a thread that his duty is to send the request to the server and getting results, he manages the http connection and he is your outside interface, so each objects in this thread is those who their request are in the flight and have been sent to the server and are waiting to get back the result , these are other requests no the one that you get the result in on response. Network response is the one that manages parsing the response and delivers it to you after response delivered to network dispatcher. i suggest you to look at the source code to better understand this beautiful framework. i think your problem is coused by parser or your long json so you can eliminate it by providing bigger cache for volley or another joson parser technique.
Update:
i mean that those hashmaps are not memory leak, those are your other requests to the server, you have not specify any memory leak in your image. what you have shown on the picture is your other requests that you sent to volley. when you send your request to this library, this library creates multiple request connections to the server to make your network operation be speedy. those multiple requests take time to go from your device to the server and come back with response. those request and connection are all managed by network dispatcher. it makes multiple connections and sends requests to the server. so what you see on the image is those requests that have not gotten results yet from server. so those 3 items must be into the memory because those are requests that you want the results for them.
after you exit from response block {} imean last brace your response automatically removed from memory, so do not worry about your response. i think your problem dose not relate to volley buges or any thing else about this library. i think you must check other aspect of your apps like the method of parsing json or ...
Upvotes: 2