Edited:
glide
to load images. I\'m getting Out of
The reason is while scrolling, glide keep doing image process even related views removes from list. Add this code in your listview's onScrollStateChanged.
if (view.getContext() != null) {
switch (scrollState) {
case SCROLL_STATE_IDLE:
Glide.with(view.getContext()).resumeRequests();
break;
case SCROLL_STATE_TOUCH_SCROLL:
case SCROLL_STATE_FLING:
Glide.with(view.getContext()).pauseRequests();
break;
}
}
Using Glide doesn't guarantee no Out of Memory
errors, you need to use several small steps to reduce the probability to not get OOM's
.
Step 1: Understand the caching mechanism in Glide
Step 2: I prefer to load thumbnails
into recyclerview
Glide
.with( context )
.load( UsageExampleGifAndVideos.gifUrl )
.thumbnail( 0.1f )
.into( imageView2 );
Remember to always request small size image if bigger or HD images are not required.
Use recyclerView
instead of ListView
. It reusable single item for rendering items. I am using glide
with recyclerView
where i am loading wallpapers with 100+ items.
In ListView every time you are creating view, if you have 100+ view and it will create 100+ views where as in recyclerview it creates how many visible items are there in screen +2.
I faced the similar problem . I am sharing the way I solved it . Create a folder named drawable-nodpi
put your golive_load_image
and golive_cancel_image
file into that folder , and remove those two image file from other place like drawable-ldpi
,drawable-hdpi
etc (if you have there ) . And add skipMemoryCache( true )
Glide.with(context).load(rowItem.getPosteduserpostimage())
.skipMemoryCache( true )
.placeholder(R.drawable.golive_load_image).error(R.drawable.golive_cancel_image)
.override(600, 200)
.into(holder.ivPostedImage);
I faced the same issue and solved it by adding android:largeHeap="true"
in the application tag of my manifest file like below.
<manifest>
...
<application
.....
android:largeHeap="true"
....
>
....
</application>
</manifest>
NB: this should be your last option, as using largeHeap:true
is not recommended for solving simple OOM problems.