RecyclerView vs ListView: Which Android List Component Truly Outperforms?
This article examines the caching mechanisms of Android's RecyclerView and ListView, comparing their hierarchical caches, view holder strategies, and partial refresh capabilities, and concludes when each component is preferable based on performance, animation support, and data update frequency.
1. Background
RecyclerView is an official Google UI component for displaying large data sets, designed to replace the traditional ListView with greater power and flexibility.
The author investigates whether ListView should be replaced by RecyclerView from a performance perspective, focusing on their caching mechanisms.
2. Main Content
2.1 Cache Mechanism Comparison
Different hierarchy: RecyclerView has two additional cache levels compared to ListView, supporting multiple off‑screen item caches, custom cache handling, and a shared RecyclerViewPool.
ListView uses a two‑level cache (active views and attached scrap). RecyclerView uses a four‑level cache (active, attached scrap, cached views, and a pool).
Both share similar concepts: mActiveViews and mAttachedScrap quickly reuse visible items; mScrapView (ListView) and mCachedViews + mRecyclerPool (RecyclerView) cache off‑screen items for reuse.
RecyclerView’s mCacheViews can reuse off‑screen items without rebinding, and its pool can be shared across multiple RecyclerViews, giving it an advantage in specific scenarios such as ViewPager with multiple lists.
Cache content: RecyclerView caches ViewHolder objects (view + holder + flag), while ListView caches raw View objects.
Cache retrieval flow differs: ListView obtains a view from mScrapViews by position and then calls getView (rebinding). RecyclerView obtains a ViewHolder by position, checks the flag, and may skip rebinding.
2.2 Partial Refresh
RecyclerView provides partial‑refresh APIs (e.g., notifyItemRemoved) that avoid unnecessary bindView calls.
When notifyItemRemoved is invoked, the layout process runs: onMeasure → onLayout → onDraw. The critical onLayout step consists of three sub‑steps:
Record pre‑layout item positions for animation calculations.
Measure and layout children via layoutChildren().
Determine item state changes (remove, add, move, update) and trigger appropriate animations.
The layoutChildren() flow is illustrated in the accompanying diagram.
During notifyItemRemoved, RecyclerView updates off‑screen items' position and flag, allowing getViewForPosition to bind the view only once.
The key distinction is that ListView moves all active views to a secondary cache and rebinds them, whereas RecyclerView selectively flags items, enabling more efficient partial updates.
3. Conclusion
1. For scenarios like initial screen rendering or simple scrolling, both ListView and RecyclerView perform adequately; RecyclerView does not provide a significant performance boost.
2. In cases with frequent data updates (e.g., bullet‑screen comments), RecyclerView’s caching and partial‑refresh mechanisms show clear advantages.
Overall, if a list page requires animations, frequent updates, or partial refreshes, RecyclerView is recommended for its robustness and extensibility. Otherwise, ListView remains a convenient and efficient choice.
4. References
1. ListView
a. Android‑23 source code
b. Detailed analysis of ListView internals
c. Hands‑on ListView learning resources
2. RecyclerView
a. RecyclerView‑v7‑23.4.0 source code
b. In‑depth RecyclerView dissection articles
c. Additional RecyclerView analysis
WeChat Client Technology Team
Official account of the WeChat mobile client development team, sharing development experience, cutting‑edge tech, and little‑known stories across Android, iOS, macOS, Windows Phone, and Windows.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
