Optimize RecyclerView Performance in Android

Official answer

Profile a representative scrolling/update trace first. Separate inflation, binding, image decoding, layout, drawing and background diff work; measure frame deadlines, allocation/GC, memory and response time on target devices.

Keep onCreateViewHolder focused on constructing a compatible row and caching its child references. A full onBindViewHolder must set every relevant visible state for the current item: text, selection, enabled/visibility state and image placeholder. A recycled holder may previously have displayed a completely different item. Only use a partial bind when known payloads justify it, and retain a correct full-bind fallback because payloads can be dropped.

Use immutable list/item snapshots with ListAdapter or AsyncListDiffer where appropriate. Define stable item identity separately from content equality and do not mutate a submitted list while diffing. Use targeted updates rather than rebuilding everything for one changed row. Additional view types are for genuinely different row structures; more types can reduce reuse.

Move expensive formatting/data preparation off the critical binding path. Use an image loader that sizes/caches images and cancels or replaces old requests so late results do not attach to another item. Keep layouts as simple as the design permits; a particular layout class does not guarantee faster frames.

Handle click identity using the currently bound item or a valid current binding-adapter position, including NO_POSITION. For very large data, page it instead of assuming view recycling bounds the dataset itself. Test fast scroll, deletion/moves, image completion after reuse and empty/error states. DAU changes do not establish a RecyclerView performance improvement.

RecyclerView roles, Adapter binding contract, ListAdapter immutable updates, DiffUtil assumptions