What are RecyclerView.Adapter and ViewHolder, and why do they improve scrolling?
This tests RecyclerView's data-to-view separation. A strong answer says Adapter binds data while ViewHolder caches findViewById results, avoiding hierarchy scans on scroll. A red flag is calling ViewHolder a memory saver instead of a lookup cache.
What's really being asked
The interviewer wants to know if you understand the difference between creating a view and populating it with data, and whether you can explain why scrolling performance degrades without the ViewHolder pattern. Specifically they are looking for knowledge of the view recycling mechanism and the cost of repeated findViewById calls.
The full answer
First, the Adapter has two jobs: creating new ViewHolder instances in onCreateViewHolder and binding data to existing ones in onBindViewHolder. Second, the ViewHolder is a lightweight object that holds references to the subviews of a list item layout, typically obtained once via findViewById inside the ViewHolder constructor. Third, because the RecyclerView recycles ViewHolder instances as the user scrolls, the framework calls onBindViewHolder with an existing holder instead of inflating a new layout and traversing the view hierarchy to locate each TextView or ImageView again. Fourth, this separation means expensive inflation and view lookup happen once per item type, while binding happens many times, keeping frame rates smooth during scroll.
The mistakes people make
A major red flag is saying the ViewHolder reduces memory usage by itself; the ViewHolder is a reference cache, not a memory management tool. Another mistake is claiming it recycles bitmaps or images; image loading is handled by libraries or manual cleanup in onViewRecycled, not by the holder pattern. Candidates also stumble by describing the Adapter as only a data source without mentioning its responsibility for creating views, or by saying findViewById is slow because it searches the entire activity layout rather than just the item view.
What usually comes next
The interviewer may ask how DiffUtil relates to Adapter updates, or how ListAdapter differs from RecyclerView.Adapter. They might also ask what happens if you omit the ViewHolder and call findViewById inside onBindViewHolder, or how payload-based binding can further reduce work during partial updates. Another common extension is asking about view recycling with multiple item types and how getItemViewType affects the pool.
A concrete example
Imagine a list of one thousand messages. Without a ViewHolder, onBindViewHolder would call findViewById three times per row to locate the avatar ImageView, the username TextView, and the message TextView. At sixty frames per second while scrolling, that is thousands of hierarchy traversals per second. With a ViewHolder, those three references are stored in final fields when the row is first inflated. During scroll, the RecyclerView pulls a dirty ViewHolder from its scrap heap, and the Adapter simply assigns new text and image URLs to the already-cached views. The findViewById cost drops to zero for every subsequent bind.
Interview question
During fast scrolling, why is it critical that findViewById happens inside the ViewHolder constructor rather than inside onBindViewHolder?
- a.Because findViewById scans the entire activity layout, so calling it in onBindViewHolder wastes time on every scroll frame
- b.Because recycled ViewHolders already hold cached subview references, eliminating repeated hierarchy traversals in onBindViewHolderCorrect
- c.Because moving the call to the constructor reduces memory usage by preventing layout inflation during scroll
- d.Because the ViewHolder pattern recycles bitmaps and images automatically, avoiding reloads during scroll
Why? this is the answer
The ViewHolder caches subview references via findViewById once during creation, and because RecyclerView recycles these holders, onBindViewHolder avoids expensive repeated hierarchy traversals. Distractor A is tempting because it correctly notes that findViewById is slow, but it wrongly claims the search scope is the entire activity layout instead of just the item view.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #recyclerview
- #performance
- #viewholder
- #adapter
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles