A brief discussion on performance optimization of RecyclerView

As we all know, RecyclerView has four levels of cache, which are:

Scrap cache: includes mAttachedScrap and mChangedScrap, also known as in-screen cache. It does not participate in recycling and reuse during sliding, and is only used as a temporarily saved variable.
- mAttachedScrap: Only saves the invalid, unremoved, and unrefreshed holders of items separated from RecyclerView during relayout.
- mChangedScrap: will only be responsible for saving invalid and unremoved holders of items that change during relayout.
CacheView cache: mCachedViews, also known as off-screen cache, is used to save the latest removed ViewHolder and views that have been separated from RecyclerView. This level of cache has a capacity limit, and the default maximum number is 2.
ViewCacheExtension: mViewCacheExtension, also known as extended cache, is a cache pool reserved for developers. Developers can expand the recycling pool by themselves and are generally not used.
RecycledViewPool: The ultimate recycling cache pool, a cache pool that actually stores ViewHolders that have been marked as abandoned (other pools are unwilling to recycle). The ViewHolder here has had its data erased and there is no trace of binding. It needs to rebind the data.

(1) If the RecyclerView is cached without scrolling (such as deleting an item) or re-layout.

Separate the ViewHolder on the screen from the screen and store it in Scrap, that is, the changed ViewHolder is cached in mChangedScrap, and the ViewHolder that does not change is stored in mAttachedScrap.
The remaining ViewHolder will be cached in mCachedViews or RecycledViewPool according to mCachedViews> RecycledViewPoolpriority.

(2) If the RecyclerView is cached while scrolling (such as a sliding list), the layout will be filled when sliding.

First remove the items that slide out of the screen, and the first-level cache mCachedViews caches these ViewHolders first.
Since the maximum capacity of mCachedViews is 2, when mCachedViews is full, the first-in-first-out principle will be used to store the old ViewHolder in the RecycledViewPool and then remove it to free up space, and then add the new ViewHolder to mCachedViews.
The remaining ViewHolder will be cached in the ultimate recycling pool RecycledViewPool, which caches different types of ArrayList according to itemType, with a maximum capacity of 5.

When RecyclerView wants to get a reused ViewHolder:

If it is preloaded, it will first go to mChangedScrap to accurately search for the corresponding ViewHolder (according to position and id respectively).
If not, go to mAttachedScrap and mCachedViews to find out exactly (first position, then id) whether it is the original ViewHolder.
If not, then finally go to mRecyclerPool to find it. If the itemType type matches the corresponding ViewHolder, then return the instance and let it 重新绑定数据.
If mRecyclerPool does not return ViewHolder, it will be called createViewHolder()to create one again.

Here are a few things to note:

The ViewHolder obtained in mChangedScrap, mAttachedScrap, and mCachedViews are all accurate matches.
mAttachedScrap and mCachedViews have not changed and are used directly.
Because mChangedScrap has changed and mRecyclerPool has been erased, it is necessary to call onBindViewHolder()rebind data before it can be used.