{

            if (mHasFixedSize) {

                mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);

                return;

            }

            // custom onMeasure

            if (mAdapterUpdateDuringMeasure) {

                startInterceptRequestLayout();

                onEnterLayoutOrScroll();

                processAdapterUpdatesAndSetAnimationFlags();

                onExitLayoutOrScroll();

                if (mState.mRunPredictiveAnimations) {

                    mState.mInPreLayout = true;

                } else {

                    // consume remaining updates to provide a consistent state with the layout pass.

                    mAdapterHelper.consumeUpdatesInOnePass();

                    mState.mInPreLayout = false;

                }

                mAdapterUpdateDuringMeasure = false;

                stopInterceptRequestLayout(false);

            } else if (mState.mRunPredictiveAnimations) {

                // If mAdapterUpdateDuringMeasure is false and mRunPredictiveAnimations is true:

                // this means there is already an onMeasure() call performed to handle the pending

                // adapter change, two onMeasure() calls can happen if RV is a child of LinearLayout

                // with layout_width=MATCH_PARENT. RV cannot call LM.onMeasure() second time

                // because getViewForPosition() will crash when LM uses a child to measure.

                setMeasuredDimension(getMeasuredWidth(), getMeasuredHeight());

                return;

            }

            if (mAdapter != null) {

                mState.mItemCount = mAdapter.getItemCount();

            } else {

                mState.mItemCount = 0;

            }

            startInterceptRequestLayout();

            mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);

            stopInterceptRequestLayout(false);

            mState.mInPreLayout = false; // clear

        } 

    /**

     * The final step of the layout where we save the information about views for animations,

     * trigger animations and do any necessary cleanup.

     */

    private void dispatchLayoutStep3() {
　　　　　// 动画

        mState.assertLayoutStep(State.STEP_ANIMATIONS);

        startInterceptRequestLayout();

        onEnterLayoutOrScroll();
　　　　　// 标记进行复位

        mState.mLayoutStep = State.STEP_START;

        if (mState.mRunSimpleAnimations) {

            // Step 3: Find out where things are now, and process change animations.

            // traverse list in reverse because we may call animateChange in the loop which may

            // remove the target view holder.

            for (int i = mChildHelper.getChildCount() - 1; i >= 0; i--) {

                ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i));

                if (holder.shouldIgnore()) {

                    continue;

                }

                long key = getChangedHolderKey(holder);

                final ItemHolderInfo animationInfo = mItemAnimator

                        .recordPostLayoutInformation(mState, holder);

                ViewHolder oldChangeViewHolder = mViewInfoStore.getFromOldChangeHolders(key);

                if (oldChangeViewHolder != null && !oldChangeViewHolder.shouldIgnore()) {

                    // run a change animation

                    // If an Item is CHANGED but the updated version is disappearing, it creates

                    // a conflicting case.

                    // Since a view that is marked as disappearing is likely to be going out of

                    // bounds, we run a change animation. Both views will be cleaned automatically

                    // once their animations finish.

                    // On the other hand, if it is the same view holder instance, we run a

                    // disappearing animation instead because we are not going to rebind the updated

                    // VH unless it is enforced by the layout manager.

                    final boolean oldDisappearing = mViewInfoStore.isDisappearing(

                            oldChangeViewHolder);

                    final boolean newDisappearing = mViewInfoStore.isDisappearing(holder);

                    if (oldDisappearing && oldChangeViewHolder == holder) {

                        // run disappear animation instead of change

                        mViewInfoStore.addToPostLayout(holder, animationInfo);

                    } else {

                        final ItemHolderInfo preInfo = mViewInfoStore.popFromPreLayout(

                                oldChangeViewHolder);

                        // we add and remove so that any post info is merged.

                        mViewInfoStore.addToPostLayout(holder, animationInfo);

                        ItemHolderInfo postInfo = mViewInfoStore.popFromPostLayout(holder);

                        if (preInfo == null) {

                            handleMissingPreInfoForChangeError(key, holder, oldChangeViewHolder);

                        } else {

                            animateChange(oldChangeViewHolder, holder, preInfo, postInfo,

                                    oldDisappearing, newDisappearing);

                        }

                    }

                } else {

                    mViewInfoStore.addToPostLayout(holder, animationInfo);

                }

            }

            // Step 4: Process view info lists and trigger animations 做动画

            mViewInfoStore.process(mViewInfoProcessCallback);

        }

        mLayout.removeAndRecycleScrapInt(mRecycler);
　　　　　// 记录数据，并把之前用到一些标志位复位

        mState.mPreviousLayoutItemCount = mState.mItemCount;

        mDataSetHasChangedAfterLayout = false;

        mDispatchItemsChangedEvent = false;

        mState.mRunSimpleAnimations = false;

        mState.mRunPredictiveAnimations = false;

        mLayout.mRequestedSimpleAnimations = false;

        if (mRecycler.mChangedScrap != null) {

            mRecycler.mChangedScrap.clear();

        }

        if (mLayout.mPrefetchMaxObservedInInitialPrefetch) {

            // Initial prefetch has expanded cache, so reset until next prefetch.

            // This prevents initial prefetches from expanding the cache permanently.

            mLayout.mPrefetchMaxCountObserved = 0;

            mLayout.mPrefetchMaxObservedInInitialPrefetch = false;

            mRecycler.updateViewCacheSize();

        }

        mLayout.onLayoutCompleted(mState);

        onExitLayoutOrScroll();

        stopInterceptRequestLayout(false);

        mViewInfoStore.clear();
        //

        if (didChildRangeChange(mMinMaxLayoutPositions[0], mMinMaxLayoutPositions[1])) {

            dispatchOnScrolled(0, 0);

        }

        recoverFocusFromState();

        resetFocusInfo();

    }

    public void draw(Canvas c) {

        super.draw(c);

        final int count = mItemDecorations.size();

        for (int i = 0; i < count; i++) {

            mItemDecorations.get(i).onDrawOver(c, this, mState);

        }

        // ......

}    

    @Override

    public void onDraw(Canvas c) {

        super.onDraw(c);

        final int count = mItemDecorations.size();

        for (int i = 0; i < count; i++) {

            mItemDecorations.get(i).onDraw(c, this, mState);

        }

    }

    @Override

    public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {

        // ......

        ensureLayoutState();

        mLayoutState.mRecycle = false;

        // resolve layout direction

        resolveShouldLayoutReverse();
　　　　　// ...... 

　　　　　// calculate anchor position and coordinate
　　　　　updateAnchorInfoForLayout(recycler, state, mAnchorInfo);
　　　　　mAnchorInfo.mValid = true;

// noRecycleSpace not needed: recycling doesn't happen in below's fill

        // invocations because mScrollingOffset is set to SCROLLING_OFFSET_NaN

        mLayoutState.mNoRecycleSpace = 0;

        if (mAnchorInfo.mLayoutFromEnd) {

            // fill towards start

            updateLayoutStateToFillStart(mAnchorInfo);

            mLayoutState.mExtraFillSpace = extraForStart;

            fill(recycler, mLayoutState, state, false);

            startOffset = mLayoutState.mOffset;

            final int firstElement = mLayoutState.mCurrentPosition;

            if (mLayoutState.mAvailable > 0) {

                extraForEnd += mLayoutState.mAvailable;

            }

            // fill towards end

            updateLayoutStateToFillEnd(mAnchorInfo);

            mLayoutState.mExtraFillSpace = extraForEnd;

            mLayoutState.mCurrentPosition += mLayoutState.mItemDirection;

            fill(recycler, mLayoutState, state, false);

            endOffset = mLayoutState.mOffset;

            if (mLayoutState.mAvailable > 0) {

                // end could not consume all. add more items towards start

                extraForStart = mLayoutState.mAvailable;

                updateLayoutStateToFillStart(firstElement, startOffset);

                mLayoutState.mExtraFillSpace = extraForStart;

                fill(recycler, mLayoutState, state, false);

                startOffset = mLayoutState.mOffset;

            }

        } else {

            // fill towards end

            updateLayoutStateToFillEnd(mAnchorInfo);

            mLayoutState.mExtraFillSpace = extraForEnd;

            fill(recycler, mLayoutState, state, false);

            endOffset = mLayoutState.mOffset;

            final int lastElement = mLayoutState.mCurrentPosition;

            if (mLayoutState.mAvailable > 0) {

                extraForStart += mLayoutState.mAvailable;

            }

            // fill towards start

            updateLayoutStateToFillStart(mAnchorInfo);

            mLayoutState.mExtraFillSpace = extraForStart;

            mLayoutState.mCurrentPosition += mLayoutState.mItemDirection;

            fill(recycler, mLayoutState, state, false);

            startOffset = mLayoutState.mOffset;

            if (mLayoutState.mAvailable > 0) {

                extraForEnd = mLayoutState.mAvailable;

                // start could not consume all it should. add more items towards end

                updateLayoutStateToFillEnd(lastElement, endOffset);

                mLayoutState.mExtraFillSpace = extraForEnd;

                fill(recycler, mLayoutState, state, false);

                endOffset = mLayoutState.mOffset;

            }

        }

        layoutForPredictiveAnimations(recycler, state, startOffset, endOffset);

        if (!state.isPreLayout()) {

            mOrientationHelper.onLayoutComplete();

        } else {

            mAnchorInfo.reset();

        }

        mLastStackFromEnd = mStackFromEnd;

        if (DEBUG) {

            validateChildOrder();

        }

    }

根据锚点信息，调用 fill 方法进行 Children 的填充。这个过程中根据锚点信息的不同，可能会调用两次 fill 方法。

updateAnchorInfoForLayout

要想看锚点信息的计算过程，我们可以从 updateAnchorInfoForLayout 方法里面来找出答案，我们来看看 updateAnchorInfoForLayout 方法：

    private void updateAnchorInfoForLayout(RecyclerView.Recycler recycler, RecyclerView.State state,

            AnchorInfo anchorInfo) {

        if (updateAnchorFromPendingData(state, anchorInfo)) {

            if (DEBUG) {

                Log.d(TAG, "updated anchor info from pending information");

            }

            return;

        }

        if (updateAnchorFromChildren(recycler, state, anchorInfo)) {

            if (DEBUG) {

                Log.d(TAG, "updated anchor info from existing children");

            }

            return;

        }

        if (DEBUG) {

            Log.d(TAG, "deciding anchor info for fresh state");

        }

        anchorInfo.assignCoordinateFromPadding();

        anchorInfo.mPosition = mStackFromEnd ? state.getItemCount() - 1 : 0;

    }

我相信通过上面的代码注释，大家都能明白 updateAnchorInfoForLayout 方法到底干了嘛，这里我简单分析一下这三种确定所做的含义，具体是怎么做的，这里就不讨论。

1. 第一种计算方式，表示含义有两种：1. RecyclerView 被重建，期间回调了 onSaveInstanceState 方法，所以目的是为了恢复上次的布局；2. RecyclerView 调用了scrollToPosition 之类的方法，所以目的是让

2. RecyclerView 滚到准确的位置上去。所以，锚点的信息根据上面的两种情况来计算。

3. 第二种计算方法，从C hildren 上面来计算锚点信息。这种计算方式也有两种情况：1. 如果当前有拥有焦点的 Child，那么有当前有焦点的 Child 的位置来计算锚点；2. 如果没有 child 拥有焦点，那么根据布局方向(此时布局方向由 mLayoutFromEnd 来决定)获取可见的第一个 ItemView 或者最后一个 ItemView。

4. 如果前面两种方式都计算失败了，那么采用第三种计算方式，也就是默认的计算方式。

fill 填充布局

然后就是调用 fill 方法来填充 Children。在正式分析填充过程时，我们先来看一张图片：

 

上图形象的展现出三种fill的情况。其中，我们可以看到第三种情况，fill 方法被调用了两次。

我们看看 fill 方法:

    int fill(RecyclerView.Recycler recycler, LayoutState layoutState,

            RecyclerView.State state, boolean stopOnFocusable) {

        // ······

        while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {

            // ······

            layoutChunk(recycler, state, layoutState, layoutChunkResult);

        }

         // ······

    }

fill 方法的代码比较长，其实都是来计算可填充的空间，真正填充 Child 的地方是 layoutChunk 方法。我们来看看 layoutChunk 方法。

void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,

        LayoutState layoutState, LayoutChunkResult result) {

    View view = layoutState.next(recycler);

    ...

    if (layoutState.mScrapList == null) {

        if (mShouldReverseLayout == (layoutState.mLayoutDirection

                == LayoutState.LAYOUT_START)) {

            addView(view);

        } else {

            addView(view, 0);

        }

    }

    ...

    measureChildWithMargins(view, 0, 0);

    ...

    // We calculate everything with View's bounding box (which includes decor and margins)

    // To calculate correct layout position, we subtract margins.

    layoutDecorated(view, left + params.leftMargin, top + params.topMargin,

            right - params.rightMargin, bottom - params.bottomMargin);

    ...

}

提醒下别小看这个 next 方法，RecyclerView 缓存机制的起点就是从这个方法开始，可想而知，这个方法到底为我们做了多少事情。

这里的 addView() 方法，其实就是 ViewGroup 的 addView() 方法；measureChildWithMargins() 方法看名字就知道是用于测量子控件大小的，这里我先跳过这个方法的解释，放在后面来做，目前就简单地理解为测量子控件大小就好了。下面是 layoutDecoreated() 方法：

        public void layoutDecorated(@NonNull View child, int left, int top, int right, int bottom) {
　　　　　　　// 将分割线考虑进去

            final Rect insets = ((LayoutParams) child.getLayoutParams()).mDecorInsets;

            child.layout(left + insets.left, top + insets.top, right - insets.right,

                    bottom - insets.bottom);

        }

总结上面代码，在 RecyclerView 的 measure 及 layout 阶段，填充 ItemView 的算法为：向父容器增加子控件，测量子控件大小，布局子控件，布局锚点向当前布局方向平移子控件大小，重复上诉步骤至 RecyclerView 可绘制空间消耗完毕或子控件已全部填充。

这样所有的子控件的 measure 及 layout 过程就完成了。回到 RecyclerView 的 onMeasure 方法，执行 mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec) 这行代码的作用就是根据子控件的大小，设置 RecyclerView 的大小。至此，RecyclerView 的 measure 和 layout 实际上已经完成了。

但是，你有可能已经发现上面过程中的问题了：如何确定 RecyclerView 的可绘制空间？不过，如果你熟悉 android 控件的绘制机制的话，这就不是问题。其实，这里的可绘制空间，可以简单地理解为父容器的大小；更准确的描述是，父容器对 RecyclerView 的布局大小的要求，可以通过 MeasureSpec.getSize() 方法获得。

总结

到这里，关于 RecyclerView 的绘制流程就讲完了，由于主打绘制流程，没有分析其他，可能会导致整个逻辑有些跳跃，但不妨碍理解整个绘制过程。

最后回到文章前面的问题上，可以发现 RecyclerView 将绘制过程其实是委托给 layoutManager 来操作，这和普通自定义 view 是很不一样的。这样的灵活操作，可以让使用者自定义各种样式，使得 RecyclerView 使用场景变得更加丰富。