RecyclerView

How Android efficiently renders thousands of items using a pool of reusable views — and why understanding the recycling pipeline, DiffUtil, and the ViewHolder contract is non-negotiable for any Android interview.

Why RecyclerView exists

Before RecyclerView, the go-to for lists was ListView. ListView worked — but it had a fundamental performance problem. By default, it created a new View for every item in the list. Scroll through a list of 1,000 items and ListView would try to inflate 1,000 views. On a slow device with complex list item layouts, this was catastrophic: dropped frames, janky scrolling, and out-of-memory crashes on large datasets.

The ViewHolder pattern was retrofitted onto ListView as a workaround — developers could optionally cache the view reference in convertView.tag to avoid re-inflating. But it was optional, easy to get wrong, and still didn't solve the deeper problem: ListView was tightly coupled to its layout strategy, its animation system, and its adapter. You couldn't use a grid layout, add custom item animations, or compose multiple data sources without significant gymnastics.

RecyclerView arrived in 2014 and rethought the entire system from the ground up. It separated concerns cleanly: the LayoutManager decides where items go, the Adapter creates and binds views, the ViewHolder holds view references, the ItemAnimator handles transitions, and the RecycledViewPool manages the reuse pool. Each piece is swappable. The recycling is mandatory, not optional. And crucially, RecyclerView only ever creates as many views as fit on screen — plus a small buffer. All the rest are recycled and reused.

The RecyclerView architecture

RecyclerView is not one class doing everything — it's a collaboration between five components, each with a single responsibility.

How recycling actually works

The recycling pipeline is the heart of RecyclerView. Understanding it precisely — not just "views get reused" — is what separates a strong interview answer from a weak one. There are actually four pools involved, accessed in order:

What happens step-by-step during a scroll

Let's walk through exactly what RecyclerView does as the user scrolls down and three new items come into view while three scroll off the top.

Step 1 — LayoutManager requests a ViewHolder. As an item enters the viewport, the LayoutManager calls Recycler.getViewForPosition(position). The Recycler is RecyclerView's internal broker — it runs the four-pool lookup on every request.

Step 2 — Check attached scrap first. The Scrap pool is actually split into two: attached scrap (views still connected to RecyclerView but being relaid out, e.g. during a DiffUtil dispatch) and changed scrap (views marked as changed via notifyItemChanged). If the exact position is in either scrap, it's returned immediately with no rebind — this is the fastest path possible, used heavily during predictive animations.

Step 3 — Check the Cache. The cache (size 2 by default, tunable via setItemViewCacheSize()) holds recently-detached ViewHolders keyed by position. If the user scrolled down and then immediately back up, the just-departed views are here — same position, same data, no rebind. This is what makes small back-scrolls feel instant.

Step 4 — Check ViewCacheExtension. Rarely used. Skipped for most adapters.

Step 5 — Check RecycledViewPool. Views here are keyed only by view type, not position. A product card ViewHolder is indistinguishable from any other product card ViewHolder in this pool — they're all in the same bucket. The Recycler grabs one, calls onBindViewHolder(holder, position) to stamp fresh data onto it, and returns it. This is the normal recycling path during continuous scrolling.

Step 6 — Last resort: createViewHolder. If all pools are empty (typically only during the initial fill when the list first appears), onCreateViewHolder is called. Layout inflation happens here — this is the expensive part. Once enough ViewHolders exist to fill the screen, this almost never runs again during normal scrolling.

The takeaway from the four pools: Scrap and Cache are the fast paths — no rebind required, the ViewHolder still holds the correct data. The RecycledViewPool is the rebind path — the ViewHolder is type-correct but its data is stale, so onBindViewHolder() must be called to populate it with new data. Creating a new ViewHolder via createViewHolder() is always the last resort and most expensive option.

The ViewHolder pattern

A ViewHolder has one job: hold references to the views inside a single list item so you never call findViewById() during scrolling. findViewById() walks the entire view tree — it's an O(n) operation on the tree depth. Calling it inside onBindViewHolder() (which runs on every scroll) is the single easiest way to make a list janky. The ViewHolder caches those references once at inflation time, and every subsequent bind reuses them.

ViewHolder lifecycle callbacks

Beyond onCreateViewHolder and onBindViewHolder, the adapter has four more callbacks that most developers never use — but they matter for correctness, especially when your ViewHolders hold resources like media players, timers, or registered listeners.

The ordering of these calls during a typical scroll looks like this: onCreateViewHolder → onBindViewHolder → onViewAttachedToWindow … (user scrolls) … onViewDetachedFromWindow → onViewRecycled (if it exits cache). If the item comes back from the cache without being recycled, it goes: onViewAttachedToWindow directly — no rebind. This is why the Cache is so fast.

DiffUtil — the engine behind smooth list updates

The naive way to update a list is notifyDataSetChanged() — tell RecyclerView "everything changed, rebind everything." It works, but it's wasteful and produces terrible UX: the entire list flickers, scroll position resets, and no item animations play. If you changed one item out of 100, you just forced 100 rebinds and killed every transition animation.

DiffUtil solves this by computing the minimal set of changes between two lists using the Myers diff algorithm — the same algorithm git uses for file diffs. You give it the old list and the new list, it figures out exactly which items were added, removed, moved, or changed, and dispatches fine-grained notifications to the adapter. Only the changed items rebind. Animations play correctly. Scroll position is preserved.

The two-pass process: identity vs content

DiffUtil calls your callback in two distinct passes, and understanding both is essential for writing a correct callback.

Pass 1 — areItemsTheSame(). DiffUtil first asks: "are these the same logical item?" This is an identity check — not about what the item looks like, but whether it represents the same real-world entity. For a product, this means comparing stable IDs (old.id == new.id). If this returns true, DiffUtil treats them as the same item and moves to pass 2. If it returns false, DiffUtil treats one as a removal and the other as an insertion. Never compare by content here — if a product's price changes from ₹100 to ₹150, it's still the same product. Comparing by price would incorrectly produce a remove + insert animation instead of a change animation.

Pass 2 — areContentsTheSame(). Only called when areItemsTheSame() returned true. DiffUtil now asks: "does the item look different?" This is a content check — compare every field the user can see. With Kotlin data classes, old == new does structural equality automatically and works perfectly here. If this returns false, DiffUtil dispatches notifyItemChanged(position) — only that one item rebinds and animates. If it returns true, nothing happens at all for that item.

Optional pass — getChangePayload(). When areContentsTheSame() returns false, DiffUtil calls this optional method. It lets you return a hint about what specifically changed — e.g. only the wishlist state. The adapter receives this as the payloads parameter in onBindViewHolder(holder, position, payloads). If payloads is non-empty, you can update only the changed view instead of the entire row — avoiding flicker on everything else.

LayoutManagers

The LayoutManager is fully responsible for positioning items and deciding the scrolling direction. RecyclerView ships with three built-in options, and you can write your own if needed.

Multiple view types

Most production lists have more than one type of item — headers, ads, loading placeholders, banners mixed with regular items. RecyclerView handles this with getItemViewType(). Each unique type gets its own pool bucket in the RecycledViewPool — a ViewHolder for a header will never be recycled into a product card slot.

ConcatAdapter — composing adapters together

Writing a single adapter that handles headers, footers, loading states, and content is messy. ConcatAdapter (introduced in RecyclerView 1.2) lets you compose multiple independent adapters in sequence. A header adapter, a content adapter, and a footer adapter each handle their own type — ConcatAdapter chains them together. Each adapter stays focused and independently testable.

ItemDecoration — dividers, spacing, and badges

ItemDecoration lets you draw on top of or around items — dividers, spacing between items, section badges, selection highlights. The key advantage over adding padding in item layouts: ItemDecoration is applied by RecyclerView itself and knows about item positions, so you can easily skip the divider after the last item, or only draw a badge on items of a certain type.

Performance — keeping scroll at 60fps

RecyclerView is fast by default, but there are several high-impact optimisations every production list should use.

Paging 3 integration

When your list has thousands of items from a server, you can't load them all upfront. Paging 3 handles this transparently: it loads pages of data on demand as the user scrolls, exposes the result as a Flow<PagingData<T>> from the ViewModel, and a PagingDataAdapter (which extends ListAdapter) consumes it. RecyclerView never knows — from its perspective it's just a regular adapter. Paging 3 handles retry logic, load state, and error states out of the box.

Common mistakes

Calling notifyDataSetChanged()

This is the nuclear option — it tells RecyclerView "assume everything is different, rebind everything, don't animate anything." It kills animations, resets scroll momentum, and does far more work than needed. 99% of the time you should be using ListAdapter with submitList() and letting DiffUtil dispatch precise notifications. Reserve notifyDataSetChanged() only when you genuinely can't compute a diff — like when the entire dataset's sort order has changed.

Setting click listeners in onCreateViewHolder

Click listeners set in onCreateViewHolder capture the ViewHolder's position at creation time. When items are inserted or deleted, that position becomes stale. Always set click listeners in onBindViewHolder (or, even better, use holder.adapterPosition / holder.bindingAdapterPosition at click time). The cleanest pattern — used in the adapter above — is passing lambdas to ViewHolder.bind() which capture the current item directly.

Heavy work in onBindViewHolder

onBindViewHolder runs on the main thread and is called on every visible item during scroll. Any operation that takes more than a couple of milliseconds here will drop frames. Common culprits: synchronous image decoding, complex date/string formatting computed inline, view hierarchy inflation, or notifyDataSetChanged() called from inside a bind. Format strings ahead of time in the ViewModel or data class; decode images with Glide/Coil; never inflate from onBindViewHolder.

How this connects to system design interviews

RecyclerView comes up in nearly every Android system design question — feeds, search results, order history, chat. The depth of your answer matters more than the fact that you know RecyclerView exists. Strong answers go beyond "use RecyclerView with an adapter" and address specifics: "I'd use a PagingDataAdapter with a RemoteMediator to cache pages in Room so the feed works offline. The ViewModel exposes Flow<PagingData> cached with cachedIn(viewModelScope). DiffUtil handles all item change animations automatically. For the mixed content types — banner, product card, loading footer — I'd use ConcatAdapter so each type is managed independently."

Performance questions are equally common: "How do you keep a list with images smooth?" The answer hits prefetching, shared RecycledViewPool for tabbed lists, setHasFixedSize(true), off-thread image decoding via Coil/Glide, DiffUtil payloads for partial rebinds, and avoiding nested RecyclerViews in the same scroll direction.