The documentation says that setItemViewCacheSize
sets the number of offscreen views to retain before adding them to the potentially s
I've read this article by Pavel Shmakov and it explains the difference between Pool and Cache
Pool and Cache in Action
- If a ViewHolder was found nowhere, it is created and bound.
- If a ViewHolder was found in pool, it is bound.
- If a ViewHolder was found in cache, there is nothing to be done.
So, as long as the cache isn’t full, ViewHolders go there. If it’s full, a new ViewHolder pushes a ViewHolder from the “other end” of the cache into the pool. If a pool is already full, that ViewHolder is pushed into oblivion, to the garbage collector that is
Now let’s look at the way pool and cache behave in a couple of actual RecyclerView usage scenarios.
Consider scrolling:
As we scroll downwards, there is a “tail” behind the currently seen items consisting of cached items and then a pooled item. When the item 8 appears on screen, no suitable ViewHolder is found in cache: no ViewHolder associated with position 8 there. So we use a pooled ViewHolder, which was previously at position 3. When item 6 disappears on top, it goes to the cache, pushing 4 into the pool.
The picture is different when we start scrolling in the opposite direction:
Here we find a ViewHolder for position 5 in view cache and reuse it right away, without rebinding. And that seems to be the main use-case of the cache — to make scrolling in opposite direction, to the items we’ve just seen, more efficient. So if you have a news feed, the cache might be useless, since users won’t go back too often. But if it’s a list of things to choose from, say a gallery of wallpapers, you might want to extend the capacity of the cache.
Read more here https://android.jlelse.eu/anatomy-of-recyclerview-part-1-a-search-for-a-viewholder-404ba3453714