RecyclerView源码解析（三）：RecyclerView的缓存机制
RecyclerView源码解析（三）：RecyclerView的缓存机制
导言
上两篇文章我们结合LinearLayoutManager对RecyclerView整体是如何绘制的有了大致的了解，不过RecyclerView的重头戏并不是简单显示列表，而是它通过缓存机制实现的高性能，本篇文章我们继续对源码进行分析来解析RecyclerView最重要的缓存机制。
关于viewHolder的状态
在RecyclerView中，ViewHolder作为视图的持有者会处于各种不同的状态，下面是可能出现的状态:
- Attached（附加）：ViewHolder 附加到 RecyclerView 中的父视图，它是可见的并可以响应用户输入事件。在这个状态下，ViewHolder 可以被看到，而且可以与用户进行交互。
- Detached（分离）：ViewHolder 不再附加到 RecyclerView 中的父视图，它不再可见。在这个状态下，ViewHolder 可能已经超出了屏幕可见范围，或者它已经从 RecyclerView 中分离，但尚未被回收。
- Recycled（回收）：ViewHolder 被回收，通常是因为它不再可见或不再需要。在这个状态下，ViewHolder 的视图资源被释放，但ViewHolder 对象本身可能会被保留在 RecyclerView 的回收池中，以便稍后重用。
- Invalid（无效）：ViewHolder 被标记为无效，通常表示该 ViewHolder 对应的数据项已经发生了变化。在这个状态下，ViewHolder 可能需要重新绑定以反映最新的数据。
- Removed（移除）：ViewHolder 被标记为已移除，通常表示该 ViewHolder 对应的数据项已从适配器数据集中删除。这个状态通常会伴随着一些动画效果，直到 ViewHolder 完全离开屏幕。
- Update（更新）：ViewHolder 被标记为需要更新，通常表示 ViewHolder 所对应的数据发生了部分更改，需要进行局部更新而不是完全的重新绑定。
而源文件中也有各种各样的FLAG标志位的定义和注释，这里介绍一些经常会出现的标志位：
-
FLAG_BOUND标志： 表示 ViewHolder 已经绑定到了一个数据位置上，ViewHolder 的mPosition、mItemId和mItemViewType都已经设置为有效值。 -
FLAG_UPDATE标志：表示 ViewHolder 的视图所反映的数据已经过时，需要由适配器重新绑定。ViewHolder 的mPosition和mItemId仍然保持有效，但是需要重新执行数据绑定操作以更新视图的内容。(区别于完全重新绑定，viewType还是没变) -
FLAG_INVALID标志： 表示 ViewHolder 的数据无效。ViewHolder 的mPosition和mItemId不再可信，而且可能不再匹配项视图的类型。这意味着 ViewHolder 需要完全重新绑定到不同的数据项，通常是因为与之前的数据不再匹配。这个标志位用于通知 RecyclerView，特定的 ViewHolder 需要进行完全的重新绑定。 -
FLAG_REMOVED标志：表示 ViewHolder 对应的数据项曾经从数据集中移除。但是，它的视图可能仍然可以用于执行一些操作，例如进行退出动画。这个标志位用于标记 ViewHolder 对应的数据项已被移除，但 RecyclerView 可能仍然需要对其执行一些动画等操作。 -
FLAG_NOT_RECYCLABLE标志：表示 ViewHolder 不应该被回收。通常，RecyclerView 会尝试回收不再需要的 ViewHolder 以便节省内存和性能。然而，在某些情况下，你可能希望保持 ViewHolder 不被回收，比如在执行动画时需要保持视图。 -
FLAG_RETURNED_FROM_SCRAP标志：表示这个 ViewHolder 是从废弃状态返回的。当一个 ViewHolder 从废弃状态返回时，它会保留在废弃列表中，直到布局过程结束，然后如果没有重新添加到 RecyclerView 中，它会被 RecyclerView 回收。 -
FLAG_IGNORE标志： 表示这个 ViewHolder 被布局管理器完全管理。它不会被废弃、回收或移除，除非布局管理器被替换。这个 ViewHolder 对布局管理器来说仍然是完全可见的。通常情况下，这种标志用于标识 RecyclerView 中的某些视图应该由布局管理器自己处理，而不被 RecyclerView 的回收和复用系统管理。 -
FLAG_TMP_DETACHED标志：表示当视图从父视图中分离（detached）时，设置了这个标志，以便在需要将其移除或添加回来时采取正确的操作。这个标志通常用于处理视图的临时分离状态。
源码解析
从next方法开始
解析缓存机制的话我们还是以LinearLayoutManager为例，从它的next方法作为切入点进行分析，因为在布局是LinearLayoutManager是通过next方法来获取下一个布局的视图的，来看next方法：
View next(RecyclerView.Recycler recycler) {
if (mScrapList != null) {
return nextViewFromScrapList();
}
final View view = recycler.getViewForPosition(mCurrentPosition);
mCurrentPosition += mItemDirection;
return view;
}
这个方法张红出现了一个mScrapList变量，根据注释：
在RecyclerView中，LayoutManager（LLM）可以设置一个mScrapList（或称为"废弃列表"）来存储特定的ViewHolder对象。当LayoutManager需要布局特定的视图时，它将这些视图的ViewHolder对象添加到mScrapList中。然后，在LayoutState中，当需要获取下一个要布局的视图时，会首先尝试从mScrapList中获取ViewHolder对象，如果找到则返回，否则返回null。
这个机制的目的是提高性能，因为LayoutManager在进行布局时可能需要多次获取ViewHolder对象，而不必每次都从Recycler中获取。通过使用mScrapList，LayoutManager可以在内部管理一组特定的ViewHolder对象，以提高布局效率。
需要注意的是，mScrapList是一个临时的列表，用于特定的布局操作，它不会永久存储ViewHolder对象。这些ViewHolder对象仍然受Recycler的管理，并可以被回收和重用。
我们可以把这个mScrapList看做是一个由LinearLayoutManager管理的缓存列表，不过它不会永久存储ViewHolder对象。这些ViewHolder对象仍然受Recycler的管理，并可以被回收和重用。RecyclerView实现缓存主要也不是依赖于LayoutManager类，而是通过RecyclerView自身的Recycler回收池，就比如之后就调用了recycler.getViewForPosition(mCurrentPosition)，这就是通过Recycler来获取view的。我们首先大致看一看Recycler类的大致结构。
Recycler类
这个类也有必要的注释：
Recycler（回收器）是负责管理被丢弃或分离的视图以供重用的组件。
"被丢弃"的视图是指仍然附加到其父RecyclerView但已被标记为要删除或重用的视图。
RecyclerView.LayoutManager通常通过Recycler来获取适配器的数据集中特定位置或项ID的视图。如果要重用的视图被认为是 “脏的”，则适配器将被要求重新绑定它。如果不是脏视图，LayoutManager可以快速地重新使用它，而无需进一步的工作。未请求布局的干净视图可能会被LayoutManager重新定位，而无需重新测量。Recycler的主要作用是协助RecyclerView的LayoutManager有效地管理和重用视图，以提高性能和滚动的流畅性。
如果要对数据进行缓存的话，显然需要一些成员变量来作为容器，我们正好可以在Recycler类中发现这些成员变量:
final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>();//一级缓存
final ArrayList<ViewHolder> mCachedViews = new ArrayList<ViewHolder>();//二级缓存
RecycledViewPool mRecyclerPool;//四级缓存
private ViewCacheExtension mViewCacheExtension;//三级缓存
主要是通过这四级缓存来构建起来了整个RecyclerView的缓存机制。
何处真正获取到View对象
tryGetViewHolderForPositionByDeadline方法的第一部分
前面说到，next方法中将通过recycler.getViewForPosition(mCurrentPosition)方法来试图获取到View，而这个方法实际上又会跳转到别的方法中，最终会调用到RecyclerView的tryGetViewHolderForPositionByDeadline方法中，同样的，这个方法也有注释：
这段注释可以说是很重要，因为它清楚地指出了view的获取来源：
这段代码描述了RecyclerView中的一个方法，用于获取给定位置的ViewHolder。ViewHolder是用来显示RecyclerView中的每个项的视图容器。这个方法的作用是尝试从不同的来源获取ViewHolder，包括Recycler的临时存储(scrap)、缓存(cache)、RecycledViewPool（用于存储被回收的视图）、或者直接创建ViewHolder。
这就指明了常用的三个缓存区，分别就是mAttachedScrap，mCachedViews和mRecyclerPool.接下来分析这个方法，把这个方法拆解成几个步骤：
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;
}
这一步将根据当前是否在进行预布局来决定是否要通过 getChangedScrapViewForPosition(position)方法来获得ViewHolder。这个是否正在进行预布局是在哪里设置的呢？在RecyclerView中这个标志位主要是根据另一个标志位mRunPredictiveAnimations来决定的，当该标志位为true时才需要进行预布局。而这个mRunPredictiveAnimations又需要mRunSimpleAnimations标志位来决定，总的来说如果有动画的话才会进行预布局，默认状态下是为false的。
// 1) Find by position from scrap/hidden list/cache
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
if (holder != null) {
if (!validateViewHolderForOffsetPosition(holder)) {
// recycle holder (and unscrap if relevant) since it can't be used
if (!dryRun) {
// we would like to recycle this but need to make sure it is not used by
// animation logic etc.
holder.addFlags(ViewHolder.FLAG_INVALID);
if (holder.isScrap()) {
removeDetachedView(holder.itemView, false);
holder.unScrap();
} else if (holder.wasReturnedFromScrap()) {
holder.clearReturnedFromScrapFlag();
}
recycleViewHolderInternal(holder);
}
holder = null;
} else {
fromScrapOrHiddenOrCache = true;
}
}
}
当在之前的判断中没有获得holder的情况下先会调用getScrapOrHiddenOrCachedHolderForPosition来获得来自mAttachedScrap,mHiddenViews或者mCachedViews中的holder,这其实就是从缓存中获取数据。我们可以根据从获取数据三个缓存区为分界，将这个方法分成三个部分，分别就是从mAttachedScrap,mHiddenViews和mCachedViews中获取holder的过程，查看该方法的具体逻辑：
final int scrapCount = mAttachedScrap.size();
// Try first for an exact, non-invalid match from scrap.
for (int i = 0; i < scrapCount; i++) {
final ViewHolder holder = mAttachedScrap.get(i);
if (!holder.wasReturnedFromScrap() && holder.getLayoutPosition() == position
&& !holder.isInvalid() && (mState.mInPreLayout || !holder.isRemoved())) {
holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP);
return holder;
}
}
第一部分会首先尝试在mAttachedScrap中获取holder，如果当前holder在之前尚未被从mAttachedScrap返回的话（即是首次从mAttachedScrap中返回），且满足布局位置与布局位置相同等一系列条件的话，就说明当前的holder是可以重用的。如果可以重用的话就会标记当前holder已经被重用了，最后就可以返回获得的holder了。
if (!dryRun) {
View view = mChildHelper.findHiddenNonRemovedView(position);
if (view != null) {
// This View is good to be used. We just need to unhide, detach and move to the
// scrap list.
final ViewHolder vh = getChildViewHolderInt(view);
mChildHelper.unhide(view);
int layoutIndex = mChildHelper.indexOfChild(view);
if (layoutIndex == RecyclerView.NO_POSITION) {
throw new IllegalStateException("layout index should not be -1 after "
+ "unhiding a view:" + vh + exceptionLabel());
}
mChildHelper.detachViewFromParent(layoutIndex);
scrapView(view);
vh.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP
| ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST);
return vh;
}
}
第二部分会尝试从HiddenView中获取，也就是从隐藏列表中获取view，然后根据这个view构建出一个viewHolder，把这个viewHolder添加进入Scrap中，接着会设置标志位以表明该view已经被重用，最后返回viewHolder。需要解释的是这个dryRun标志位，这个用于指示是否执行 “干运行”，也就是在查找ViewHolder时不执行真正的操作，而只是找到匹配的ViewHolder但不进行后续的移除或处理操作。这个参数通常用于在不实际操作ViewHolder的情况下，只是查找匹配的ViewHolder并返回它，以便后续根据需要进行操作。如果 dryRun 为 true，那么操作是干净的，不会对数据产生实际影响；如果为 false，那么操作将会对数据产生实际影响，比如从缓存中移除ViewHolder。
// Search in our first-level recycled view cache.
final int cacheSize = mCachedViews.size();
for (int i = 0; i < cacheSize; i++) {
final ViewHolder holder = mCachedViews.get(i);
// invalid view holders may be in cache if adapter has stable ids as they can be
// retrieved via getScrapOrCachedViewForId
if (!holder.isInvalid() && holder.getLayoutPosition() == position
&& !holder.isAttachedToTransitionOverlay()) {
if (!dryRun) {
mCachedViews.remove(i);
}
if (DEBUG) {
Log.d(TAG, "getScrapOrHiddenOrCachedHolderForPosition(" + position
+ ") found match in cache: " + holder);
}
return holder;
}
}
第三部分是会尝试从mCachedViews获取holder，注释中也提到这是尝试从第一级回收视图缓存。它会依次获取并检查这个holder的状态，如果该holder有效，布局位置与所需的位置匹配，以及ViewHolder没有附加到过渡叠加层（transition overlay）上的话就可以返回这个holder。如果没有被标记为dryRun的话还有从缓存中将该holder给移除。
可以用一个流程图概括一下这个方法：
tryGetViewHolderForPositionByDeadline方法的第二部分
书接上段，让我们继续回到tryGetViewHolderForPositionByDeadline方法中：
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
if (holder != null) {
if (!validateViewHolderForOffsetPosition(holder)) {
// recycle holder (and unscrap if relevant) since it can't be used
if (!dryRun) {
// we would like to recycle this but need to make sure it is not used by
// animation logic etc.
holder.addFlags(ViewHolder.FLAG_INVALID);
if (holder.isScrap()) {
removeDetachedView(holder.itemView, false);
holder.unScrap();
} else if (holder.wasReturnedFromScrap()) {
holder.clearReturnedFromScrapFlag();
}
recycleViewHolderInternal(holder);
}
holder = null;
} else {
fromScrapOrHiddenOrCache = true;
}
}
}
如果在getScrapOrHiddenOrCachedHolderForPosition方法中获得了holder的话就会对该holder的有效性再次进行验证validateViewHolderForOffsetPosition(holder)方法，如果holder无效的话就会进入到接下来的分支中对该holder进行一些处理：
- 如果 ViewHolder 是从缓存中取出的（
holder.isScrap()返回 true），它会将 ViewHolder 的 itemView（视图）从 RecyclerView 中移除，并将 ViewHolder 标记为未被回收状态（holder.unScrap()）。 - 如果 ViewHolder 是从回收池中返回的（
holder.wasReturnedFromScrap()返回 true），它会清除 ViewHolder 的返回自回收池标志。 - 最后，无论是哪种情况，都会调用
recycleViewHolderInternal(holder)方法将 ViewHolder 回收，即将其添加回 RecyclerView 的回收池中。
第一个isScrap在之前的获得holder的方法有所体现，是在HiddenView中查找的流程中，查找到的话会调用一个scrapView方法，调用这个方法后isScrap就会被设置为true了。如果之前获得的holder有效的话将 fromScrapOrHiddenOrCache 标志设置为 true，以表示它是从缓存或隐藏状态中获取的。
总的来说这第二部分是对之前获得到的ViewHolder进行验证，如果无法使用，则将其标记为无效并回收；如果可以使用，则将其标记为来自缓存或隐藏状态。这是为了确保 RecyclerView 中的 ViewHolder 在正确的位置使用，以避免出现问题。
tryGetViewHolderForPositionByDeadline方法的第三部分
if (holder == null) {
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
.......
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;
}
}
.........
}
这第三部分对应的是Adapter有StableIds的情况，hasStableIds() 是 RecyclerView.Adapter 类的一个方法，用于指示 RecyclerView 的适配器是否为数据集中的每个项提供了稳定的唯一标识符（ID）。这个标识符可以作为数据集中给定位置上的项的键，如果该项在数据集中重新定位，那么应该返回相同的 ID。
在这一部分将会通过getScrapOrCachedViewForId方法从Scrap中或者CachedView中获得ViewHolder。来看这个方法的第一部分：
// Look in our attached views first
final int count = mAttachedScrap.size();
for (int i = count - 1; i >= 0; i--) {
final ViewHolder holder = mAttachedScrap.get(i);
if (holder.getItemId() == id && !holder.wasReturnedFromScrap()) {
if (type == holder.getItemViewType()) {
holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP);
if (holder.isRemoved()) {
// this might be valid in two cases:
// > item is removed but we are in pre-layout pass
// >> do nothing. return as is. make sure we don't rebind
// > item is removed then added to another position and we are in
// post layout.
// >> remove removed and invalid flags, add update flag to rebind
// because item was invisible to us and we don't know what happened in
// between.
if (!mState.isPreLayout()) {
holder.setFlags(ViewHolder.FLAG_UPDATE, ViewHolder.FLAG_UPDATE
| ViewHolder.FLAG_INVALID | ViewHolder.FLAG_REMOVED);
}
}
return holder;
} else if (!dryRun) {
// if we are running animations, it is actually better to keep it in scrap
// but this would force layout manager to lay it out which would be bad.
// Recycle this scrap. Type mismatch.
mAttachedScrap.remove(i);
removeDetachedView(holder.itemView, false);
quickRecycleScrapView(holder.itemView);
}
}
}
和之前第一部分获取holder的方法很类似，会尝试从mAttachedScrap获取holder，如果holder有效且type符合就会返回这个holder并将该holder标记为已重用。如果type不符合的话还会将该holder从mAttachedScrap给移除并将其视图分离，最后将该试图拆解并回收。最后这个quickRecycleScrapView方法会继续向后调用recyclerViewHolderInternal方法，这个方法是用来回收ViewHolder的，会试图将ViewHolder回收入mRecyclerPool或者mCachedViews中。我们看看这个方法：
void recycleViewHolderInternal(ViewHolder holder) {
......
if (forceRecycle || holder.isRecyclable()) {
.......
if (cachedViewSize >= mViewCacheMax && cachedViewSize > 0) {
recycleCachedViewAt(0);//从mCachedViews中移除并且将其添加进入RecyclerPool中
cachedViewSize--;
}
.......
mCachedViews.add(targetCacheIndex, holder);//添加进mCachedViews中
cached = true;
}
if (!cached) {
addViewHolderToRecycledViewPool(holder, true);//如果未被cached就将其添加入RecyclerPool中
recycled = true;
}
} else {
.......
}
// even if the holder is not removed, we still call this method so that it is removed
// from view holder lists.
mViewInfoStore.removeViewHolder(holder);//将该holder完全移除
if (!cached && !recycled && transientStatePreventsRecycling) {
holder.mOwnerRecyclerView = null;
}
}
首先会判断mCachedViews是否可用，如果可用会再次判断mCachedViews是否满了，如果满了的话就会将mCachedViews中index为0处的holder给移除并将其添加进入mRecyclerPool中。如果mCachedViews不可用就会直接将其添加进入mRecyclerPool中。
接下来回到getScrapOrCachedViewForId方法的第二部分：
// Search the first-level cache
final int cacheSize = mCachedViews.size();
for (int i = cacheSize - 1; i >= 0; i--) {
final ViewHolder holder = mCachedViews.get(i);
if (holder.getItemId() == id && !holder.isAttachedToTransitionOverlay()) {
if (type == holder.getItemViewType()) {
if (!dryRun) {
mCachedViews.remove(i);
}
return holder;
} else if (!dryRun) {
recycleCachedViewAt(i);
return null;
}
}
}
这里就是从第一层缓存中寻找，具体来说是从mCachedViews中寻找holder，如果找到了的话就会将其从mCachedViews中移除，如果发现viewType不匹配还会将其从mCachedViews中移入RecyclerPool中去。
tryGetViewHolderForPositionByDeadline方法的第四部分
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) {
throw new IllegalArgumentException("getViewForPositionAndType returned"
+ " a view which does not have a ViewHolder"
+ exceptionLabel());
} else if (holder.shouldIgnore()) {
throw new IllegalArgumentException("getViewForPositionAndType returned"
+ " a view that is ignored. You must call stopIgnoring before"
+ " returning this view." + exceptionLabel());
}
}
}
这第四部分会尝试从mViewCacheExtension中获取holder，这个默认是空的，指的是我们自定义的视图缓存一般反正我也不用，我们直接跳过这一段。
tryGetViewHolderForPositionByDeadline方法的第五部分
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);
}
}
}
经历了前四部分相信这里我们理解起来就很清晰了，会尝试从RecyclerPool中获取holder，如果成功从共享池中获取到一个 ViewHolder（holder != null），还会执行以下步骤：
- 重置 ViewHolder 的内部状态，以便它可以被重新使用。
- 如果
FORCE_INVALIDATE_DISPLAY_LIST为 true，还会调用invalidateDisplayListInt(holder)方法来强制刷新视图的显示列表（这通常在一些特定情况下需要，以确保视图的显示正确）。
tryGetViewHolderForPositionByDeadline方法的第五部分
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);
}
}
long end = getNanoTime();
mRecyclerPool.factorInCreateTime(type, end - start);
if (DEBUG) {
Log.d(TAG, "tryGetViewHolderForPositionByDeadline created new ViewHolder");
}
}
最后这一部分的情况就是当在所有的缓存中都没有找到可以重用的holder时就会调用我们重写的createViewHolder方法来生成一个全新的ViewHolder。
总结如何从缓存中获取ViewHolder
终于分析完了这个巨长无比的tryGetViewHolderForPositionByDeadLine方法了，现在估计还是很疑惑，现在让我们对上面这个过程进行一下总结。
最后我光看到了将viewHolder添加进入RecyclerPool而没有看到清除，所以对其源码进行了查看，发现mRecyclerPool是通过ArrayList存储viewHolder，用SparseArray存储与之相关的一些信息，通过这两个容器检查了回收池中指定类型的视图是否已满。如果池已满，就直接返回，不会将视图添加到回收池中。这是为了限制池中视图的数量，以防止占用过多内存。