RecyclerView 表项动画是怎么实现的？RecyclerView 在做表项动画时会布局几次？pre-layout 是什么意思？我带着这么多疑问在茫茫源码中苦苦搜寻，本想直接给出答案，却发现过程也很值得回味，且听我慢慢道来。
这是 RecyclerView 动画原理的第一篇，系列文章目录如下：
引子
最初听到pre-layout这个概念是从一道面试题：RecyclerView 为什么要预布局？
下面这个场景就要用到预布局：
列表中有两个表项（1、2），删除 2，此时 3 会从屏幕底部平滑地移入并占据原来 2 的位置。
这是怎么做到的？RecyclerView如何知道表项 3 的动画轨迹？虽然动画的终点已经有了（表项 2 的顶部），那起点呢？LayoutManager只加载所有可见表项，在删除表项 2 之前，表项 3 处于不可见状态，它并不会被 layout。
对于这种情况RecyclerView的策略是“执行两次 layout”：为动画前的表项先执行一次pre-layout，将不可见的表项 3 也加载到布局中，形成一张布局快照（1、2、3）。再为动画后的表项执行一次post-layout，同样形成一张布局快照（1、3）。比对两张快照中表项 3 的位置，就知道它该如何做动画了。
具体是怎么实现的？去源码里搜搜答案~
预布局生命周期
一开始，也不知道该从哪看起。但既然是预布局，肯定和布局有关系，就从RecyclerView.onLayout()开始把：
看原码就是这样，有时候它更像是漫无目的的逛街，而不是明确指向的淘宝搜索。
public class RecyclerView {
@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;
}
}
RecyclerView.onLayout()很短，一眼就可以找到其中的关键dispatchLayout()：
public class RecyclerView {
void dispatchLayout() {
mState.mIsMeasuring = false;
if (mState.mLayoutStep == State.STEP_START) {
// 分发布局1
dispatchLayoutStep1();
mLayout.setExactMeasureSpecsFrom(this);
// 分发布局2
dispatchLayoutStep2();
} else if (mAdapterHelper.hasUpdates() || mLayout.getWidth() != getWidth()
|| mLayout.getHeight() != getHeight()) {
mLayout.setExactMeasureSpecsFrom(this);
dispatchLayoutStep2();
} else {
mLayout.setExactMeasureSpecsFrom(this);
}
// 分发布局3
dispatchLayoutStep3();
}
}
布局分了三个步骤，从第一步骤开始看：
public class RecyclerView {
private void dispatchLayoutStep1() {
...
mState.mInPreLayout = mState.mRunPredictiveAnimations;
...
}
public static class State {
boolean mInPreLayout = false;
...
}
}
在分发布局第一步中发现了一个布尔变量mInPreLayout，字面意思是“是否在 pre-layout 过程中”。
找到一点和pre-layout沾边的信息，映入脑壳的问题是 “ mInPreLayout 什么时候被置为 true，什么时候又被置为 false？”，回答这个问题就能知道pre-layout的生命周期了。
全局搜索mInPreLayout被赋值的地方，除了mState.mInPreLayout = mState.mRunPredictiveAnimations;其余都被置为 false。想必mState.mRunPredictiveAnimations一定为 true！怎么验证？看看它在哪里被赋值：
public class RecyclerView {
private void processAdapterUpdatesAndSetAnimationFlags() {
...
mState.mRunSimpleAnimations = mFirstLayoutComplete
&& mItemAnimator != null
&& (mDataSetHasChangedAfterLayout
|| animationTypeSupported
|| mLayout.mRequestedSimpleAnimations)
&& (!mDataSetHasChangedAfterLayout
|| mAdapter.hasStableIds());
mState.mRunPredictiveAnimations = mState.mRunSimpleAnimations
&& animationTypeSupported
&& !mDataSetHasChangedAfterLayout
&& predictiveItemAnimationsEnabled();
}
}
mRunPredictiveAnimations的值由另外 N 个布尔变量共同决定，难道我得挨个搜索其他变量才能确定它的值吗？（其实有一个更简单的方法可以验证，下面会提到）
就此打住，mRunPredictiveAnimations的值一定为 true，否则mInPreLayout就永远为 false 了。
看原码就是这样，源码无涯，回头是岸，点到为止就好。
继续走查dispatchLayoutStep1()剩余的代码：
public class RecyclerView {
private void dispatchLayoutStep1() {
...
mState.mInPreLayout = mState.mRunPredictiveAnimations;
...
if (mState.mRunPredictiveAnimations) {
...
mLayout.onLayoutChildren(mRecycler, mState);
...
}
...
}
}
发现了一个很关键的方法LayoutManager.onLayoutChildren()，它有很长的注释，大意是“该方法用于布局 Adapter 中所有的表项。若支持表项动画，则 onLayoutChildren() 会被调用 2 次，第一次称为 pre-layout，它是真正布局表项之前的一次预布局。”
搜索LayoutManager.onLayoutChildren()被调用的地方，只有两处，一次在RecyclerView.dispatchLayoutStep1()中，另一次在RecyclerView.dispatchLayoutStep2()：
public class RecyclerView {
private void dispatchLayoutStep2() {
...
mState.mInPreLayout = false;// pre-layout 结束
mLayout.onLayoutChildren(mRecycler, mState); // 开始正真的布局
...
}
}
布局的第二步中，调用onLayoutChildren()前，把mInPreLayout置为了 false，pre-layout就此结束。
而且mState作为参数被传入onLayoutChildren()，在onLayoutChildren()中一定会读取mInPreLayout。
看到这里，结合注释和代码走查，可以下一些结论：
RecyclerView为了实现表项动画，进行了 2 次布局，第一次预布局，第二次正真的布局，在源码上表现为LayoutManager.onLayoutChildren()被调用 2 次
mState.mInPreLayout的值标记了预布局的生命周期。预布局的过程始于RecyclerView.dispatchLayoutStep1()，终于RecyclerView.dispatchLayoutStep2()。两次调用LayoutManager.onLayoutChildren()会因为这个标记位的不同而执行不同的逻辑分支。
预布局填充额外表项
知道了预布局的起点和终点，就为走查代码缩小了范围。只需要定位在LinearLayoutManager.onLayoutChildren()中，就可以了解预布局做了些什么。
预布局一定做了很多事情，但现在最关心的是“预布局过程中，如何将额外的不可见表项填充进来？”
在RecyclerView缓存机制（咋复用？）中讲述了怎么在源码中一步步找到 “填充表项” 的逻辑，这段逻辑正好就在onLayoutChildren()中，引用如下：
public class LinearLayoutManager {
// 布局表项
public void onLayoutChildren() {
// 填充表项
fill() {
while(列表有剩余空间){
// 填充单个表项
layoutChunk(){
// 让表项成为子视图
addView(view)
}
}
}
}
}
RecyclerView将布局表项的任务委托给LinearLayoutManager。LinearLayoutManager布局表项时，在fill()方法中循环不断地调用layoutChunk()逐个将表项填入，直到列表没有空间。
对于填充表项，fill()和layoutChunk()是两个关键方法，添加额外表项的逻辑肯定藏在其中：
public class LinearLayoutManager {
// 根据剩余空间填充表项
int fill(RecyclerView.Recycler recycler, LayoutState layoutState,RecyclerView.State state, boolean stopOnFocusable) {
...
// 计算剩余空间 = 可用空间 + 额外空间
int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace;
// 当剩余空间 > 0 时，继续填充更多表项
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
...
layoutChunk()
...
}
}
}
LinearLayoutManager在循环填充表项前会计算剩余空间，计算公式中的mExtraFillSpace引起了我的注意，它和我关心的问题“额外表项”很匹配，心想 “在 pre-layout 过程中可能是mExtraFillSpace增大，放宽了循环条件，使得额外表项被填充。” 于是乎，我开始搜索它被赋值的地方，结果显示有 11 处（有点多，好慌）：
仔细一瞅，大部分的赋值都发生在onLayoutChildren()中：
if (mAnchorInfo.mLayoutFromEnd) {// 从尾部开始布局
mLayoutState.mExtraFillSpace = extraForStart;
} else {// 从头部开始布局
mLayoutState.mExtraFillSpace = extraForEnd;
}
而且它们分别处于不同的方向分支中，即对于一种方向的列表只有一个赋值语句被执行，随便找了一个mLayoutState.mExtraFillSpace = extraForEnd;，继续搜索extraForEnd被赋值的地方：
看源码就是这样，道路千万条，抽丝剥茧选一条。
public class LinearLayoutManager {
private int[] mReusableIntPair = new int[2];
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
...
mReusableIntPair[0] = 0;
mReusableIntPair[1] = 0;
calculateExtraLayoutSpace(state, mReusableIntPair); // 计算值
int extraForEnd = Math.max(0, mReusableIntPair[1]) // 赋值
}
}
extraForEnd的值和mReusableIntPair[1]有关，而它在calculateExtraLayoutSpace()中被计算，继续跳转：
看源码就是这样，想知道一个变量的值，可能得先知道其他 N 个变量的值。
public class LinearLayoutManager {
// 计算额外空间
protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state,@NonNull int[] extraLayoutSpace) {
int extraLayoutSpaceStart = 0;
int extraLayoutSpaceEnd = 0;
int extraScrollSpace = getExtraLayoutSpace(state);// 计算值
if (mLayoutState.mLayoutDirection == LayoutState.LAYOUT_START) {
extraLayoutSpaceStart = extraScrollSpace;
} else {
extraLayoutSpaceEnd = extraScrollSpace;
}
extraLayoutSpace[0] = extraLayoutSpaceStart;
extraLayoutSpace[1] = extraLayoutSpaceEnd;// 赋值
}
}
calculateExtraLayoutSpace()这个方法名让我更加坚信这条路没错（额外表项对应着额外空间）。
在这个方法中又调用了getExtraLayoutSpace()并将结果赋值给extraLayoutSpace[1]，继续跳：
看源码就是这样，不停地跳来跳去，有时候跳远了都忘了为啥而跳。
public class LinearLayoutManager {
protected int getExtraLayoutSpace(RecyclerView.State state) {
if (state.hasTargetScrollPosition()) {
return mOrientationHelper.getTotalSpace();
} else {
return 0;
}
}
}
方法要么返回 0 要么返回mOrientationHelper.getTotalSpace()，我更愿意相信后者，因为只有返回非0值才能证实猜想。为了验证，我还得跳一次：
public class RecyclerView {
public static class State {
public boolean hasTargetScrollPosition() {
return mTargetPosition != RecyclerView.NO_POSITION;
}
}
}
看到这，我陷入了迷茫，因为删除表项操作并不会发生列表滚动，即hasTargetScrollPosition()应该返回 false，也就说返回额外空间的方法getExtraLayoutSpace()应该返回0。我无法接受这个事实。。。
看源码就是这样，千辛万苦在一条道上走了很久，到头来却发现是个死胡同。
难道列表发生滚动了？
怎么证明滚动了？
继续搜索 mTargetPosition 被赋值的地方？
不。。。我已经跳不动了。。
硬生生地看了一下午源码，也没有看到想要的结果，更致命的是硬看很容易钻牛角尖，有限的生命就耗费在这无穷的细节中。
想知道某个变量的值，最快的办法是断点调试，它也可以用到阅读源码上。写了一个简单的 Demo 模拟删除表项的场景，将断点打在计算剩余空间那一行：
public class LinearLayoutManager {
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()
...
}
}
}
断点告诉我layoutState.mExtraFillSpace的确为0！
那layoutState.mAvailable的值是否在pre-layout过程中变大？断点告诉我没有！
循环条件没有放宽！那额外的表项是如何被填充的？
我将断点打在了循环条件while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) 上，惊喜地发现了一个新的线索：在正常布局表项时，当第二个表项被填充后remainingSpace就等于0了，但同样的情况在 pre-layout 阶段，remainingSpace就不为0，这导致循环可以多走一次，即可以将表项 3 填充进来。
每次循环填充表项后remainingSpace的值应该变小，难道填充被删除的表项时跳过了这个步骤？
又到了硬看源码发挥作用的时刻：
public class LinearLayoutManager {
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();
// 填充单个表项（将layoutChunkResult传入）
layoutChunk(recycler, state, layoutState, layoutChunkResult);
...
if (!layoutChunkResult.mIgnoreConsumed || layoutState.mScrapList != null|| !state.isPreLayout()) {
// 在剩余空间中扣除刚填充表项消耗的空间
remainingSpace -= layoutChunkResult.mConsumed;
}
}
}
}
循环中唯一一处扣除剩余空间的代码被一个条件表达式包裹着，表达式中有三个条件做或运算，其中一个条件!state.isPreLayout()对于非pre-layout阶段来说肯定为 true，即无论其他条件如何，非pre-layout阶段一定会扣除所有表项消耗的空间，而对于pre-layout来说，填充某些表项时，可能会跳过扣除。哪些表项会跳过？
条件表达式中有一个变量 layoutChunkResult.mIgnoreConsumed，字面意思是忽略这次消耗，而且layoutChunkResult被作为参数传入layoutChunk()：
public class LinearLayoutManager {
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) {
// 获取下一个该被填充的表项视图
View view = layoutState.next(recycler);
...
// 获取表项布局参数
RecyclerView.LayoutParams params = (RecyclerView.LayoutParams) view.getLayoutParams();
// 如果表项被移除 则 mIgnoreConsumed 置为 true
if (params.isItemRemoved() || params.isItemChanged()) {
result.mIgnoreConsumed = true;
}
...
}
}
看到这里感觉八九不离十了，用断点调试验证了，的确和猜想的一样：
在预布局阶段，循环填充表项时，若遇到被移除的表项，则会忽略它占用的空间，多余空间被用来加载额外的表项，这些表项在屏幕之外，本来不会被加载。
走查到这里，虽然只回答了两个问题，一是预布局的生命周期，二是预布局如何填充额外表项，但篇幅已经有点长了，关于“RecyclerView预布局的其他分析”及“RecyclerView如何实现表项动画”下回在讲。
推荐阅读
RecyclerView 系列文章目录如下:
