I have multiple elements in my recyclerview's row -> By multiple I mean multiple in number as well as multiple in type i.e mutliple imageviews, textviews etc.
Following is the gist so that you can see all the elements: https://gist.github.com/Harshhb101/55e25da72e3a474aeeb422d5e231d3e3
The issue is that I need to hide/show these elements based on a parameter which can have upto 10 values. Thus I will have 10 types of rows. Currently I have created only one layout for the row have elements for all types of rows and in some mobiles, the scroll has a lag. Majorly I am getting the lag where the rows have images. I am using Glide to load the images. Following is the gist for the onBindView: https://gist.github.com/Harshhb101/e10feb2cccda9d698ff06487bbb879ef
I did look up on stackoverflow but could not find anything solid but came upon using multiple viewholders. My question is that if I refactor my code, will it make a substantial difference by using multiple viewholders? Or is there something wrong in my approach that could be fixed to get a good scoll.
You need to make your RecyclerView images smaller to save memory and cache them. Read this.
Also if your ViewHolder contains images that has size wrap_content then images are loaded full size what is really bad for performance for example if view size on screen is 48dp x 48dp and picture is full HD, then full HD drawable going to be loaded in to memory what is making your scrolling slow and not smooth.
I suggest using fixed size in ViewHolder or override image size when loading in Glide
Please declare many view type instead of one view type for many kind. It's actually make the code more readability, but not much the reduce the lag because the recycle view/listview is have the reused mechanism.
Recommended to use fixed size in RecycleView.
I saw the Glide used for image loading. So did you config the cache?
I have doubt that you loading the big resolution image
After looking into the code i found couple of improvements.
Don't make God ViewType (One view type for all kind of views). instead create
individual viewtype for each kind of posts. so it'll eliminate the rendering cost of all the views and making them visible and invisble at runtime.
Reference demo of recyclerview with multiple viewtypes
Use some image loading libraries so that you dont have to handle caching images and bitmap related manipulations (Picasso will be good).
Picasso
And lastly avoid doing heavy tasks in onbind() instead prepare your data class specifically for recyclerview (if much caluclation required like heavy string manipulations etc) before setting recyclerview adapter.
Related
I've been trying to create a Recycler View full of Card Views. Currently, I'm using the Recycler View from this tutorial and loading it with 14 different images. The professional quality images range in size from 134K to 242K.(Down from 8MB - 18MB)
I know that the images may be too big but, I feel there must be some way to get better performance while scrolling. Can someone point me in the right direction?
Edit: The images will be stored on the device. There will probably never be more than 20 of them.
You can use Picasso library or Android Universal Image Loader
Picasso
Android-Universal-Image-Loader
You don't need any AsyncTask.Theese 2 library handling image operations in background so you can keep scrolling smoothly. I am using Picasso in my project right now. You can add error drawable , temporary placeholder default drawable , and its so simple automatically caching.
Just use one of them in onBindViewHolder to bind any image to imageView
Load the images in a separate thread (or AsyncTask).
Got some good feedback. Originally wanted infinite scroll. Removed it. I am also an interested in a solution with pagination or that just handles a simple case of the first 20 results to start. The main thing I want to know is the best types of views to use. Question was very vague at first. Narrowed the scope of it, too.
I want a view that fills the phone or tablet's screen with tiled images from an api.
How I'm thinking about doing this:
putting a GridView in my layout
using the Picasso library by Square to load the images (possibly do more, not sure what it can do for me)
making an adapter to the GridView
doing a query to my api (in this case getting popular movies)
processing the query results and turning them into an ArrayList of Strings or Uris with the image locations (for popular movie posters)
passing the list to the adapter to the GridView so it can show the images.
I don't I know enough about Android to think this through fully yet. I'm in the process of learning.
Any suggestions for better design, tutorials on similar things, or things that may make this easier/better?
Thanks!
Please see the picture. I have an application that shows data in the form of list but it is a WebView.My application size got increased and it is also creating a lot of data.
So if i convert all the webview to list view then will it reduce the size and does it make any sense to do so?
Or Please suggest me any other way to display data in list that reduce the size.
assuming that all you are going to display is scroll-able list of text sections - ListView probably consume much less memory then loading similar content to WebView. no doubt about that.
also, if you decide to go for ListView - make sure you are following all important guidelines and design patterns to optimize memory and improve performence, such as using the ViewHolder design pattern, handling recycling properly, and so on..
I'm using Android-Universal-Image-Loader in a ListView of mine and I'm trying to find the best solution to following:
using resetViewBeforeLoading is necessary or else I get the same image in my ConvertViews, but this causes jitter, unless..
I use PauseOnScrollListener which is otherwise great, except that it shows a blank in some ConvertViews even for images that are already downloaded (I'm using memory and disk caches), so it's confusing to the user who sees a blank for an image they saw only 2 swipes ago
So it seems that I can't get an instant image load (for already-downloaded images) on scroll without jitter, even for images in memory, is this about right? Is there a better or more standard way to do this? (Vertical list-view showing screen-width images, sort of like the Instagram app, which does it buttery-smooth)
Otherwise, is there a way to lengthen the number of convertViews in my ListView to prevent unnecessarily aggressive re-use?
Thanks in advance
I have a ListView with many lines (about 200).
In each item of the ListView there is a thumbnail picture.
The pictures are downloaded for form the internet as the ListView scrolls.
The problem is that if I scroll rapidly the ListView it gets sluggish and quickly I get an Out of Memory error.
Please could you suggest an approach on how to avoid this?
Use View Holder pattern on the custom adapter you're using with lazy loading.
Lazy Loading using Universal Image Loader.
OR
you could give Picasso / Volley Libraries a shot. They can handle caching efficiently for you.
The basic flow is to use a caching system:
Download Image to your cache directory -> read it back into memory cache -> scale it down (if the image is larger than the the image view that displays it) -> display it in your image view.
The official android training has a great tutorial along with full source code on how to create something like this.
They address the common issue of scrolling lag by pausing the background task(s) while user is scrolling.
Out Of memory is addressed through LruCache.
Alternatively you can use a third party library like the Universal Image Loader for addressing this issue.
You must handle your view recycling. It's a very important performance issue and you should always handle it.
See this post, it will guide you in this process, handling the view recycling and using the View Holder pattern. Also see this.
There are many reasons for recycling views:
Object creation is relatively expensive. Every additional object that is created needs to be dealt with by the garbage collection system, and at least temporarily increases your memory footprint;
This is more important for more complex views, but inflating and laying out the view objects can be expensive. Most often, you are only making minor changes to the view in getView that won't affect the layout (e.g, setting text) so you might be able to avoid the layout overhead;
Remember that android is designed to be run in a resource constrained environment;
Finally, its already done for you, and it certainly doesn't hurt anything, so why not use it;
Hoe it helps you.