详解RecyclerView的预布局
概述
RecyclerView 的预布局用于 Item 动画中，也叫做预测动画。其用于当 Item 项进行变化时执行的一次布局过程（如添加或删除 Item 项），使 ItemAnimator 体验更加友好。
考虑以下 Item 项删除场景，屏幕内的 RecyclerView 列表包含两个 Item 项：item1 和 item2。当删除 item2 时，item3 从底部平滑出现在 item2 的位置。
+-------+ +-------+
| | <-----+ | | <-----+
| item1 | | | item1 | |
| | | | | |
+-------+ screen ----> +-------+ screen
| | | | | |
| item2 | | | item3 | |
| | <-----+ | | <-----+
+-------+ +-------+
上述效果是如何实现的？我们知道 RecyclerView 只会布局屏幕内可见的 Item ，对于屏幕外的 item3，如何知道其要运行的动画轨迹呢？要形成轨迹，至少需要知道起始点，而 item3 的终点位置是很明确的，也就是被删除的 item2 位置。那起点是如何确定的呢？
对于这种情况，Recyclerview 会进行两次布局，第一次被称为 pre-layout，也就是预布局，其会将不可见的 item3 也加载进布局内，得到 [item1, item2, item3] 的布局信息。之后再执行一次 post-layout，得到 [item1, item3] 的布局信息，比对两次 item3 的布局信息，也就确定了 item3 的动画轨迹了。
以下分析过程我们先定义一个大前提：LayoutManager 为 LinearLayoutManager，场景为上述描述的 item 删除场景，屏幕能够同时容纳两个 Item。
预布局
我们知道 RecyclerView 有三个重要的 layout 阶段，分别为：dispatchLayoutStep1、dispatchLayoutStep2 和 dispatchLayoutStep3。这里先直接了当的告知结论：pre-layout 发生于 dispatchLayoutStep1 阶段，而 post-layout 则发生于 dispatchLayoutStep2 阶段。
在执行 item2 的删除时，我们通过调用 Adapter#notifyItemRemoved 来通知 RecyclerView 发生了变化，其调用链如下：
RecyclerView.Adapter#notifyItemRemoved
RecyclerView.RecyclerViewDataObserver#onItemRangeRemoved
AdapterHelper#onItemRangeRemoved
RecyclerView.RecyclerViewDataObserver#triggerUpdateProcessor
RecyclerView#requestLayout
RecyclerView 中的变更操作会被封装为 UpdateOp 操作，这里删除动作被封装为一个 UpdateOp，添加到 mPendingUpdates 中等待处理。其处理时机为dispatchLayoutStep1 阶段，根据 mPendingUpdates 中的 UpdateOp 来更新列表和 ViewHolder 的信息。
// AdapterHelper#onItemRangeRemoved
boolean onItemRangeRemoved(int positionStart, int itemCount) {
if (itemCount < 1) {
return false;
}
mPendingUpdates.add(obtainUpdateOp(UpdateOp.REMOVE, positionStart, itemCount, null));
mExistingUpdateTypes |= UpdateOp.REMOVE;
return mPendingUpdates.size() == 1;
}
调用链最终会走到 RecyclerView#requestLayout 方法，进而触发 RecyclerView#onLayout 方法的调用。onLayout 做的事比较简单，直接调用 dispatchLayout 将布局事件分发下去，然后将 mFirstLayoutComplete 赋值为true，也就是只要执行过一次 dispatchLayout 那么这个值就会为 true，这个值在后续分析中会用到。
// RecyclerView#onLayout
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
TraceCompat.beginSection(TRACE_ON_LAYOUT_TAG);
dispatchLayout();
TraceCompat.endSection();
mFirstLayoutComplete = true;
}
dispatchLayout 根据状态会调用 layout 的三个重要阶段，保证 layout 三个重要阶段至少被运行一次。
// RecyclerView#dispatchLayout
void dispatchLayout() {
...
if (mState.mLayoutStep == State.STEP_START) {
dispatchLayoutStep1();
mLayout.setExactMeasureSpecsFrom(this);
dispatchLayoutStep2();
} else if (mAdapterHelper.hasUpdates()
|| needsRemeasureDueToExactSkip
|| mLayout.getWidth() != getWidth()
|| mLayout.getHeight() != getHeight()) {
mLayout.setExactMeasureSpecsFrom(this);
dispatchLayoutStep2();
} else {
// always make sure we sync them (to ensure mode is exact)
mLayout.setExactMeasureSpecsFrom(this);
}
dispatchLayoutStep3();
}
dispatchLayoutStep1 中根据 mRunPredictiveAnimations 的值来决定是否处于 pre-layout 中，而 mInPreLayout 和 mRunPredictiveAnimations 初始值都是false，因此我们需要找到 mRunPredictiveAnimations 被赋值的地方。
// RecyclerView#dispatchLayoutStep1
private void dispatchLayoutStep1() {
...
mState.mInPreLayout = mState.mRunPredictiveAnimations;
...
}
// RecyclerView#State
public static class State {
boolean mInPreLayout = false;
boolean mRunPredictiveAnimations = false;
}
mRunPredictiveAnimations 由多个变量共同决定，从代码中我们知道只有 mFirstLayoutComplete 为 true 之后才有可能开始运行 ItemAnimator 和预测动画（决定了是否执行 pre-layout），而 mFirstLayoutComplete 只有完成一次 onLayout 才会被赋值为 true，因此可以得知另一个信息：RecyclerView 不支持初始动画。
这里不去一一分析每一个变量的赋值时机，从调试可知这里 mRunSimpleAnimations 和 mRunPredictiveAnimations 会被赋值为true（或者从现象反推，表项删除是带有动画的，因此这里也必须为 true 才能支持表项删除的 ItemAnimator）。
// RecyclerView#processAdapterUpdatesAndSetAnimationFlags
private void processAdapterUpdatesAndSetAnimationFlags() {
...
boolean animationTypeSupported = mItemsAddedOrRemoved || mItemsChanged;
mState.mRunSimpleAnimations = mFirstLayoutComplete
&& mItemAnimator != null
&& (mDataSetHasChangedAfterLayout
|| animationTypeSupported
|| mLayout.mRequestedSimpleAnimations)
&& (!mDataSetHasChangedAfterLayout
|| mAdapter.hasStableIds());
mState.mRunPredictiveAnimations = mState.mRunSimpleAnimations
&& animationTypeSupported
&& !mDataSetHasChangedAfterLayout
&& predictiveItemAnimationsEnabled();
}
继续查看 dispatchLayoutStep1 的其他代码，当可以执行预测动画时，会调用 LayoutManager 的 onLayoutChildren 方法。
private void dispatchLayoutStep1() {
...
processAdapterUpdatesAndSetAnimationFlags();
if (mState.mRunPredictiveAnimations) {
...
mLayout.onLayoutChildren(mRecycler, mState);
}
...
mState.mLayoutStep = State.STEP_LAYOUT;
}
查看 onLayoutChildren 代码，其注释信息如下：
布局 Adapter 的所有相关子视图。LayoutManager 负责 Item 动画的行为。默认情况下，RecyclerView 有一个非空的 ItemAnimator，并且启用简单的 item 动画。这意味着 Adapter 上的添加/删除操作会伴随有相关动画出现。如果 LayoutManager 的
supportsPredictiveItemAnimations()（默认值）返回 false，并在onLayoutChildren(RecyclerView.Recycler, RecyclerView.State)运行正常的布局操作， RecyclerView 也有足够的信息以简单的方式运行这些动画。
当 LayoutManager 想要拥有用户体验更加友好的 ItemAnimator，那么 LayoutManager 应该让supportsPredictiveItemAnimations()返回 true 并向onLayoutChildren( RecyclerView.Recycler、RecyclerView.State）添加额外逻辑。支持预测动画意味着onLayoutChildren(RecyclerView.Recycler, RecyclerView.State)将被调用两次； 一次作为“预”布局来确定 Item 在实际布局之前的位置，并再次进行“实际”布局。在预布局阶段，Item 将记住它们的预布局位置，以便能够被布局正确。 此外，移除的项目将从 scrap 列表中返回，以帮助确定其他项目的正确放置。 这些删除的项目不应添加到子列表中，而应用于帮助计算其他视图的正确位置，包括以前不在屏幕上的视图（称为 APPEARING view），但可以确定其预布局屏幕外位置 给出有关预布局删除视图的额外信息。
第二次布局是真正的布局，其中仅使用未删除的视图。 此过程中唯一的附加要求是，如果supportsPredictiveItemAnimations()返回 true，请注意哪些视图在布局之前存在于子列表中，哪些视图在布局之后不存在（称为 DISAPPEARING view），并定位/布局这些视图，而不考虑 RecyclerView 的实际边界。这使得动画系统能够知道将这些消失的视图动画化到的位置。
RecyclerView 的默认 LayoutManager 实现已经处理了所有这些动画要求。 RecyclerView 的客户端可以直接使用这些布局管理器之一，也可以查看它们的onLayoutChildren()实现，以了解它们如何解释 APPEARING 和 DISAPPEARING 视图。
简单总结为：为了在 Item 项变更时能够获得更好的动画体验，onLayoutChildren 会被调用两次，一次用于 pre-layout（预布局），一次用于 post-layout（实际布局）。查看代码调用时机，onLayoutchildren 一次在 dispatchLayoutStep1 调用，一次在 dispatchLayoutStep2 调用。
onLayoutChildren 中会调用 fill 函数进行布局填充。能否继续填充由 layoutState.mInfinite 或 remainingSpace 和 layoutState.hasMore(state) 共同决定。
layoutState.mInfinite 表示无限填充，不适用于我们分析的case，因此关键在于 remainingSpace 值的变更。在 pre-layout 中会多布局一次，也就是说相比较于 post-layout，remainingSpace 在 pre-layout 少消费了一次。
remainingSpace 的变更受三个变量控制，由于处在 pre-layout 阶段，因此 state.isPreLayout 为 true，layoutState.mScrapList 此处还未被赋值，因此关注 layoutChunkResult.mIgnoreConsumed 变量。
// LinearLayoutManager#onLayoutChildren
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
...
fill(recycler, mLayoutState, state, false);
...
}
// LinearLayoutManager#fill
int fill(RecyclerView.Recycler recycler, LayoutState layoutState,
RecyclerView.State state, boolean stopOnFocusable) {
...
int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace;
LayoutChunkResult layoutChunkResult = mLayoutChunkResult;
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
layoutChunkResult.resetInternal();
layoutChunk(recycler, state, layoutState, layoutChunkResult);
if (layoutChunkResult.mFinished) {
break;
}
layoutState.mOffset += layoutChunkResult.mConsumed * layoutState.mLayoutDirection;
if (!layoutChunkResult.mIgnoreConsumed || layoutState.mScrapList != null
|| !state.isPreLayout()) {
layoutState.mAvailable -= layoutChunkResult.mConsumed;
// we keep a separate remaining space because mAvailable is important for recycling
remainingSpace -= layoutChunkResult.mConsumed;
}
...
}
return start - layoutState.mAvailable;
}
layoutChunkResult 在 fill 过程被当作参数传入 layoutChunk ，因此我们需要关注下是否是这里导致了 layoutChunkResult 的成员变量改变了。
查看 layoutChunk 源码，当 Item 项被标记为 Remove 时，会将 mIgnoreConsumed 变量置为 true，因此在 fill 过程会忽略被删除的 Item 项的布局占用。
// LinearLayoutManager#layoutChunkResult
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,
LayoutState layoutState, LayoutChunkResult result) {
...
if (params.isItemRemoved() || params.isItemChanged()) {
result.mIgnoreConsumed = true;
}
}
// RecyclerView#LayoutParams
public boolean isItemRemoved() {
return mViewHolder.isRemoved();
}
// RecyclerView#ViewHolder
boolean isRemoved() {
return (mFlags & FLAG_REMOVED) != 0;
}
ViewHolder 信息更新
我们通过 notifyItemRemoved 来通知 RecyclerView Item 项被删除，那么在什么时候 ViewHolder 被标记为删除状态呢？
在 预布局 一节中我们知道调用最终走到 requestLayout 中，进入触发 onLayout 方法。在布局过程中，关于 ViewHolder 信息更新的调用链路如下：
RecyclerView#dispatchLayoutStep1
RecyclerView#processAdapterUpdatesAndSetAnimationFlags
AdapterHelper#preProcess
AdapterHelper#applyRemove
AdapterHelper#postponeAndUpdateViewHolders
AdapterHelper#Callback#offsetPositionsForRemovingLaidOutOrNewView
RecyclerView#offsetPositionRecordsForRemove
ViewHolder#offsetPosition
ViewHolder#flagRemovedAndOffsetPosition
postponeAndUpdateViewHolders 会调用 Adapterhelper#Callback 接口的方法，这个接口在 AdapterHelper 实例化的时候进行实现。最终会走到 offsetPositionRecordsForRemove 方法，这里会对 ViewHolder 相关的 position 和 flag 变量进行修改。
AdapterHelper#Callback 接口实现的地方：
// RecyclerView#initAdapterManager
void initAdapterManager() {
mAdapterHelper = new AdapterHelper(new AdapterHelper.Callback() {
...
}
}
回看 dispatchLayoutStep1 阶段的 processAdapterUpdatesAndSetAnimationFlags 调用，在执行 pre-layout 时会调用 mAdapterHelper.preProcess()。
// RecyclerView#processAdapterUpdatesAndSetAnimationFlags
private void processAdapterUpdatesAndSetAnimationFlags() {
...
if (predictiveItemAnimationsEnabled()) {
mAdapterHelper.preProcess();
} else {
mAdapterHelper.consumeUpdatesInOnePass();
}
...
}
preProcess 根据 mPendingUpdates 中存储的 UpdateOp 来决定执行相关动作。这与我们上述讲到的 RecyclerView 中的变更操作会被封装为 UpdateOp 操作，添加到 mPendingUpdates 中等待处理 相呼应，这里就是对应的处理逻辑。（额外说一下 AdapterHelper 就是用来存储和处理 UpdateOp 的相关工具类，根据保存的 UpdateOp 列表，计算 position 等信息）
// AdapterHelper#preProcess
void preProcess() {
mOpReorderer.reorderOps(mPendingUpdates);
final int count = mPendingUpdates.size();
for (int i = 0; i < count; i++) {
UpdateOp op = mPendingUpdates.get(i);
switch (op.cmd) {
...
case UpdateOp.REMOVE:
applyRemove(op);
break;
...
}
if (mOnItemProcessedCallback != null) {
mOnItemProcessedCallback.run();
}
}
mPendingUpdates.clear();
}
根据上述的调用链关系，由于中间的调用过程都是一些比较简单的逻辑中转，我们直接查看 RecyclerView#offsetPositionRecordsForRemove 代码的相关逻辑。
由于有 Item 项被删除了，那么它后面的 Item 项的位置信息就需要被更新。这里分两个分支逻辑进行处理：
- 被删除的 Item 项调用
flagRemovedAndOffsetPosition - 被删除的 Item 项之后的 Item 项调用
offsetPosition
void offsetPositionRecordsForRemove(int positionStart, int itemCount,
boolean applyToPreLayout) {
final int positionEnd = positionStart + itemCount;
final int childCount = mChildHelper.getUnfilteredChildCount();
for (int i = 0; i < childCount; i++) {
final ViewHolder holder = getChildViewHolderInt(mChildHelper.getUnfilteredChildAt(i));
if (holder != null && !holder.shouldIgnore()) {
if (holder.mPosition >= positionEnd) {
holder.offsetPosition(-itemCount, applyToPreLayout);
mState.mStructureChanged = true;
} else if (holder.mPosition >= positionStart) {
holder.flagRemovedAndOffsetPosition(positionStart - 1, -itemCount,
applyToPreLayout);
mState.mStructureChanged = true;
}
}
}
mRecycler.offsetPositionRecordsForRemove(positionStart, itemCount, applyToPreLayout);
requestLayout();
}
flagRemovedAndOffsetPosition 中将 ViewHolder 的标志位添加上了 FLAG_REMOVED 的删除标志。
// ViewHolder#flagRemovedAndOffsetPosition
void flagRemovedAndOffsetPosition(int mNewPosition, int offset, boolean applyToPreLayout) {
addFlags(ViewHolder.FLAG_REMOVED);
offsetPosition(offset, applyToPreLayout);
mPosition = mNewPosition;
}
此外对于 ViewHolder 的 position 相关信息也会被更新。
void offsetPosition(int offset, boolean applyToPreLayout) {
if (mOldPosition == NO_POSITION) {
mOldPosition = mPosition;
}
if (mPreLayoutPosition == NO_POSITION) {
mPreLayoutPosition = mPosition;
}
if (applyToPreLayout) {
mPreLayoutPosition += offset;
}
mPosition += offset;
if (itemView.getLayoutParams() != null) {
((LayoutParams) itemView.getLayoutParams()).mInsetsDirty = true;
}
}
预布局和后布局的差异
根据上述的分析我们知道，onLayoutChildren 会被调用两次，一次用于 pre-layout，一次用于 post-layout。那么他们的区别在哪，为何会造成 pre-layout 的布局快照为 [item1, item2, item3]， 而 post-layout 的布局快照为 [item1, item3] 呢？
回看 onLayoutChildren 源码，在进行 fill 填充时，会先调用 detachAndScrapAttachedViews 将屏幕内的 Item 项先进行 detach 放置到 mAttachedScrap 中保存。此时 mAttachedScrap 中保存着 item1 和 item2。
// LinearLayoutManager#onLayoutChildren
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
...
detachAndScrapAttachedViews(recycler);
...
fill(recycler, mLayoutState, state, false);
...
}
detachAndScrapAttachedViews 遍历列表中的子 View，将他们都暂时 detach 掉。
// RecyclerView#detachAndScrapAttachedViews
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);
}
}
// RecyclerView#scrapOrRecycleView
private void scrapOrRecycleView(Recycler recycler, int index, View view) {
final ViewHolder viewHolder = getChildViewHolderInt(view);
if (viewHolder.shouldIgnore()) {
if (DEBUG) {
Log.d(TAG, "ignoring view " + viewHolder);
}
return;
}
if (viewHolder.isInvalid() && !viewHolder.isRemoved()
&& !mRecyclerView.mAdapter.hasStableIds()) {
removeViewAt(index);
recycler.recycleViewHolderInternal(viewHolder);
} else {
detachViewAt(index);
recycler.scrapView(view);
mRecyclerView.mViewInfoStore.onViewDetached(viewHolder);
}
}
在上述分析中，我们知道删除一个 Item 项，其会被添加上 FLAG_REMOVED 的标记位，因此对于 scrapView 的逻辑，其会走入第一个分支逻辑，将 Viewholder 加入到 mAttachedScap 中。
// RecyclerView#Recycler#scrapView
void scrapView(View view) {
final ViewHolder holder = getChildViewHolderInt(view);
if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID)
|| !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) {
if (holder.isInvalid() && !holder.isRemoved() && !mAdapter.hasStableIds()) {
throw new IllegalArgumentException("Called scrap view with an invalid view."
+ " Invalid views cannot be reused from scrap, they should rebound from"
+ " recycler pool." + exceptionLabel());
}
holder.setScrapContainer(this, false);
mAttachedScrap.add(holder);
} else {
if (mChangedScrap == null) {
mChangedScrap = new ArrayList<ViewHolder>();
}
holder.setScrapContainer(this, true);
mChangedScrap.add(holder);
}
}
回到 fill 源码，fill 的核心填充逻辑调用的 layoutChunk。layoutChunk 将获取填充的 View 委托给了 layoutState.next 方法。
// LinearLayoutManager#layoutChunk
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,
LayoutState layoutState, LayoutChunkResult result) {
View view = layoutState.next(recycler);
...
}
LayoutState#next 内部执行逻辑即为 RecyclerView 缓存复用的核心流程。调用链如下：
LayoutState#next
LinearLayoutManager#Recycler#getViewForPosition
LinearLayoutManager#Recycler#tryGetViewHolderForPositionByDeadline
RecyclerView#Recycler#getChangedScrapViewForPosition
RecyclerView#Recycler#getScrapOrHiddenOrCachedHolderForPosition
RecyclerView#RecycledViewPool#getRecycledView
RecyclerView#Adapter#createViewHolder
我们重点关注 getScrapOrHiddenOrCachedHolderForPosition， 因为它包含了从 mAttachedScap 列表获取 ViewHolder 的相关逻辑，而 mAttachedScap 我们上述讲过，onLayoutChildren 过程 detach 的 ViewHolder 会存放在这里。
// RecyclerView#Recycler#getScrapOrHiddenOrCachedHolderForPosition
ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) {
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;
}
}
...
return null;
}
对于是否能够复用 mAttachedScap 中的 ViewHolder 取决于多个变量的共同作用。
holder.wasReturnedFromScrap()： 由于 ViewHolder 刚被加入到mAttachedScap中，因此其还没有被标记上FLAG_RETURNED_FROM_SCRAP标志。另外，当能够复用时，被标记了FLAG_RETURNED_FROM_SCRAP标志，其也会在RecyclerView#LayoutManager#addViewInt中被清除掉。holder.isInvalid()：Item 项在删除过程没有被标记上FLAG_INVALID标志。mState.mInPreLayout || !holder.isRemoved()是否处于预布局或不被删除
这里重点讲一下 holder.getLayoutPosition() == position
// RecyclerView#ViewHolder#getLayoutPosition
public final int getLayoutPosition() {
return mPreLayoutPosition == NO_POSITION ? mPosition : mPreLayoutPosition;
}
只有当位置不变时，才能被复用。因为从 mAttachedScap 中复用的 ViewHolder 不会再进行 bind 操作。
对于 getLayoutPosition 的取值由 mPreLayoutPosition 和 mPosition 共同作用。这两个变量的取值，其可能会在多处被修改。在初始调用 notifyItemRangeRemoved 通知 RecyclerView 的 Item 项被删除时，在 offsetPositionRecordsForRemove 中 mPosition 会被修正为 Item 已经被删除的正确位置，这个我们在 ViewHolder 信息更新 一节中有过阐述。
item3 由于不存在于 mAttachedScap 和各级缓存中，因此需要被创建。同时在 tryGetViewHolderForPositionByDeadline 中会将 mPosition 和 mPreLayoutPosition 进行正确赋值。
isBound 表示 ViewHolder 是否完成布局，对于刚通过 createViewHolder 创建的 ViewHolder 其为 false， 因此会走入第二个分支逻辑，进行数据绑定以及 position 数据的更新。
注意 offsetPosition 的相关计算，其调用 mAdapterHelper.findPositionOffset(position) 得到。作用与上述讲到的 offsetPositionRecordsForRemove 作用类似。AdapterHelper 会根据 UpdateOp 来为 ViewHolder 提供正确的 position 信息。
// RecyclerView#ViewHolder#tryGetViewHolderForPositionByDeadline
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
...
if (holder == null) {
...
holder = mAdapter.createViewHolder(RecyclerView.this, type);
}
...
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);
}
...
}
此时 pre-layout 的中 ViewHolder 的 position 信息如下：
| mPosition | mPreLayoutPosition | |
|---|---|---|
| item1 | 0 | 0 |
| item2 | 0 | 1 |
| item3 | 1 | 2 |
其得到的布局快照为 [item1, item2, item3]
在 dispatchLayoutStep1 源码中，在函数体结尾处会调用 clearOldPositions 将 mPreLayoutPosition 重置。因此在 dispatchLayoutStep2 中进行 post-layout 过程中调用 getLayoutPosition 的值由 mPosition 决定。
// RecyclerView#dispatchLayoutStep1
private void dispatchLayoutStep1() {
...
if (mState.mRunPredictiveAnimations) {
mLayout.onLayoutChildren(mRecycler, mState);
...
clearOldPositions();
}
...
}
// RecyclerView#clearOldPositions
void clearOldPositions() {
final int childCount = mChildHelper.getUnfilteredChildCount();
for (int i = 0; i < childCount; i++) {
final ViewHolder holder = getChildViewHolderInt(mChildHelper.getUnfilteredChildAt(i));
if (!holder.shouldIgnore()) {
holder.clearOldPosition();
}
}
mRecycler.clearOldPositions();
}
// RecyclerView#ViewHolder#clearOldPosition
void clearOldPosition() {
mOldPosition = NO_POSITION;
mPreLayoutPosition = NO_POSITION;
}
此时 post-layout 中 ViewHolder 的 position 信息如下：
| mPosition | mPreLayoutPosition | |
|---|---|---|
| item1 | 0 | -1 |
| item2 | 0 | -1 |
| item3 | 1 | -1 |
因此 getScrapOrHiddenOrCachedHolderForPosition 只有 item1 和 item3 能够命中 mAttachedScap 的 ViewHolder，形成 [item1, item3] 的布局快照。
以上分析有很多细节点可能没有很详尽地阐述，因为 RecyclerView 当中应用的概念过于复杂。如果发散开来，形成的篇幅很大，且不易把握主题。
对于 预布局和后布局的差异 这一节中，整体脉络涉及到 Item布局、 ViewHolder 缓存复用以及增删变更带来的 Position 等信息的变化，内容多信息量大，不易快速掌握。建议写一个精简 demo，跟随文章中阐述的调用链实际调试走一把，感受各个变量值变更的过程，加快理解。
┆ 凉 ┆ 暖 ┆ 降 ┆ 等 ┆ 幸 ┆ 我 ┆ 我 ┆ 里 ┆ 将 ┆ ┆ 可 ┆ 有 ┆ 谦 ┆ 戮 ┆ 那 ┆ ┆ 大 ┆ ┆ 始 ┆ 然 ┆
┆ 薄 ┆ 一 ┆ 临 ┆ 你 ┆ 的 ┆ 还 ┆ 没 ┆ ┆ 来 ┆ ┆ 是 ┆ 来 ┆ 逊 ┆ 没 ┆ 些 ┆ ┆ 雁 ┆ ┆ 终 ┆ 而 ┆
┆ ┆ 暖 ┆ ┆ 如 ┆ 地 ┆ 站 ┆ 有 ┆ ┆ 也 ┆ ┆ 我 ┆ ┆ 的 ┆ 有 ┆ 精 ┆ ┆ 也 ┆ ┆ 没 ┆ 你 ┆
┆ ┆ 这 ┆ ┆ 试 ┆ 方 ┆ 在 ┆ 逃 ┆ ┆ 会 ┆ ┆ 在 ┆ ┆ 清 ┆ 来 ┆ 准 ┆ ┆ 没 ┆ ┆ 有 ┆ 没 ┆
┆ ┆ 生 ┆ ┆ 探 ┆ ┆ 最 ┆ 避 ┆ ┆ 在 ┆ ┆ 这 ┆ ┆ 晨 ┆ ┆ 的 ┆ ┆ 有 ┆ ┆ 来 ┆ 有 ┆
┆ ┆ 之 ┆ ┆ 般 ┆ ┆ 不 ┆ ┆ ┆ 这 ┆ ┆ 里 ┆ ┆ 没 ┆ ┆ 杀 ┆ ┆ 来 ┆ ┆ ┆ 来 ┆
