Question

总而言之，我在Volley的onResponse()方法中使用Picasso来填充带有图像的列表视图。

代码正在运行，但是我的帧率很低，如果我过快地滚动列表视图，应用程序就会崩溃而没有内存。

糟糕的表现来自哪里？我认为异步的东西会处理所有事情。

Picasso和Volley的工作只是找到，直到我把它们粘在彼此之内。

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

以下是我在Volley中使用Picasso的方法：

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）bests图像加载库到日期Picasso和Glide之间的比较。教程涵盖了内存使用，质量等所有你想知道的事情关于这两个库。所以，经过这些讨论之后，你会明白使用毕加索调整大小是为了摆脱记忆问题。

使用resize()或fit()与picasso

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

Answer 2

我拿出了Picasso代码片段，我意识到我仍然有同样糟糕的帧速率。总之，问题是Volley！现在，我必须明白为什么。

在Volley里面使用Picasso给了我一个糟糕的帧速率并且崩溃了我的应用程序

2 个答案: