What are RecyclerView.Adapter and ViewHolder, and why do they improve scrolling?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.

Source: developer.android.com