问题
To make a long story short, I'm using Picasso inside Volley's onResponse() method to populate a listview with images.
The code is working, but I'm getting a bad frame-rate, and the app is crashing with no memory if I scroll through the list view too quickly.
Where is the bad performance coming from? I thought the asynchronous stuff would take care of everything.
Picasso and Volley work just find until I stick them inside of each-other.
I think the problem might be that I'm sticking an asynchronous class inside another asynchronous class. Maybe this explains the threading errors I get e.g. all threads took?
Here is how I use Picasso inside 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);
}
The last bit of the error log
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)
回答1:
You can see( Link ) the comparison between the bests image loading libraries till date Picasso and Glide.The tutorial covers memory usages,quality etc all the things you want to know about both the libraries. So, after going through the tuts you get the point when using picasso resizing is considerable to get rid from memory issues.
Use Either resize() or fit() with picasso
Picasso.with(this)
.load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")
.resize(100, 100)//fit()
.into(ivImgPicasso);
回答2:
I took out the Picasso code snippet and I realized I still had the same bad frame-rate. In conclusion, the problem was Volley! Now, I have to understand why.
来源：https://stackoverflow.com/questions/33954019/using-picasso-inside-volley-is-giving-me-a-bad-frame-rate-and-crashing-my-app