锐客网

  1. 首页 > it技术 > >

让你彻底掌握RecyclerView的缓存机制

前言 【让你彻底掌握RecyclerView的缓存机制】RecyclerView这个控件几乎所有的Android开发者都使用过（甚至不用加几乎），它是真的很好用，完美取代了ListView和GridView，而RecyclerView之所以好用，得益于它优秀的缓存机制。关于RecyclerView缓存机制，更是需要我们开发者来掌握的。本文就将先从整体流程看RecyclerView的缓存，再带你从源码角度分析，跳过读源码的坑，最后用一个简单的demo的形式展示出来。在开始RecyclerView的缓存机制之前我们先学习关于ViewHolder的知识。
RecyclerView为什么强制我们实现ViewHolder模式？ 关于这个问题，我们首先看一下ListView。ListView是不强制我们实现ViewHolder的，但是后来google建议我们实现ViewHolder模式。我们先分别看一下这两种不同的方式。

让你彻底掌握RecyclerView的缓存机制
文章图片
不使用ViewHolder的模式
让你彻底掌握RecyclerView的缓存机制
文章图片
使用ViewHolder的模式
其实这里我已经用红框标出来了，ListView使用ViewHolder的好处就在于可以避免每次getView都进行findViewById()操作，因为findViewById()利用的是DFS算法（深度优化搜索），是非常耗性能的。而对于RecyclerView来说，强制实现ViewHolder的其中一个原因就是避免多次进行findViewById（）的处理，另一个原因就是因为ItemView和ViewHolder的关系是 一对一，也就是说一个ViewHolder对应一个ItemView。这个ViewHolder当中持有对应的ItemView的所有信息，比如说：position；view；width等等，拿到了ViewHolder基本就拿到了ItemView的所有信息，而ViewHolder使用起来相比itemView更加方便。RecyclerView缓存机制缓存的就是 ViewHolder（ListView缓存的是ItemView），这也是为什么RecyclerView为什么强制我们实现ViewHolder的原因。
Listview的缓存机制 在正式讲RecyclerView的缓存机制之前还需要提一嘴ListView的缓存机制，不多BB，先上图

让你彻底掌握RecyclerView的缓存机制
文章图片
listview缓存页面.png
ListView的缓存有两级，在ListView里面有一个内部类 RecycleBin，RecycleBin有两个对象Active View和Scrap View来管理缓存，Active View是第一级，Scrap View是第二级。

  • Active View：是缓存在屏幕内的ItemView，当列表数据发生变化时，屏幕内的数据可以直接拿来复用，无须进行数据绑定。
  • Scrap view：缓存屏幕外的ItemView，这里所有的缓存的数据都是"脏的"，也就是数据需要重新绑定，也就是说屏幕外的所有数据在进入屏幕的时候都要走一遍getView（）方法。
    再来一张图，看看ListView的缓存流程
    让你彻底掌握RecyclerView的缓存机制
    文章图片
    lisview.png
    当Active View和Scrap View中都没有缓存的时候就会直接create view。
小结
ListView的缓存机制相对比较好理解，它只有两级缓存，一级缓存Active View是负责屏幕内的ItemView快速复用，而Scrap View是缓存屏幕外的数据，当该数据从屏幕外滑动到屏幕内的时候需要走一遍getView（）方法。
RecyclerView的缓存机制 先上图

让你彻底掌握RecyclerView的缓存机制
文章图片
RecyclerView缓存.png
RecyclerView的缓存分为四级
  • Scrap
  • Cache
  • ViewCacheExtension
  • RecycledViewPool
Scrap对应ListView 的Active View，就是屏幕内的缓存数据，就是相当于换了个名字，可以直接拿来复用。
Cache 刚刚移出屏幕的缓存数据，默认大小是2个，当其容量被充满同时又有新的数据添加的时候，会根据FIFO原则，把优先进入的缓存数据移出并放到下一级缓存中，然后再把新的数据添加进来。Cache里面的数据是干净的，也就是携带了原来的ViewHolder的所有数据信息，数据可以直接来拿来复用。需要注意的是，cache是根据position来寻找数据的，这个postion是根据第一个或者最后一个可见的item的position以及用户操作行为（上拉还是下拉）。
举个栗子：当前屏幕内第一个可见的item的position是1，用户进行了一个下拉操作，那么当前预测的position就相当于（1-1=0），也就是position=0的那个item要被拉回到屏幕，此时RecyclerView就从Cache里面找position=0的数据，如果找到了就直接拿来复用。
ViewCacheExtension是google留给开发者自己来自定义缓存的，这个ViewCacheExtension我个人建议还是要慎用，因为我扒拉扒拉网上其他的博客，没有找到对应的使用场景，而且这个类的api设计的也有些奇怪，只有一个public abstract View getViewForPositionAndType(@NonNull Recycler recycler, int position, int type); 让开发者重写通过position和type拿到ViewHolder的方法，却没有提供如何产生ViewHolder或者管理ViewHolder的方法，给人一种只出不进的赶脚，还是那句话慎用。
RecycledViewPool刚才说了Cache默认的缓存数量是2个，当Cache缓存满了以后会根据FIFO（先进先出）的规则把Cache先缓存进去的ViewHolder移出并缓存到RecycledViewPool中，RecycledViewPool默认的缓存数量是5个。RecycledViewPool与Cache相比不同的是，从Cache里面移出的ViewHolder再存入RecycledViewPool之前ViewHolder的数据会被全部重置，相当于一个新的ViewHolder，而且Cache是根据position来获取ViewHolder，而RecycledViewPool是根据itemType获取的，如果没有重写getItemType（）方法，itemType就是默认的。因为RecycledViewPool缓存的ViewHolder是全新的，所以取出来的时候需要走onBindViewHolder（）方法。
再来张图看看整体流程

让你彻底掌握RecyclerView的缓存机制
文章图片
RecyclerView流程.png
这里大家先记住主要流程，并且记住各级缓存是根据什么拿到ViewHolder以及ViewHolder能否直接拿来复用，先有一个整体的认识，下面我会带着大家再简单分析一下RecyclerView缓存机制的源码。
阅读RecyclerView的缓存机制源码 由于篇幅和内容的关系，我不可能带大家一行一行读，这里我只列出关键点，还有哪些需要重点看，哪些可以直接略过，避免大家陷入读源码一个劲儿钻进去出不来的误区。
当RecyclerView绘制的时候，会走到LayoutManager里面的next()方法，在next()里面是正式开始使用缓存机制，这里以LinearLayoutManager为例子
/** * Gets the view for the next element that we should layout. * Also updates current item index to the next item, based on {@link #mItemDirection} * * @return The next element that we should layout. */ View next(RecyclerView.Recycler recycler) { if (mScrapList != null) { return nextViewFromScrapList(); } final View view = recycler.getViewForPosition(mCurrentPosition); mCurrentPosition += mItemDirection; return view; }

在next方法里传入了Recycler对象，这个对象是RecyclerView的内部类。我们先去看一眼这个类
public final class Recycler { final ArrayList mAttachedScrap = new ArrayList<>(); ArrayList mChangedScrap = null; final ArrayList mCachedViews = new ArrayList(); private final List mUnmodifiableAttachedScrap = Collections.unmodifiableList(mAttachedScrap); private int mRequestedCacheMax = DEFAULT_CACHE_SIZE; int mViewCacheMax = DEFAULT_CACHE_SIZE; RecycledViewPool mRecyclerPool; private ViewCacheExtension mViewCacheExtension; static final int DEFAULT_CACHE_SIZE = 2; }

再看一眼RecycledViewPool的源码
public static class RecycledViewPool { private static final int DEFAULT_MAX_SCRAP = 5; static class ScrapData { final ArrayList mScrapHeap = new ArrayList<>(); int mMaxScrap = DEFAULT_MAX_SCRAP; long mCreateRunningAverageNs = 0; long mBindRunningAverageNs = 0; } SparseArray mScrap = new SparseArray<>();

其中mAttachedScrap对应Scrap；mCachedViews对应Cache；mViewCacheExtension对应ViewCacheExtension；mRecyclerPool对应RecycledViewPool。
注意：mAttachedScrap、mCachedViews和RecycledViewPool里面的mScrapHeap都是ArrayList，缓存被加入到这三个对象里面实际上就是调用的ArrayList.add()方法，复用缓存呢，这里要注意一下不是调用的ArrayList.get（）而是ArrayList.remove(),其实这里也很好理解，因为当缓存数据被取出来展示到了屏幕内，自然就应该被移除。
我们现在回到刚才的next（）方法里，recycler.getViewForPosition(mCurrentPosition); 直接去看getViewForPosition这个方法，接着跟到了这里
View getViewForPosition(int position, boolean dryRun) { return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView; }

接着跟进去
ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) { if (position < 0 || position >= mState.getItemCount()) { throw new IndexOutOfBoundsException("Invalid item position " + position + "(" + position + "). Item count:" + mState.getItemCount() + exceptionLabel()); } boolean fromScrapOrHiddenOrCache = false; ViewHolder holder = null; // 0) If there is a changed scrap, try to find from there if (mState.isPreLayout()) { holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; } // 1) Find by position from scrap/hidden list/cache if (holder == null) { holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); } if (holder == null) { final int type = mAdapter.getItemViewType(offsetPosition); // 2) Find from scrap/cache via stable ids, if exists if (mAdapter.hasStableIds()) { holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition), type, dryRun); if (holder != null) { // update position holder.mPosition = offsetPosition; fromScrapOrHiddenOrCache = true; } } if (holder == null && mViewCacheExtension != null) { // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension .getViewForPositionAndType(this, position, type); if (view != null) { holder = getChildViewHolder(view); } } if (holder == null) { // fallback to pool if (DEBUG) { Log.d(TAG, "tryGetViewHolderForPositionByDeadline(" + position + ") fetching from shared pool"); } holder = getRecycledViewPool().getRecycledView(type); if (holder != null) { holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) { invalidateDisplayListInt(holder); } } } if (holder == null) { long start = getNanoTime(); if (deadlineNs != FOREVER_NS && !mRecyclerPool.willCreateInTime(type, start, deadlineNs)) { // abort - we have a deadline we can't meet return null; } holder = mAdapter.createViewHolder(RecyclerView.this, type); if (ALLOW_THREAD_GAP_WORK) { // only bother finding nested RV if prefetching RecyclerView innerView = findNestedRecyclerView(holder.itemView); if (innerView != null) { holder.mNestedRecyclerView = new WeakReference<>(innerView); } } } } boolean bound = false; if (mState.isPreLayout() && holder.isBound()) { // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; } else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) { if (DEBUG && holder.isRemoved()) { throw new IllegalStateException("Removed holder should be bound and it should" + " come here only in pre-layout. Holder: " + holder + exceptionLabel()); } final int offsetPosition = mAdapterHelper.findPositionOffset(position); bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); } return holder; }

终于到了缓存机制最核心的地方，为了方便大家阅读，我对这部分源码进行了删减，直接从官方给的注释里面看。
// (0) If there is a changed scrap, try to find from there if (mState.isPreLayout()) { holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; }

这里面只有设置动画以后才会为true，跟咱们讲的缓存也没有多大关系，直接略过。
// 1) Find by position from scrap/hidden list/cache if (holder == null) { holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); }

这里就开始拿第一级和第二级缓存了getScrapOrHiddenOrCachedHolderForPosition（）这个方法可以深入去看以下，注意这里传的参数是position（dryRun这个参数不用管），就跟我之前说的，Scrap和Cache是根据position拿到缓存。
if (holder == null && mViewCacheExtension != null) { // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension .getViewForPositionAndType(this, position, type); if (view != null) { holder = getChildViewHolder(view); } }

这里开始拿第三级缓存了，这里我们不自定义ViewCacheExtension就不会进入判断条件，还是那句话慎用。
if (holder == null) { // fallback to pool if (DEBUG) { Log.d(TAG, "tryGetViewHolderForPositionByDeadline(" + position + ") fetching from shared pool"); } holder = getRecycledViewPool().getRecycledView(type); if (holder != null) { holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) { invalidateDisplayListInt(holder); } } }

这里到了第四级缓存RecycledViewPool，getRecycledViewPool().getRecycledView(type); 通过type拿到ViewHolder，接着holder.resetInternal(); 重置ViewHolder，让其变成一个全新的ViewHolder
if (holder == null) { long start = getNanoTime(); if (deadlineNs != FOREVER_NS && !mRecyclerPool.willCreateInTime(type, start, deadlineNs)) { // abort - we have a deadline we can't meet return null; } holder = mAdapter.createViewHolder(RecyclerView.this, type); if (ALLOW_THREAD_GAP_WORK) { // only bother finding nested RV if prefetching RecyclerView innerView = findNestedRecyclerView(holder.itemView); if (innerView != null) { holder.mNestedRecyclerView = new WeakReference<>(innerView); } } }

到这里如果ViewHolder还为null的话，就会create view了，创建一个新的ViewHolder
boolean bound = false; if (mState.isPreLayout() && holder.isBound()) { // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; } else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) { if (DEBUG && holder.isRemoved()) { throw new IllegalStateException("Removed holder should be bound and it should" + " come here only in pre-layout. Holder: " + holder + exceptionLabel()); } final int offsetPosition = mAdapterHelper.findPositionOffset(position); bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); }

这里else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid())是判断这个ViewHolder是不是有效的，也就是可不可以复用，如果不可以复用就会进入tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); 这个方法，在这里面调用了bindViewHolder（）方法。
点进去看一眼
private boolean tryBindViewHolderByDeadline(@NonNull ViewHolder holder, int offsetPosition, int position, long deadlineNs) { .................... mAdapter.bindViewHolder(holder, offsetPosition); .................... return true; }

在点进去就到了我们熟悉的onBindViewHolder（）
public final void bindViewHolder(@NonNull VH holder, int position) { ....................... onBindViewHolder(holder, position, holder.getUnmodifiedPayloads()); ......................... }

至此，缓存机制的整体流程就全部分析完毕了。
小结
ListView有两级缓存，分别是Active View和Scrap View，缓存的对象是ItemView；而RecyclerView有四级缓存，分别是Scrap、Cache、ViewCacheExtension和RecycledViewPool，缓存的对象是ViewHolder。Scrap和Cache分别是通过position去找ViewHolder可以直接复用；ViewCacheExtension自定义缓存，目前来说应用场景比较少却需慎用；RecycledViewPool通过type来获取ViewHolder，获取的ViewHolder是个全新，需要重新绑定数据。当你看到这里的时候，面试官再问RecyclerView的性能比ListView优化在哪里，我想你已经有答案。
通过Demo再理解一遍 担心你看完上面的内容，倒头就忘，我们写个简单的demo通过打印log的方式来巩固一下学到的知识。
简单说一下Demo里面需要注意的代码，下面是对RecyclerView的一个包装
public class RecyclerViewWrapper extends RecyclerView { privateLayoutListener layoutListener; public RecyclerViewWrapper(@NonNull Context context) { super(context); }public RecyclerViewWrapper(@NonNull Context context, @Nullable AttributeSet attrs) { super(context, attrs); }public RecyclerViewWrapper(@NonNull Context context, @Nullable AttributeSet attrs, int defStyle) { super(context, attrs, defStyle); }public void setLayoutListener(LayoutListener layoutListener) { this.layoutListener = layoutListener; }@Override protected void onLayout(boolean changed, int l, int t, int r, int b) { if (layoutListener != null) { layoutListener.onBeforeLayout(); } super.onLayout(changed, l, t, r, b); if (layoutListener != null) { layoutListener.onAfterLayout(); } }public interface LayoutListener {void onBeforeLayout(); void onAfterLayout(); }}

其实很简单，在RecyclerView执行onLayout（）方法前后执行一下咱们打印缓存变化的方法
再看一眼打印缓存变化的方法，利用反射的技术
/** * 利用java反射机制拿到RecyclerView内的缓存并打印出来 * */ private void showMessage(RecyclerViewWrapper rv) { try { Field mRecycler = Class.forName("androidx.recyclerview.widget.RecyclerView").getDeclaredField("mRecycler"); mRecycler.setAccessible(true); RecyclerView.Recycler recyclerInstance = (RecyclerView.Recycler) mRecycler.get(rv); Class recyclerClass = Class.forName(mRecycler.getType().getName()); Field mViewCacheMax = recyclerClass.getDeclaredField("mViewCacheMax"); Field mAttachedScrap = recyclerClass.getDeclaredField("mAttachedScrap"); Field mChangedScrap = recyclerClass.getDeclaredField("mChangedScrap"); Field mCachedViews = recyclerClass.getDeclaredField("mCachedViews"); Field mRecyclerPool = recyclerClass.getDeclaredField("mRecyclerPool"); mViewCacheMax.setAccessible(true); mAttachedScrap.setAccessible(true); mChangedScrap.setAccessible(true); mCachedViews.setAccessible(true); mRecyclerPool.setAccessible(true); int mViewCacheSize = (int) mViewCacheMax.get(recyclerInstance); ArrayListWrapper mAttached = (ArrayListWrapper) mAttachedScrap.get(recyclerInstance); ArrayList mChanged = (ArrayList) mChangedScrap.get(recyclerInstance); ArrayList mCached = (ArrayList) mCachedViews.get(recyclerInstance); RecyclerView.RecycledViewPool recycledViewPool = (RecyclerView.RecycledViewPool) mRecyclerPool.get(recyclerInstance); Class recyclerPoolClass = Class.forName(mRecyclerPool.getType().getName()); Log.e(TAG, "mAttachedScrap（一缓） size is:" + mAttached.maxSize + ", \n" + "mCachedViews（二缓） max size is:" + mViewCacheSize + "," + getMCachedViewsInfo(mCached) + getRVPoolInfo(recyclerPoolClass, recycledViewPool)); } catch (Exception e) { e.printStackTrace(); } }

核心的代码呢就这两块，文章的最后我会把我的demo上传到github上。
注意：本文使用的RecyclerView的版本是androidx，在调onAttachedToWindow()方法的时候会进行版本判断，如果是5.0以及以上的系统（即大于等于21），GapWorker会把RecyclerView自己加入到GapWorker。在RenderThread线程执行预取操作的时候会mPrefetchMaxCountObserved = 1，这就会导致你使用5.0以及以上系统的手机打印缓存数量的时候会比你预想的多一个。这里为了不造成这种问题，本文使用4.4系统的Android模拟器来演示Demo。
Demo演示效果截图
  • 启动App，第一次加载的情况

    让你彻底掌握RecyclerView的缓存机制
    文章图片
    第一次启动app加载
    初始化加载只有屏幕内的一级缓存7个
  • 把position = 0 和position=1 两个item移除屏幕

    让你彻底掌握RecyclerView的缓存机制
    文章图片
    前两个item移除屏幕
    看蓝色框出来的，position = 0 和position = 1的item被加入到了Cache缓存中，Cache的缓存数量我没有修改，默认2个，也就说现在已经满了
  • 再把position = 2的item也移除屏幕

    让你彻底掌握RecyclerView的缓存机制
    文章图片
    position = 2的item也移除屏幕
因为上一步Cache里面的缓存已经慢了，此时position = 2又被加入缓存，根据FIFO的原则，cache里面position = 0 被remove掉并加入到了四级缓存RecycledView里面，此时RecycledView也有了缓存并且该缓存没有任何有效数据信息。
  • 再上一步的基础上下拉一下，把position = 2的item显示出来

    让你彻底掌握RecyclerView的缓存机制
    文章图片
    把position = 2的item显示出来
    此时position = 2的item将要被显示出来，会先从cache里面找，发现Cache正好有position = 2的缓存就直接拿出来复用了，并且原来在屏幕里的position= 9 的item被移除了，就会加入到Cache的缓存里
    -----------------------------------分割线-------------------------------------------
    现在看一下onCreateViewHolder（）和onBindViewHolder（）的情况
  • 还是启动App，第一次加载后，再把position = 0和position =1的item移除屏幕再移回来

    让你彻底掌握RecyclerView的缓存机制
    文章图片
    显示效果 onBindViewHolder（）方法没有被重复执行（静态图显示的效果不是很好，gif录制的质量太差了，还是建议下载demo自己尝试一下）
  • 最后留一个问题给大家

    让你彻底掌握RecyclerView的缓存机制
    文章图片
    onCreateViewHolder不再执行
    为什么在第10次onCreateViewHolder（）执行以后就再也没有执行过onCreateViewHolder（）方法了？
总结 关于RecyclerView的缓存分为四级，Scrap、Cache、ViewCacheExtension和RecycledViewPool。Scrap是屏幕内的缓存一般我们不怎么需要特别注意；Cache可直接拿来复用的缓存，性能高效；ViewCacheExtension需要开发者自定义的缓存，API设计比较奇怪，慎用；RecycledViewPool四级缓存，可以避免用户调用onCreateViewHolder（）方法，提高性能，在ViewPager+RecyclerView的应用场景下可以大有作为。以上就是关于RecyclerView缓存的所有内容，另外要备注一下，就是文章的图片上有些单词打错了，实在是懒得重画了，以文本的内容为准，请大家见谅。
最后是github的地址:RecyclerViewCacheDemo

    推荐阅读


    上一篇：春节假期结束全国今起陆续复工（超15类抗疫服务支付宝一站获取）

    下一篇：玻璃钢化粪池营销