RecyclerView 缓存之一的 scrap 结构中缓存的是什么？为什么需要 scrap 缓存？pre-layout 及 post-layout 过程中 scrap 缓存内容会如何变化？这一篇继续通过 走查源码 + 断点调试的方式解答这些疑问。
这是 RecyclerView 动画原理的第二篇，系列文章目录如下：
引子
这一篇源码分析还是基于下面这个 Demo 场景：
列表中有两个表项（1、2），删除 2，此时 3 会从屏幕底部平滑地移入并占据原来 2 的位置。
为了实现该效果，RecyclerView的策略是：为动画前的表项先执行一次pre-layout，将不可见的表项 3 也加载到布局中，形成一张布局快照（1、2、3）。再为动画后的表项执行一次post-layout，同样形成一张布局快照（1、3）。比对两张快照中表项 3 的位置，就知道它该如何做动画了。
在此援引上一篇已经得出的结论：
RecyclerView为了实现表项动画，进行了 2 次布局（预布局 + 后布局），在源码上表现为LayoutManager.onLayoutChildren()被调用 2 次。
- 预布局的过程始于
RecyclerView.dispatchLayoutStep1()，终于RecyclerView.dispatchLayoutStep2()。
- 在预布局阶段，循环填充表项时，若遇到被移除的表项，则会忽略它占用的空间，多余空间被用来加载额外的表项，这些表项在屏幕之外，本来不会被加载。
其中第三点表现在源码上，是这样的：
public class LinearLayoutManager { // 布局表项 public void onLayoutChildren() { // 不断填充表项 fill() { while(列表有剩余空间){ // 填充单个表项 layoutChunk(){ // 让表项成为子视图 addView(view) } if (表项没有被移除) { 剩余空间 -= 表项占用空间 } ... } } } }
这是RecyclerView填充表项的伪码。以 Demo 为例，预布局阶段，第一次执行onLayoutChildren()，因表项 2 被删除，所以它占用的空间不会被扣除，导致while循环多执行一次，这样表项 3 就被填充进列表。
后布局阶段，会再次执行onLayoutChildren()，再把表项 1、3 填入列表。那此时列表中不是得有两个表项 1，两个表项 3，和一个表项 2 吗？
这显然是不可能的，用上一篇介绍的断点调试，运行 Demo，把断点断在addView()，发现后布局阶段再次调用该方法时，RecyclerView的子控件个数为 0。
先清空表项再填充
难道每次布局之前都会删掉现有布局中所有的表项？
从fill()开始，往上走查代码，果然发现了一个线索：
public class LinearLayoutManager { public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) { ... // detach 并 scrap 表项 detachAndScrapAttachedViews(recycler); ... // 填充表项 fill() }
在填充表项之前，有一个 detach 操作：
public class RecyclerView { public abstract static class LayoutManager { public void detachAndScrapAttachedViews(@NonNull Recycler recycler) { // 遍历所有子表项 final int childCount = getChildCount(); for (int i = childCount - 1; i >= 0; i--) { final View v = getChildAt(i); // 回收子表项 scrapOrRecycleView(recycler, i, v); } } } }
果不其然，在填充表项之前会遍历所有子表项，并逐个回收它们：
public class RecyclerView { public abstract static class LayoutManager { // 回收表项 private void scrapOrRecycleView(Recycler recycler, int index, View view) { final ViewHolder viewHolder = getChildViewHolderInt(view); if (viewHolder.isInvalid() && !viewHolder.isRemoved()&& !mRecyclerView.mAdapter.hasStableIds()) { removeViewAt(index); recycler.recycleViewHolderInternal(viewHolder); } else { // detach 表项 detachViewAt(index); // scrap 表项 recycler.scrapView(view); ... } } } }
回收表项时，根据viewHolder的不同状态执行不同分支。硬看源码很难快速判断会走哪个分支，果断运行 Demo，断点调试一把。在上述场景中，所有表项都走了第二个分支，即在布局表项之前，对现有表项做了两个关键的操作：
- detach 表项
detachViewAt(index)
- scrap 表项
recycler.scrapView(view)
detach 表项
先看看 detach 表项是个什么操作：
public class RecyclerView { public abstract static class LayoutManager { ChildHelper mChildHelper; // detach 指定索引的表项 public void detachViewAt(int index) { detachViewInternal(index, getChildAt(index)); } // detach 指定索引的表项 private void detachViewInternal(int index, @NonNull View view) { ... // 将 detach 委托给 ChildHelper mChildHelper.detachViewFromParent(index); } } } // RecyclerView 子表项管理类 class ChildHelper { // 将指定位置的表项从 RecyclerView detach void detachViewFromParent(int index) { final int offset = getOffset(index); mBucket.remove(offset); // 最终实现 detach 操作的回调 mCallback.detachViewFromParent(offset); } }
LayoutManager会将 detach 任务委托给ChildHelper，ChildHelper再执行detachViewFromParent()回调，它在初始化ChildHelper时被实现：
public class RecyclerView { // 初始化 ChildHelper private void initChildrenHelper() { // 构建 ChildHelper 实例 mChildHelper = new ChildHelper(new ChildHelper.Callback() { @Override public void detachViewFromParent(int offset) { final View view = getChildAt(offset); ... // 调用 ViewGroup.detachViewFromParent() RecyclerView.this.detachViewFromParent(offset); } ... } } }
RecyclerView detach 表项的最后一步调用了ViewGroup.detachViewFromParent()：
public abstract class ViewGroup { // detach 子控件 protected void detachViewFromParent(int index) { removeFromArray(index); } // 删除子控件的最后一步 private void removeFromArray(int index) { final View[] children = mChildren; // 将子控件持有的父控件引用置空 if (!(mTransitioningViews != null && mTransitioningViews.contains(children[index]))) { children[index].mParent = null; } final int count = mChildrenCount; // 将父控件持有的子控件引用置空 if (index == count - 1) { children[--mChildrenCount] = null; } else if (index >= 0 && index < count) { System.arraycopy(children, index + 1, children, index, count - index - 1); children[--mChildrenCount] = null; } ... } }
ViewGroup.removeFromArray()是容器控件移除子控件的最后一步（ViewGroup.removeView()也会调用这个方法）。
至此可以得出结论：
在每次向
RecyclerView填充表项之前都会先清空现存表项。
目前看来，detach view和remove view差不多，它们都会将子控件从父控件的孩子列表中删除，唯一的区别是detach更轻量，不会触发重绘。而且detach是短暂的，被detach的 View 最终必须被彻底 remove 或者重新 attach。（下面就会马上把他们重新 attach）
scrap 表项
scrap 表项的意思是回收表项并将其存入mAttachedScrap列表，它是回收器Recycler中的成员变量：
public class RecyclerView { public final class Recycler { // scrap 列表 final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>(); } }
mAttachedScrap是一个 ArrayList 结构，用于存储ViewHolder实例。
RecyclerView 填充表项前，除了会 detach 所有可见表项外，还会同时 scrap 它们：
public class RecyclerView { public abstract static class LayoutManager { // 回收表项 private void scrapOrRecycleView(Recycler recycler, int index, View view) { final ViewHolder viewHolder = getChildViewHolderInt(view); ... // detach 表项 detachViewAt(index); // scrap 表项 recycler.scrapView(view); ... } } }
scrapView()是回收器Recycler的方法，正是这个方法将表项回收到了mAttachedScrap列表中：
public class RecyclerView { public final class Recycler { void scrapView(View view) { final ViewHolder holder = getChildViewHolderInt(view); // 表项不需要更新，或被移除，或者表项索引无效时，将被会收到 mAttachedScrap if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID) || !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) { holder.setScrapContainer(this, false); // 将表项回收到 mAttachedScrap 结构中 mAttachedScrap.add(holder); } else { // 只有当表项没有被移除且有效且需要更新时才会被回收到 mChangedScrap if (mChangedScrap == null) { mChangedScrap = new ArrayList<ViewHolder>(); } holder.setScrapContainer(this, true); mChangedScrap.add(holder); } } } }
scrapView()中根据ViewHolder状态将其会收到不同的结构中，同样地，硬看源码很难快速判断执行了那个分支，继续断点调试，Demo 场景中所有的表项都会被回收到mAttachedScrap结构中。（关于 mAttachedScrap 和 mChangedScrap 的区别会在后续文章分析）
分析至此，进一步细化刚才得到的结论：
在每次向
RecyclerView填充表项之前都会先清空 LayoutManager 中现存表项，将它们 detach 并同时缓存入mAttachedScrap列表中。
将结论应用在 Demo 的场景，即是：RecyclerView 在预布局阶段准备向列表中填充表项前，会清空现有的表项 1、2，把它们都 detach 并回收对应的 ViewHolder 到 mAttachedScrap列表中。
从缓存拿填充表项
预布局与 scrap 缓存的关系
缓存定是为了复用，啥时候用呢？紧接着的“填充表项”中就立马会用到：
public class LinearLayoutManager { public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) { ... // detach 表项 detachAndScrapAttachedViews(recycler); ... // 填充表项 fill() } int fill(RecyclerView.Recycler recycler, LayoutState layoutState,RecyclerView.State state, boolean stopOnFocusable) { // 计算剩余空间 int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace; // 不停的往列表中填充表项，直到没有剩余空间 while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) { // 填充单个表项 layoutChunk(recycler, state, layoutState, layoutChunkResult); ... } } // 填充单个表项 void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) { // 获取下一个被填充的视图 View view = layoutState.next(recycler); ... // 填充视图 addView(view); ... } }
填充表项时，通过layoutState.next(recycler)获取下一个该被填充的表项视图：
public class LinearLayoutManager { static class LayoutState { View next(RecyclerView.Recycler recycler) { ... // 委托 Recycler 获取下一个该填充的表项 final View view = recycler.getViewForPosition(mCurrentPosition); ... return view; } } } public class RecyclerView { public final class Recycler { public View getViewForPosition(int position) { return getViewForPosition(position, false); } } View getViewForPosition(int position, boolean dryRun) { // 调用链最终传递到 tryGetViewHolderForPositionByDeadline() return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView; } }
沿着调用链一直往下，最终走到了Recycler.tryGetViewHolderForPositionByDeadline()，在RecyclerView缓存机制（咋复用？）中对其做过详细介绍，援引结论如下：
- 在 RecyclerView 中，并不是每次绘制表项，都会重新创建 ViewHolder 对象，也不是每次都会重新绑定 ViewHolder 数据。
- RecyclerView 填充表项前，会通过
Recycler获取表项的 ViewHolder 实例。
Recycler在tryGetViewHolderForPositionByDeadline()方法中，前后尝试 5 次，从不同缓存中获取可复用的 ViewHolder 实例，其中第一优先级的缓存即是scrap结构。
- 从
scrap缓存获取的表项不需要重新构建，也不需要重新绑定数据。
从 scrap 结构获取 ViewHolder 的源码如下：
public class RecyclerView { public final class Recycler { ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) { ViewHolder holder = null; ... // 从 scrap 结构中获取指定 position 的 ViewHolder 实例 if (holder == null) { holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); ... } ... } ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) { final int scrapCount = mAttachedScrap.size(); // 遍历 mAttachedScrap 列表中所有的 ViewHolder 实例 for (int i = 0; i < scrapCount; i++) { final ViewHolder holder = mAttachedScrap.get(i); // 校验 ViewHolder 是否满足条件，若满足，则缓存命中 if (!holder.wasReturnedFromScrap() && holder.getLayoutPosition() == position && !holder.isInvalid() && (mState.mInPreLayout || !holder.isRemoved())) { holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP); return holder; } } ... } } }
从mAttachedScrap列表中获取的ViewHolder实例后，得进行校验。校验的内容很多，其中最重要的的是：ViewHolder索引值和当前填充表项的位置值是否相等，即：
scrap 结构缓存的 ViewHolder 实例，只能复用于和它回收时相同位置的表项。
也就是说，若当前列表正准备填充 Demo 中的表项 2（position == 1），即使 scrap 结构中有相同类型 ViewHolder，只要viewHolder.getLayoutPosition()的值不为 1，缓存不会命中。
分析至此，可以把上面得到的结论进一步拓展：
在每次向
RecyclerView填充表项之前都会先清空 LayoutManager 中现存表项，将它们 detach 并同时缓存入mAttachedScrap列表中。在紧接着的填充表项阶段，就立马从mAttachedScrap中取出刚被 detach 的表项并重新 attach 它们。
（弱弱地问一句，这样折腾意义何在？可能接着往下看就知道了。。）
将结论应用在 Demo 的场景，即是：RecyclerView 在预布局阶段准备向列表中填充表项前，会清空现有的表项 1、2，把它们都 detach 并回收对应的 ViewHolder 到 mAttachedScrap 列表中。然后又在填充表项阶段从 mAttachedScrap 中重新获取了表项 1、2 并填入列表。
上一篇的结论说“Demo 场景中，预布局阶段还会额外加载列表第三个位置的表项 3”，但mAttachedScrap只缓存了表项 1、2。所以在填充表项 3 时，scrap 缓存未命中。不仅如此，因表项 3 是从未被加载过的表项，遂所有的缓存都不会命中，最后只能沦落到重新构建表项并绑定数据：
public class RecyclerView { public final class Recycler { ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) { if (holder == null) { ... // 构建 ViewHolder holder = mAdapter.createViewHolder(RecyclerView.this, type); ... } // 获取表项偏移的位置 final int offsetPosition = mAdapterHelper.findPositionOffset(position); // 绑定 ViewHolder 数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); } } } }
沿着上述代码的调用链往下走查，就能找到熟悉的onCreateViewHolder()和onBindViewHolder()。
在绑定 ViewHolder 数据之前，先调用了mAdapterHelper.findPositionOffset(position)获取了“偏移位置”。断点调试告诉我，此时它会返回 1，即表项 2 被移除后，表项 3 在列表中的位置。
AdapterHelper将所有对表项的操作都抽象成UpdateOp并保存在列表中，当获取表项 3 偏移位置时，它发现有一个表项 2 的删除操作，所以表项 3 的位置会 -1。（有关 AdapterHelper 的内容就不展开了~）
至此，预布局阶段的填充表项结束了，LayoutManager 中现有表项 1、2、3，形成了第一张快照（1，2，3）。
后布局与 scrap 缓存的关系
再次援引上一篇的结论：
- RecyclerView 为了实现表项动画，进行了 2 次布局，第一次预布局，第二次后布局，在源码上表现为 LayoutManager.onLayoutChildren() 被调用 2 次。
- 预布局的过程始于 RecyclerView.dispatchLayoutStep1()，终于 RecyclerView.dispatchLayoutStep2()。
在紧接着执行的dispatchLayoutStep2()中，开始了后布局：
public class RecyclerView { void dispatchLayout() { ... dispatchLayoutStep1();// 预布局 mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2();// 后布局 ... } private void dispatchLayoutStep2() { mState.mInPreLayout = false;// 预布局结束 mLayout.onLayoutChildren(mRecycler, mState); // 第二次 onLayoutChildren() }
布局子表项的老花样要再来一遍，即先 detach 并 scrap 现有表项，然后再填充。
但这次会有一些不同：
- 因为 LayoutManager 中现有表项 1、2、3，所以 scrap 完成后，
mAttachedScrap中存有表项1、2、3 的 ViewHolder 实例（position 依次为 0、0、1，被移除表项的 position 会被置 0）。
- 因为第二次执行
onLayoutChildren()已不属于预布局阶段，所以不会加载额外的表项，即LinearLayoutManager.layoutChunk()只会执行 2 次，分别填充位置为 0 和 1 的表项。
mAttachedScrap缓存的 ViewHolder 中，有 2 个 position 为 0，1 个 position 为 1。毫无疑问，填充列表位置 1 的表项时，表项 3 必会命中（因为 position 相等）。但填充列表位置 0 的表项时，是表项 1 还是 表项 2 命中？（它们的 position 都为 0）再回看一遍，缓存命中前的校验逻辑：
public class RecyclerView { public final class Recycler { // 从 缓存中获取 ViewHolder 实例 ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) { final int scrapCount = mAttachedScrap.size(); // 遍历 mAttachedScrap 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的表项 2 时，虽然它的位置满足了要求，但校验的最后一个条件把它排除了，因为现在已经不再是预布局阶段，且表项 2 是被移除的。所以列表的位置 0 只能被剩下的表项 1 填充。
分别用表项 1、3 填充了列表的位置 0、1 ，后布局的填充表项也结束了。
此时就形成第二张快照（1，3），和预布局形成的快照（1，2，3）比对之后，就知道表项 2 需要做消失动画，而表项 3 需要做移入动画。那动画具体是怎么实现的？限于篇幅，下次再析。
总结
回到篇中的那个问题：“何必这样折腾？即先 detach 并 缓存表项到 scrap 结构中，然后紧接着又在填充表项时从中取出？”
因为 RecyclerView 要做表项动画，
为了确定动画的种类和起终点，需要比对动画前和动画后的两张“表项快照”，
为了获得两张快照，就得布局两次，分别是预布局和后布局（布局即是往列表中填充表项），
为了让两次布局互不影响，就不得不在每次布局前先清除上一次布局的内容（就好比先清除画布，重新作画），
但是两次布局中所需的某些表项大概率是一摸一样的，若在清除画布时，把表项的所有信息都一并清除，那重新作画时就会花费更多时间（重新创建 ViewHolder 并绑定数据），
RecyclerView 采取了用空间换时间的做法：在清除画布时把表项缓存在 scrap 结构中，以便在填充表项可以命中缓存，以缩短填充表项耗时。
推荐阅读
RecyclerView 系列文章目录如下:
