凌空framewok请求保留在内存中的对象对象、内存、framewok

2023-09-03 22:30:24 作者:吃藕丑

我做这样一个凌空的请求:

I'm making a volley request in this way:

   public void makeRequest(BaseRequest request, Response.Listener<JSONObject> responseListener,
                            Response.ErrorListener errorListener) {
        if (Constants.DEBUG) Log.i(TAG, "Sending: " + request.getUrlRequest());
        JsonObjectRequest jsObjRequest = new JsonObjectRequest(METHOD, request.getUrlRequest(), null, responseListener, errorListener);
        // disable cache
        jsObjRequest.setShouldCache(false);
        jsObjRequest.setTag(mTag);
        mQueue.add(jsObjRequest);
    }

MTAG是一个类类型。我如果在其onCreate方法我称之为这个凌空请求的活动:

mTag is a Class type. I have an activity where on its onCreate method I call the volley request with this:

mVolleyManager.makeRequest(getRequest(), new Response.Listener<JSONObject>() {
        @Override
        public void onResponse(JSONObject response) {
            refreshLayout.setRefreshing(false);
            onEndLoading(response);
        }
    }, new Response.ErrorListener() {
        @Override
        public void onErrorResponse(VolleyError error) {
            refreshLayout.setRefreshing(false);
            onErrorLoading(error);
        }
    });

如果我开始打开和关闭的活动我一些时间,我的记忆中保持增长,直到它到达一个OOM错误。我试图与MAT一看,这里的结果是:

If I start open and closing the activity for a bunch of time, my memory keeps growing till it reaches an OOM error. I tried to have a look with MAT and here's the result:

看来凌空保存在内存中所有的请求,即使onResponse方法正确调用。我已经切换到改造解决了这个问题。同一code,都是相同的请求,它的工作,但我想知道这可能是我的问题的原因。

It seems that Volley keeps in memory all of its requests, even if the onResponse method is correctly called. I already solved the problem by switching to Retrofit. Same code, same requests and it's working but I want to understand what could be the cause of my problem.

推荐答案

NetworkDispatcher 只有4 主题默认所以我认为你的问题是通过创建多个请求队列老线程导致剂量不杀,使用单队列,为指的是看看:

NetworkDispatcher has only 4 threads by default so i think your problem is caused by creating multiple requestqueue and old threads dose not killed, use singleton queue, for refering to that look at:

http://developer.android.com/training/volley/requestqueue.html

每个请求队列中只有4个线程,但在你的形象,我可以看到4个以上如此明显造成不使用Singleton设计模式的问题。

each request queue has only 4 threads but in your image i can see more than 4 so obviously your problem caused by not using singleton design pattern.