RecyclerView源码分析(三)--布局流程

在上一篇文章中分析了RecyclerView的Measure过程。在Measure过程中的自动化Measure中，应用过布局流程的，得到Child的边界值，但是当时我们略过了，那么今天接着分析RecyclerView的布局过程。

PS:源码版本为androidx1.0.0版本，如果下面与你的源码有出入，请核实版本是否相同。

RecyclerView的Layout过程

首先贴一下源码，不同版本的RecyclerView源码会不同，如果你也打开了源码，请确定源码版本是否一致。

    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();这一句。去看一下dispatchLayout();的源码。

    void dispatchLayout() {
        .....
        mState.mIsMeasuring = false;
        // (1) 没有执行过布局流程的情况
        if (mState.mLayoutStep == State.STEP_START) {
            dispatchLayoutStep1();
            mLayout.setExactMeasureSpecsFrom(this);
            dispatchLayoutStep2();
        } else if (mAdapterHelper.hasUpdates() || mLayout.getWidth() != getWidth()
                || mLayout.getHeight() != getHeight()) {
            //(2) 执行过布局流程，但是之后size又有变化的情况
            mLayout.setExactMeasureSpecsFrom(this);
            dispatchLayoutStep2();
        } else {
            //(3) 执行过布局流程，可以直接使用之前数据的情况
            mLayout.setExactMeasureSpecsFrom(this);
        }
        dispatchLayoutStep3();
    }

 我们首先忽略各种判断条件，可以明显看出RecyclerView的布局过程分为3步：dispatchLayoutStep1，dispatchLayoutStep2和dispatchLayoutStep3。在之前自动化Measure过程中我们为了得到Child的边界值，使用了dispatchLayoutStep1和dispatchLayoutStep2，所以在dispatchLayout中分了三种情况进行处理：

1. 没有执行过布局流程的情况
2. 执行过布局流程，但是之后size又有变化的情况
3. 执行过布局流程，可以直接使用之前数据的情况

不过，无论什么情况，最终都是完成dispatchLayoutStep1，dispatchLayoutStep2和dispatchLayoutStep3这三步，这样的情况区分只是为了避免重复计算。接下按步分析。

dispatchLayoutStep1分析

dispatchLayoutStep1的主要作用有以下几点：

1. 处理Adapter的更新
2. 决定哪些动画播放
3. 保存当前View的信息
4. 如果有必要的话再进行上一布局操作，并保存它的信息

然后请详细看注释。

    private void dispatchLayoutStep1() {
        //检测当前状态，是否是 没有执行过布局流程的情况
        mState.assertLayoutStep(State.STEP_START);
        fillRemainingScrollValues(mState);
        mState.mIsMeasuring = false;
        //防止在layout的过程中，某一个子View触发了requestLayout方法，从而导致多余的layout操作，配合stopInterceptRequestLayout(false)使用
        startInterceptRequestLayout();
        mViewInfoStore.clear();
        onEnterLayoutOrScroll();
        // 下面这个方法很重要，那么我们先略过，看下下面的内容。哎~我就这么调皮!哈哈，
        // 其实是，在没有讲动画流程之前，根本讲不清。这个是动画流程的中间过程。所以
        // ，在这里只要先知道，这里是处理Adapter更新，并计算动画类型的即可。
        processAdapterUpdatesAndSetAnimationFlags();

        saveFocusInfo();
        mState.mTrackOldChangeHolders = mState.mRunSimpleAnimations && mItemsChanged;
        mItemsAddedOrRemoved = mItemsChanged = false;
        mState.mInPreLayout = mState.mRunPredictiveAnimations;
        mState.mItemCount = mAdapter.getItemCount();
        findMinMaxChildLayoutPositions(mMinMaxLayoutPositions);

        // 下面的内容是需要运行动画的情况下进行的，主要做的事情就是找出那些需要进
        // 行上一布局操作的ViewHolder，并且保存它们的边界信息。如果有更新操作(这个更新
        // 指的是内容的更新，不是插入删除的这种更新)，然后保存这些更新的ViewHolder
        if (mState.mRunSimpleAnimations) {
            ....
        }

        // 下面的内容是需要在布局结束之后运行动画的情况下执行的。主要做的事情就是
        // 执行上一布局操作，上一布局操作其实就是先以上一次的状态执行一遍LayoutManager
        // 的onLayoutChildren方法，其实RecyclerView的布局策略就是在
        // LayoutManager的onLayoutChildren方法中。执行一次它就获得了所有
        // ViewHolder的边界信息。只不过，这次获得的是之前状态下的ViewHolder的
        // 边界信息。不过这个应该是要在LayoutManager中，根据state的isPreLayout
        // 的返回值，选择使用新的还是旧的position。但我在系统给的几个LayoutManager中
        // 都没有看到。
        if (mState.mRunPredictiveAnimations) {
            .....
            mLayout.onLayoutChildren(mRecycler, mState);
            clearOldPositions();
        } else {
            clearOldPositions();
        }
        onExitLayoutOrScroll();
        stopInterceptRequestLayout(false);
        //布局状态改为  执行过布局流程
        mState.mLayoutStep = State.STEP_LAYOUT;
    }

嗯……，复杂的都省略了，感觉真是太爽了。

dispatchLayoutStep2分析

一路省略到了第二步，哈哈!dispatchLayoutStep2的主要作用有以下一点，注意是一点：

真正的布局!

private void dispatchLayoutStep2() {
    …… // 设置状态
    mState.mInPreLayout = false; // 更改此状态，确保不是会执行上一布局操作
    // 真正布局就是这一句话，布局的具体策略交给了LayoutManager，哈哈!这篇的主角讲完了!
    mLayout.onLayoutChildren(mRecycler, mState);
    …… // 设置和恢复状态
}

dispatchLayoutStep3分析

为了表明我是一个良心作者，我还是 坚持 把 对布局流程并没有什么卵用的 布局第三步 分析一下!
第三步主要做的事情就是：

保存信息，触发动画，清除垃圾

private void dispatchLayoutStep3() {
    …… // 设置状态
    if (mState.mRunSimpleAnimations) {
        …… // 需要动画的情况。找出ViewHolder现在的位置，并且处理改变动画。最后触发动画。
    }

    …… // 清除状态和清除无用的信息
    mLayout.onLayoutCompleted(mState); // 给LayoutManager的布局完成的回调
    …… // 清除状态和清除无用的信息，最后在恢复一些信息信息，比如焦点。
}

又一个十分复杂的函数让我给分析完了。

总结

这个源码分析的也是云里雾里，但是我们总结一下我们知道了什么：

1. RecyclerView并没有对内部的View进行布局。而是交给LayoutManager去做具体的布局操作，因此才会有LinearLayoutManager，GridLayoutManager,StaggeredGridLayoutManager这样灵活的布局。而且我们可以通过实现onLayoutChildren，自定义LayoutManager。
2. RecyclerView的布局过程中包含很多动画相关的处理。
3. RecyclerView的数据改变的动画是在布局过程的第三步中统一触发的。并不是一调用notify之后立即触发。

今天省略了很多内容，那些都是和动画相关的处理，下一篇就来分析，notify到动画播放的流程。敬请期待!!