在 Volley 中使用 Picasso 导致我的帧速率不佳并导致我的应用程序崩溃

Question

长话短说，我在 Volley 的 onResponse() 方法中使用 Picasso 来用图像填充列表视图。

代码正在运行，但我的帧速率很差，如果我在列表视图中滚动得太快，应用程序会因没有内存而崩溃。

糟糕的表现从何而来？我认为异步的东西会处理一切。

Picasso 和 Volley 一直在工作，直到我将它们粘在一起。

我认为问题可能是我将一个异步类粘在另一个异步类中。也许这解释了我得到的线程错误，例如all threads took?

这是我在 Volley 中使用毕加索的方法：

RequestQueue requestQueue = Volley.newRequestQueue(ctx1);

    JsonObjectRequest jsonObjectRequest = new JsonObjectRequest(url, new Response.Listener<JSONObject>() {
        @Override
        public void onResponse(JSONObject response) {

            // If there is a response, do this
            if (response != null) {

                // Get the number of JSON objects on the web-page
                int resultCount = response.optInt("resultCount");

                // If there is a JSON object on the web-page, do this
                if (resultCount > 0) {

                    // Get a gson object
                    Gson gson = new Gson();

                    // Get a JSONArray from the results
                    JSONArray jsonArray = response.optJSONArray("results");

                    // If the array exists, do this
                    if (jsonArray != null) {

                        JSONObjectsList = gson.fromJson(jsonArray.toString(), SongInfo[].class);

                        Picasso.with(ctx2)
                                .load(String.valueOf(JSONObjectsList[0].artworkUrl30))
                                .transform(new CircleTransform())
                                .placeholder(R.drawable.blackcircle)
                                .into(iv);
                    }
                }
            }
        }
    }, new Response.ErrorListener() {
        @Override
        public void onErrorResponse(VolleyError error) {
            Log.e("LOG", error.toString());
        }
    });

    requestQueue.add(jsonObjectRequest);
}

错误日志的最后一位

11-27 01:25:21.482 32167-32182/ I/art: Background sticky concurrent mark sweep GC freed 157894(7MB) AllocSpace objects, 62(5MB) LOS objects, 9% free, 63MB/69MB, paused 9.954ms total 196.412ms
11-27 01:25:21.502 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:21.602 32167-32182/ W/art: Suspending all threads took: 8.316ms
11-27 01:25:21.662 32167-32182/ I/art: Background partial concurrent mark sweep GC freed 160421(7MB) AllocSpace objects, 36(3MB) LOS objects, 22% free, 55MB/71MB, paused 16.171ms total 156.768ms
11-27 01:25:21.672 32167-32182/ W/art: Suspending all threads took: 5.037ms
11-27 01:25:21.712 32167-32174/ W/art: Suspending all threads took: 36.212ms
11-27 01:25:21.732 32167-32182/ I/art: Background sticky concurrent mark sweep GC freed 6365(305KB) AllocSpace objects, 6(372KB) LOS objects, 12% free, 55MB/63MB, paused 11.009ms total 55.466ms
11-27 01:25:21.772 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:21.862 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:22.062 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:22.102 32167-32182/ I/art: Background partial concurrent mark sweep GC freed 134151(6MB) AllocSpace objects, 47(4MB) LOS objects, 22% free, 55MB/71MB, paused 11.466ms total 128.496ms
11-27 01:25:22.362 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:22.652 32167-32182/ I/art: Background sticky concurrent mark sweep GC freed 171943(7MB) AllocSpace objects, 86(7MB) LOS objects, 11% free, 59MB/67MB, paused 6.646ms total 90.801ms
11-27 01:25:22.662 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:22.712 32167-32174/ W/art: Suspending all threads took: 33.982ms
11-27 01:25:22.742 32167-32182/ I/art: Background partial concurrent mark sweep GC freed 124437(6MB) AllocSpace objects, 24(2MB) LOS objects, 23% free, 52MB/68MB, paused 12.255ms total 87.884ms
11-27 01:25:22.932 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:23.192 32167-32167/ D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN
11-27 01:25:23.192 32167-32167/ I/Choreographer: Skipped 127 frames!  The application may be doing too much work on its main thread.
11-27 01:25:23.342 32167-32182/ I/art: Background sticky concurrent mark sweep GC freed 152008(7MB) AllocSpace objects, 69(6MB) LOS objects, 12% free, 57MB/65MB, paused 11.857ms total 124.020ms
11-27 01:25:23.702 32167-32174/ W/art: Suspending all threads took: 29.615ms
11-27 01:25:23.772 32167-32182/ I/art: Background partial concurrent mark sweep GC freed 165355(7MB) AllocSpace objects, 26(3MB) LOS objects, 21% free, 56MB/72MB, paused 10.798ms total 159.423ms
11-27 01:25:23.852 32167-32182/ I/art: Background sticky concurrent mark sweep GC freed 16824(674KB) AllocSpace objects, 1(150KB) LOS objects, 12% free, 57MB/65MB, paused 7.395ms total 66.835ms
11-27 01:25:24.182 32167-32174/ W/art: Suspending all threads took: 10.983ms
11-27 01:25:24.562 32167-32182/ I/art: Background partial concurrent mark sweep GC freed 60495(2MB) AllocSpace objects, 15(2MB) LOS objects, 20% free, 62MB/78MB, paused 12.542ms total 196.419ms
11-27 01:25:24.632 32167-32182/ I/art: Background sticky concurrent mark sweep GC freed 6414(236KB) AllocSpace objects, 0(0B) LOS objects, 11% free, 63MB/71MB, paused 10.624ms total 67.043ms
11-27 01:25:24.932 32167-32167/ W/libc: pthread_create failed: couldn't allocate 1064960-byte stack: Out of memory
11-27 01:25:24.932 32167-32167/ E/art: Throwing OutOfMemoryError "pthread_create (1040KB stack) failed: Try again"
11-27 01:25:24.932 32167-32167/ D/AndroidRuntime: Shutting down VM
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime: FATAL EXCEPTION: main
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime: Process: , PID: 32167
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime: java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at java.lang.Thread.nativeCreate(Native Method)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at java.lang.Thread.start(Thread.java:1063)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at com.android.volley.RequestQueue.start(RequestQueue.java:145)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at com.android.volley.toolbox.Volley.newRequestQueue(Volley.java:79)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at com.android.volley.toolbox.Volley.newRequestQueue(Volley.java:105)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at com.android.volley.toolbox.Volley.newRequestQueue(Volley.java:115)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at .ServiceHandler.runVolley(ServiceHandler.java:41)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at .MyListAdapterTracks.getView(MyListAdapterTracks.java:119)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.widget.AbsListView.obtainView(AbsListView.java:2825)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.widget.ListView.makeAndAddView(ListView.java:1884)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.widget.ListView.fillDown(ListView.java:713)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.widget.ListView.fillGap(ListView.java:677)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.widget.AbsListView.trackMotionScroll(AbsListView.java:7043)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.widget.AbsListView$FlingRunnable.run(AbsListView.java:6481)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.view.Choreographer$CallbackRecord.run(Choreographer.java:777)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.view.Choreographer.doCallbacks(Choreographer.java:590)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.view.Choreographer.doFrame(Choreographer.java:559)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:763)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.os.Handler.handleCallback(Handler.java:739)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.os.Handler.dispatchMessage(Handler.java:95)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.os.Looper.loop(Looper.java:145)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at android.app.ActivityThread.main(ActivityThread.java:5944)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at java.lang.reflect.Method.invoke(Native Method)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at java.lang.reflect.Method.invoke(Method.java:372)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1399)
11-27 01:25:24.932 32167-32167/ E/AndroidRuntime:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1194)
11-27 01:25:25.062 32167-2055/ A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 2055 (Thread-8342)

Answer 1

您可以看到 (Link) 迄今为止最好的图像加载库之间的比较 Picasso 和 Glide。本教程涵盖了内存使用、质量等关于这两个库的所有内容。 因此，在阅读完 tuts 之后，您会明白使用 picasso 调整大小对于摆脱内存问题非常重要。

将resize() 或fit() 与毕加索一起使用

 Picasso.with(this)
        .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")
        .resize(100, 100)//fit()
        .into(ivImgPicasso);

Answer 2

我取出毕加索代码 sn-p，我意识到我仍然有同样糟糕的帧速率。总之，问题是排球！现在，我必须明白为什么。