8

我正在使用 volley 库进行网络服务调用。我制作了一个通用类，用于进行所有 Web 服务调用并从那里进行服务调用，并为成功和错误响应创建了匿名侦听器。

但是当我使用泄漏金丝雀时，它显示与上下文相关的内存泄漏。下面是我的代码片段：

public void sendRequest(final int url, final Context context, final ResponseListener responseListener, final Map<String, String> params) {
    StringRequest stringRequest;
    if (isNetworkAvailable(context)) {

      stringRequest = new StringRequest(methodType, actualURL + appendUrl, new Listener<String>() {
            @Override
            public void onResponse(String response) {
                dismissProgressDialog(context);
                try {
                    (responseListener).onResponse(url, response);
                } catch (JsonSyntaxException e) {
                    // Util.showToast(context, context.getResources().getString(R.string.error));
                    Crashlytics.logException(e);
                }
            }

        }, new ErrorListener() {
            @Override
            public void onErrorResponse(VolleyError error) {
                // Util.showToast(context,context.getString(R.string.error));

                dismissProgressDialog(context);
                if (error instanceof NetworkError) {
                     Util.showToast(context, context.getResources().getString(R.string.network_error));
                } else if (error instanceof NoConnectionError) {
                     Util.showToast(context, context.getResources().getString(R.string.server_error));
                } else if (error instanceof TimeoutError) {
                     Util.showToast(context, context.getResources().getString(R.string.timeout_error));
                } else {
                     Util.showToast(context, context.getResources().getString(R.string.default_error));
                }


            }

        }) {
            @Override
            protected Map<String, String> getParams() throws AuthFailureError {
                return params;
            }


            @Override
            public Map<String, String> getHeaders() throws AuthFailureError {
                return request.getHeaders(context, actualURL, false);
            }
        };
        stringRequest.setRetryPolicy(new DefaultRetryPolicy(30000, DefaultRetryPolicy.DEFAULT_MAX_RETRIES, DefaultRetryPolicy.DEFAULT_BACKOFF_MULT));
        VolleySingleton.getInstance(context).addRequest(stringRequest);
    } else {
         Util.showToast(context, context.getString(R.string.internet_error_message));
    }
}

我创建了一个名为响应侦听器的接口，用于将响应重定向到活动或片段。我提出如下要求。

Request.getRequest().sendRequest(Request.SOME URL, SplashScreenActivity.this, SplashScreenActivity.this, new HashMap<String, String>());

但我面临内存泄漏：

In 2.1.1:31.
* activity.SplashScreenActivity has leaked:
* GC ROOT com.android.volley.NetworkDispatcher.<Java Local>
* references network.Request$5.mListener (anonymous subclass of com.android.volley.toolbox.StringRequest)
* references network.Request$3.val$responseListener (anonymous implementation of com.android.volley.Response$Listener)
* leaks activity.SplashScreenActivity instance
* Retaining: 1.2MB.
* Reference Key: b8e318ea-448c-454d-9698-6f2d1afede1e
* Device: samsung samsung SM-G355H kanas3gxx
* Android Version: 4.4.2 API: 19 LeakCanary: 1.4 6b04880
* Durations: watch=5052ms, gc=449ms, heap dump=2617ms, analysis=143058ms

任何消除此泄漏的想法都值得赞赏。

4

4 回答 4

5

通常，匿名类对封闭类实例具有强引用。在您的情况下，这将是 SplashScreenActivity。现在我想，Activity在您通过 Volley 从服务器获得响应之前，您已经完成了。由于侦听器对封闭的 Activity 具有强引用，因此在 Anonymous 类完成之前，该 Activity 不能被垃圾收集。您应该做的是将您发送的所有请求标记为 Activity 实例，并在onDestroy()Activity 回调时取消所有请求。

stringRequest.setTag(activityInstance);

要取消所有待处理的请求：

requestQueue.cancellAll(activityInstance);

此外，使用 VolleySingleton 中的应用程序上下文来创建 RequestQueue。

mRequestQueue = Volley.newRequestQueue(applicationContext);

不要在那里使用您的 Activity 上下文，也不要在 VolleySingleton 中缓存您的 Activity 实例。

于 2016-09-22T05:56:00.747 回答
2

我在 LeakCanary 中检测到了类似的问题，其中 Volley 的 mListener 正在引用我的响应侦听器，而我的侦听器正在引用 ImageView，因此它可以使用下载的图像对其进行更新。

我让我的响应监听器成为活动中的一个内部类..

private class MyVolleyResponseListener <T> implements com.android.volley.Response.Listener <Bitmap> {

        @Override
        public void onResponse(Bitmap bitmap) {
            thumbNailView.setImageBitmap(bitmap);
        }
}

.. 并在活动中的 onDestroy() 内停止并启动凌空请求队列 ..

requestQueue.stop();
requestQueue.start();

这已经修复了泄漏。

于 2017-09-30T22:27:57.937 回答
2

基本上，匿名方法在您没有大量内存Android的地方或任何地方都很糟糕。ClientSideSystem发生的事情是，您已Context在方法中作为参数传递并anonymous持有它的引用。真正的混乱现在出现在场景中，其中 make 内部的线程network call无法完成它的工作，并且在此之前调用活动由于某种原因在这种情况下销毁或回收GC无法收集活动，因为wokerThread可能仍然持有对它的引用. 请通过此了解详细说明。

解决方案可以是静态内部类或独立类，在这两种情况下都WeakReference用于保存资源并在使用它们之前进行空检查。

优点是如果没有其他人，如果持有对它的引用WeakReference，它将允许收集对象。GC

于 2016-09-22T05:48:31.790 回答
1

我知道我加入聚会有点晚了，但几天前这个问题确实破坏了我的周末。为了弄清楚，我继续研究了一下，最终得到了解决方案。

问题在于最后一个请求对象在 Network Dispatcher & Cache Dispatcher 中泄露。

@Override
    public void run() {
        if (DEBUG) VolleyLog.v("start new dispatcher");
        Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);

        // Make a blocking call to initialize the cache.
        mCache.initialize();

        Request<?> request;
        while (true) {
            // release previous request object to avoid leaking request object when mQueue is drained.
            request = null;
            try {
                // Take a request from the queue.
                request = mCacheQueue.take();
            } catch (InterruptedException e) {
                // We may have been interrupted because it was time to quit.
                if (mQuit) {
                    return;
                }
                continue;
            }
            try {
                request.addMarker("cache-queue-take");

                // If the request has been canceled, don't bother dispatching it.
                if (request.isCanceled()) {
                    request.finish("cache-discard-canceled");
                    continue;
                }

                // Attempt to retrieve this item from cache.
                Cache.Entry entry = mCache.get(request.getCacheKey());
                if (entry == null) {
                    request.addMarker("cache-miss");
                    // Cache miss; send off to the network dispatcher.
                    mNetworkQueue.put(request);
                    continue;
                }

                // If it is completely expired, just send it to the network.
                if (entry.isExpired()) {
                    request.addMarker("cache-hit-expired");
                    request.setCacheEntry(entry);
                    mNetworkQueue.put(request);
                    continue;
                }

                // We have a cache hit; parse its data for delivery back to the request.
                request.addMarker("cache-hit");
                Response<?> response = request.parseNetworkResponse(
                        new NetworkResponse(entry.data, entry.responseHeaders));
                request.addMarker("cache-hit-parsed");

                if (!entry.refreshNeeded()) {
                    // Completely unexpired cache hit. Just deliver the response.
                    mDelivery.postResponse(request, response);
                } else {
                    // Soft-expired cache hit. We can deliver the cached response,
                    // but we need to also send the request to the network for
                    // refreshing.
                    request.addMarker("cache-hit-refresh-needed");
                    request.setCacheEntry(entry);

                    // Mark the response as intermediate.
                    response.intermediate = true;

                    // Post the intermediate response back to the user and have
                    // the delivery then forward the request along to the network.
                    final Request<?> finalRequest = request;
                    mDelivery.postResponse(request, response, new Runnable() {
                        @Override
                        public void run() {
                            try {
                                mNetworkQueue.put(finalRequest);
                            } catch (InterruptedException e) {
                                // Not much we can do about this.
                            }
                        }
                    });
                }
            } catch (Exception e) {
                VolleyLog.e(e, "Unhandled exception %s", e.toString());
            }
        }

如您所见，在从队列中获取之前创建了一个新的请求对象。这克服了内存泄漏的问题。

PS：不要使用 Google 存储库中的 Volley，因为它已被弃用并且从那时起就有这个错误。为了使用 Volley，请执行以下操作：

https://github.com/mcxiaoke/android-volley

上述存储库没有任何内存泄漏。再见。

于 2017-05-01T18:02:34.520 回答