RecyclerView原理

時間 2019-11-20

標籤 recyclerview 原理简体版

原文原文鏈接

在分析RecyclerView源碼以前，咱們仍是對RecyclerView有一個初步的瞭解，簡單的瞭解它是什麼，它的基本結構有哪些。緩存

RecyclerView是Google爸爸在2014年的IO大會提出來（看來RecyclerView的年齡仍是比較大了😂），具體目的是否是用來替代ListView的，樓主也不知道，由於那時候樓主還在讀高二。可是在實際開發中，自從有了RecyclerView，ListView和GridView就不多用了，因此咱們暫且認爲RecyclerView的目的是替代ListView和GridView。架構

RecyclerView自己是一個展現大量數據的控件，相比較ListView,RecyclerView的4級緩存(也有人說是3級緩存，這些都不重要😂)就表現的很是出色，在性能方面相比於ListView提高了很多。同時因爲LayoutManager的存在,讓RecyclerView不只有ListView的特色，同時兼有GridView的特色。這多是RecyclerView受歡迎的緣由之一吧。app

RecyclerView在設計方面上也是很是的靈活，不一樣的部分承擔着不一樣的職責。其中Adapter負責提供數據，包括建立ViewHolder和綁定數據，LayoutManager負責ItemView的測量和佈局,ItemAnimator負責每一個ItemView的動畫，ItemDecoration負責每一個ItemView的間隙。這種插拔式的架構使得RecyclerView變得很是的靈活，每個人均可以根據自身的需求來定義不一樣的部分。ide

正由於這種插拔式的設計，使得RecyclerView在使用上相比較於其餘的控件稍微難那麼一點點，不過這都不算事，誰叫RecyclerView這麼惹人愛呢😂。佈局

本文參考文章：性能

進階RecyclerView源碼解析(一)——繪製流程動畫

https://www.jianshu.com/p/c52b947fe064ui

RecyclerView剖析this

https://blog.csdn.net/qq_23012315/article/details/50807224spa

RecyclerView剖析——續

https://blog.csdn.net/qq_23012315/article/details/51096696

注意，本文RecyclerView源碼均來自於27.1.1

/ measure /

無論RecyclerView是多麼神奇，它也是一個View，因此分析它的三大流程是很是有必要的。同時，若是瞭解過RecyclerView的同窗應該都知道，RecyclerView的三大流程跟普通的View比較，有很大的不一樣。

首先，咱們來看看measure過程，來看看RecyclerView的onMeasure方法。

protected void onMeasure(int widthSpec, int heightSpec) {
    if (mLayout == null) {
        // 第一種狀況
    }
    if (mLayout.isAutoMeasureEnabled()) {
        // 第二種狀況
    } else {
        // 第三種狀況
    }
}

onMeasure方法仍是有點長，這裏我將它分爲3種狀況，我將簡單解釋這三種狀況。

mLayout即LayoutManager的對象。咱們知道，當RecyclerView的LayoutManager爲空時，RecyclerView不能顯示任何的數據，在這裏咱們找到答案。

LayoutManager開啓了自動測量時，這是一種狀況。在這種狀況下，有可能會測量兩次。

第三種狀況就是沒有開啓自動測量的狀況，這種狀況比較少，由於爲了RecyclerView支持warp_content屬性，系統提供的LayoutManager都開啓自動測量的，不過咱們仍是要分析的。

首先咱們來第一種狀況。

(1).當LayoutManager爲空時

這種狀況下比較簡單，咱們來看看源碼：

if (mLayout == null) {
defaultOnMeasure(widthSpec, heightSpec);
return;
}

直接調了defaultOnMeasure方法，咱們繼續來看defaultOnMeasure方法。

void defaultOnMeasure(int widthSpec, int heightSpec) {
    // calling LayoutManager here is not pretty but that API is already public and it is better
    // than creating another method since this is internal.
    final int width = LayoutManager.chooseSize(widthSpec,
            getPaddingLeft() + getPaddingRight(),
            ViewCompat.getMinimumWidth(this));
    final int height = LayoutManager.chooseSize(heightSpec,
            getPaddingTop() + getPaddingBottom(),
            ViewCompat.getMinimumHeight(this));

    setMeasuredDimension(width, height);
}

在defaultOnMeasure方法裏面，先是經過LayoutManager的chooseSize方法來計算值，而後就是setMeasuredDimension方法來設置寬高。咱們來看看：

public static int chooseSize(int spec, int desired, int min) {
    final int mode = View.MeasureSpec.getMode(spec);
    final int size = View.MeasureSpec.getSize(spec);
    switch (mode) {
        case View.MeasureSpec.EXACTLY:
            return size;
        case View.MeasureSpec.AT_MOST:
            return Math.min(size, Math.max(desired, min));
        case View.MeasureSpec.UNSPECIFIED:
        default:
            return Math.max(desired, min);
    }
}

chooseSize方法表達的意思比較簡單，就是經過RecyclerView的測量mode來獲取不一樣的值，這裏就不詳細的解釋了。

到此，第一種狀況就分析完畢了。由於當LayoutManager爲空時，那麼當RecyclerView處於onLayout階段時，會調用dispatchLayout方法。而在dispatchLayout方法裏面有這麼一行代碼：

if (mLayout == null) {
    Log.e(TAG, "No layout manager attached; skipping layout");
    // leave the state in START
    return;
}

因此，當LayoutManager爲空時，不顯示任何數據是理所固然的。

如今咱們來看看第二種狀況，也就是正常的狀況。

(2). 當LayoutManager開啓了自動測量

在分析這種狀況以前，咱們先對了解幾個東西。

RecyclerView的測量分爲兩步，分別調用dispatchLayoutStep1和dispatchLayoutStep2。同時，瞭解過RecyclerView源碼的同窗應該知道在RecyclerView的源碼裏面還一個dispatchLayoutStep3方法。這三個方法的方法名比較接近，因此容易讓人搞混淆。本文會詳細的講解這三個方法的做用。

因爲在這種狀況下，只會調用dispatchLayoutStep1和dispatchLayoutStep2這兩個方法，因此這裏會重點的講解這兩個方法。而dispatchLayoutStep3方法的調用在RecyclerView的onLayout方法裏面，因此在後面分析onLayout方法時再來看dispatchLayoutStep3方法。

咱們在分析以前，先來看一個東西--mState.mLayoutStep。這個變量有幾個取值狀況。咱們分別來看看：

從上表中，咱們瞭解到mState.mLayoutStep的三個狀態對應着不一樣的dispatchLayoutStep方法。這一點，咱們必須清楚，不然接下來的代碼將難以理解。

好了，前戲準備的差很少，如今應該進入高潮了😂。咱們開始正式的分析源碼了。

if (mLayout.isAutoMeasureEnabled()) {
    final int widthMode = MeasureSpec.getMode(widthSpec);
    final int heightMode = MeasureSpec.getMode(heightSpec);

    /**
     * This specific call should be considered deprecated and replaced with
     * {@link #defaultOnMeasure(int, int)}. It can't actually be replaced as it could
     * break existing third party code but all documentation directs developers to not
     * override {@link LayoutManager#onMeasure(int, int)} when
     * {@link LayoutManager#isAutoMeasureEnabled()} returns true.
     */
    mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);

    final boolean measureSpecModeIsExactly =
            widthMode == MeasureSpec.EXACTLY && heightMode == MeasureSpec.EXACTLY;
    if (measureSpecModeIsExactly || mAdapter == null) {
        return;
    }

    if (mState.mLayoutStep == State.STEP_START) {
        dispatchLayoutStep1();
    }
    // set dimensions in 2nd step. Pre-layout should happen with old dimensions for
    // consistency
    mLayout.setMeasureSpecs(widthSpec, heightSpec);
    mState.mIsMeasuring = true;
    dispatchLayoutStep2();

    // now we can get the width and height from the children.
    mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec);

    // if RecyclerView has non-exact width and height and if there is at least one child
    // which also has non-exact width & height, we have to re-measure.
    if (mLayout.shouldMeasureTwice()) {
        mLayout.setMeasureSpecs(
                MeasureSpec.makeMeasureSpec(getMeasuredWidth(), MeasureSpec.EXACTLY),
                MeasureSpec.makeMeasureSpec(getMeasuredHeight(), MeasureSpec.EXACTLY));
        mState.mIsMeasuring = true;
        dispatchLayoutStep2();
        // now we can get the width and height from the children.
        mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec);
    }
}

我將這段代碼分爲三步。咱們來看看：

調用LayoutManager的onMeasure方法進行測量。對於onMeasure方法，我也感受到很是的迷惑，發現傳統的LayoutManager都沒有實現這個方法。後面，咱們會將簡單的看一下這個方法。

若是mState.mLayoutStep爲State.STEP_START的話，那麼就會執行dispatchLayoutStep1方法，而後會執行dispatchLayoutStep2方法。

若是須要第二次測量的話，會再一次調用dispatchLayoutStep2 方法。

以上三步，咱們一步一步的來分析。首先，咱們來看看第一步，也是看看onMeasure方法。

LayoutManager的onMeasure方法究竟爲咱們作什麼，咱們來看看：

public void onMeasure(Recycler recycler, State state, int widthSpec, int heightSpec) {
mRecyclerView.defaultOnMeasure(widthSpec, heightSpec);
}

默認是調用的RecyclerView的defaultOnMeasure方法,至於defaultOnMeasure方法裏面究竟作了什麼，這在前面已經介紹過了，這裏就再也不介紹了。

View的onMeasure方法的做用一般來講有兩個。一是測量自身的寬高，從RecyclerView來看，它將本身的測量工做託管給了LayoutManager的onMeasure方法。因此，咱們在自定義LayoutManager時，須要注意onMeasure方法存在，不過從官方提供的幾個LayoutManager，都沒有重寫這個方法。因此不到萬得已，最好不要重寫LayoutManager的onMeasure方法；二是測量子View,不過到這裏咱們尚未看到具體的實現。

接下來，咱們來分析第二步，看看dispatchLayoutStep1方法和dispatchLayoutStep2方法究竟作了什麼。

在正式分析第二步以前，咱們先對這三個方法有一個大概的認識。

咱們回到onMeasure方法裏面，先看看整個執行過程。

if (mState.mLayoutStep == State.STEP_START) {
dispatchLayoutStep1();
}
// set dimensions in 2nd step. Pre-layout should happen with old dimensions for
// consistency
mLayout.setMeasureSpecs(widthSpec, heightSpec);
mState.mIsMeasuring = true;
dispatchLayoutStep2();

若是mState.mLayoutStep == State.STEP_START時，纔會調用 dispatchLayoutStep1方法，這裏與咱們前面介紹mLayoutStep對應起來了。如今咱們看看dispatchLayoutStep1方法

private void dispatchLayoutStep1() {
    mState.assertLayoutStep(State.STEP_START);
    fillRemainingScrollValues(mState);
    mState.mIsMeasuring = false;
    startInterceptRequestLayout();
    mViewInfoStore.clear();
    onEnterLayoutOrScroll();
    processAdapterUpdatesAndSetAnimationFlags();
    saveFocusInfo();
    mState.mTrackOldChangeHolders = mState.mRunSimpleAnimations && mItemsChanged;
    mItemsAddedOrRemoved = mItemsChanged = false;
    mState.mInPreLayout = mState.mRunPredictiveAnimations;
    mState.mItemCount = mAdapter.getItemCount();
    findMinMaxChildLayoutPositions(mMinMaxLayoutPositions);

    if (mState.mRunSimpleAnimations) {
       // 找到沒有被remove的ItemView,保存OldViewHolder信息，準備預佈局
    }
    if (mState.mRunPredictiveAnimations) {
       // 進行預佈局
    } else {
        clearOldPositions();
    }
    onExitLayoutOrScroll();
    stopInterceptRequestLayout(false);
    mState.mLayoutStep = State.STEP_LAYOUT;
}

本文只簡單分析一下這個方法，由於這個方法跟ItemAnimator有莫大的關係，後續在介紹ItemAnimator時會詳細的分析。在這裏，咱們將重點放在processAdapterUpdatesAndSetAnimationFlags裏面，由於這個方法計算了mRunSimpleAnimations和mRunPredictiveAnimations。

private void processAdapterUpdatesAndSetAnimationFlags() {
    if (mDataSetHasChangedAfterLayout) {
        // Processing these items have no value since data set changed unexpectedly.
        // Instead, we just reset it.
        mAdapterHelper.reset();
        if (mDispatchItemsChangedEvent) {
            mLayout.onItemsChanged(this);
        }
    }
    // simple animations are a subset of advanced animations (which will cause a
    // pre-layout step)
    // If layout supports predictive animations, pre-process to decide if we want to run them
    if (predictiveItemAnimationsEnabled()) {
        mAdapterHelper.preProcess();
    } else {
        mAdapterHelper.consumeUpdatesInOnePass();
    }
    boolean animationTypeSupported = mItemsAddedOrRemoved || mItemsChanged;
    mState.mRunSimpleAnimations = mFirstLayoutComplete
            && mItemAnimator != null
            && (mDataSetHasChangedAfterLayout
            || animationTypeSupported
            || mLayout.mRequestedSimpleAnimations)
            && (!mDataSetHasChangedAfterLayout
            || mAdapter.hasStableIds());
    mState.mRunPredictiveAnimations = mState.mRunSimpleAnimations
            && animationTypeSupported
            && !mDataSetHasChangedAfterLayout
            && predictiveItemAnimationsEnabled();
}

這裏咱們的重心放在mFirstLayoutComplete變量裏面，咱們發現mRunSimpleAnimations的值與mFirstLayoutComplete有關，mRunPredictiveAnimations同時跟mRunSimpleAnimations有關。因此這裏咱們能夠得出一個結論,當RecyclerView第一次加載數據時，是不會執行的動畫。換句話說，每一個ItemView尚未layout完畢，怎麼會進行動畫。這一點，咱們也能夠經過Demo來證實，這裏也就不展現了。

接下來咱們看看dispatchLayoutStep2方法，這個方法是真正佈局children。咱們來看看：

private void dispatchLayoutStep2() {
    startInterceptRequestLayout();
    onEnterLayoutOrScroll();
    mState.assertLayoutStep(State.STEP_LAYOUT | State.STEP_ANIMATIONS);
    mAdapterHelper.consumeUpdatesInOnePass();
    mState.mItemCount = mAdapter.getItemCount();
    mState.mDeletedInvisibleItemCountSincePreviousLayout = 0;

    // Step 2: Run layout
    mState.mInPreLayout = false;
    mLayout.onLayoutChildren(mRecycler, mState);

    mState.mStructureChanged = false;
    mPendingSavedState = null;

    // onLayoutChildren may have caused client code to disable item animations; re-check
    mState.mRunSimpleAnimations = mState.mRunSimpleAnimations && mItemAnimator != null;
    mState.mLayoutStep = State.STEP_ANIMATIONS;
    onExitLayoutOrScroll();
    stopInterceptRequestLayout(false);
}

在這裏，咱們重點的看兩行代碼。一是在這裏，咱們能夠看到Adapter的getItemCount方法被調用；二是調用了LayoutManager的onLayoutChildren方法,這個方法裏面進行對children的測量和佈局，同時這個方法也是這裏的分析重點。

系統的LayoutManager的onLayoutChildren方法是一個空方法，因此須要LayoutManager的子類本身來實現。從這裏，咱們能夠得出兩個點。

1. 子類LayoutManager須要本身實現onLayoutChildren方法，從而來決定RecyclerView在該LayoutManager的策略下，應該怎麼佈局。從這裏，咱們看出來RecyclerView的靈活性。

2. LayoutManager相似於ViewGroup,將onLayoutChildren方法(ViewGroup是onLayout方法)公開出來，這種模式在Android中很常見的。

這裏，我先不對onLayoutChildren方法進行展開，待會會詳細的分析。

接下來，咱們來分析第三種狀況--沒有開啓自動測量。

(3).沒有開啓自動測量

咱們先來看看這一塊的代碼。

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

例如上面的代碼，我將分爲2步：

1. 若是mHasFixedSize爲true(也就是調用了setHasFixedSize方法)，將直接調用LayoutManager的onMeasure方法進行測量。

2. 若是mHasFixedSize爲false，同時此時若是有數據更新，先處理數據更新的事務，而後調用LayoutManager的onMeasure方法進行測量

經過上面的描述，咱們知道，若是未開啓自動測量，那麼確定會調用LayoutManager的onMeasure方法來進行測量，這就是LayoutManager的onMeasure方法的做用。

至於onMeasure方法怎麼進行測量，那就得看LayoutManager的實現類。在這裏，咱們就不進行深刻的追究了。

/ layout /

measure過程分析的差很少了，接下來咱們就該分析第二個過程--layout。咱們來看看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;
}

onLayout方法自己沒有作多少的事情，重點仍是在dispatchLayout方法裏面。

void dispatchLayout() {
    if (mAdapter == null) {
        Log.e(TAG, "No adapter attached; skipping layout");
        // leave the state in START
        return;
    }
    if (mLayout == null) {
        Log.e(TAG, "No layout manager attached; skipping layout");
        // leave the state in START
        return;
    }
    mState.mIsMeasuring = false;
    if (mState.mLayoutStep == State.STEP_START) {
        dispatchLayoutStep1();
        mLayout.setExactMeasureSpecsFrom(this);
        dispatchLayoutStep2();
    } else if (mAdapterHelper.hasUpdates() || mLayout.getWidth() != getWidth()
            || mLayout.getHeight() != getHeight()) {
        // First 2 steps are done in onMeasure but looks like we have to run again due to
        // changed size.
        mLayout.setExactMeasureSpecsFrom(this);
        dispatchLayoutStep2();
    } else {
        // always make sure we sync them (to ensure mode is exact)
        mLayout.setExactMeasureSpecsFrom(this);
    }
    dispatchLayoutStep3();
}

dispatchLayout方法也是很是的簡單，這個方法保證RecyclerView必須經歷三個過程--dispatchLayoutStep一、dispatchLayoutStep二、dispatchLayoutStep3。

同時，在後面的文章中，你會看到dispatchLayout方法其實還爲RecyclerView節省了不少步驟，也就是說，在RecyclerView經歷一次完整的dispatchLayout以後，後續若是參數有所變化時，可能只會經歷最後的1步或者2步。固然這些都是後話了😂。

對於dispatchLayoutStep1和dispatchLayoutStep2方法，咱們前面已經講解了，這裏就不作過多的解釋了。這裏，咱們就簡單的看一下dispatchLayoutStep3方法吧。

private void dispatchLayoutStep3() {
    // ······
    mState.mLayoutStep = State.STEP_START;
    // ······
}

爲何這裏只是簡單看一下dispatchLayoutStep3方法呢？由於這個方法主要是作Item的動畫，也就是咱們熟知的ItemAnimator的執行，而本文不對動畫進行展開，因此先省略動畫部分。

在這裏，咱們須要關注dispatchLayoutStep3方法的是，它將mLayoutStep重置爲了State.STEP_START。也就是說若是下一次從新開始dispatchLayout的話，那麼確定會經歷dispatchLayoutStep一、dispatchLayoutStep二、dispatchLayoutStep3三個方法。

以上就是RecyclerView的layout過程，是否是感受很是的簡單？RecyclerView跟其餘ViewGroup不一樣的地方在於，若是開啓了自動測量，在measure階段，已經將Children佈局完成了；若是沒有開啓自動測量，則在layout階段才佈局Children。

/ draw /

接下來，咱們來分析三大流程的最後一個階段--draw。在正式分析draw過程以前，我先來對RecyclerView的draw作一個概述。

RecyclerView分爲三步，咱們來看看：

1. 調用super.draw方法。這裏主要作了兩件事：1. 將Children的繪製分發給ViewGroup;2. 將分割線的繪製分發給ItemDecoration。

2. 若是須要的話，調用ItemDecoration的onDrawOver方法。經過這個方法，咱們在每一個ItemView上面畫上不少東西。

3. 若是RecyclerView調用了setClipToPadding,會實現一種特殊的滑動效果--每一個ItemView能夠滑動到padding區域。

咱們來看看這部分的代碼：

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);
    }
    // 第三步
    // TODO If padding is not 0 and clipChildrenToPadding is false, to draw glows properly, we
    // need find children closest to edges. Not sure if it is worth the effort.
    // ······
}

熟悉三大流程的同窗，確定知道第一步會回調到onDraw方法裏面，也就是說關於Children的繪製和ItemDecoration的繪製，是在onDraw方法裏面。

@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);
    }
}

onDraw方法是否是很是的簡單？調用super.onDraw方法將Children的繪製分發給ViewGroup執行；而後將ItemDecoration的繪製分發到ItemDecoration的onDraw方法裏面去。從這裏，咱們能夠看出來，RecyclerView的設計實在是太靈活了！

至於其他兩步都比較簡單，這裏就不詳細分析了。不過，從這裏，咱們終於明白了ItemDecoration的onDraw方法和onDrawOver方法的區別。

/ onLayoutChildren方法 /

從總體來講，RecyclerView的三大流程仍是比較簡單，不過在整個過程當中，咱們彷佛忽略了一個過程--那就是RecyclerView究竟是怎麼layout children的？

前面在介紹dispatchLayoutStep2方法時，只是簡單的介紹了，RecyclerView經過調用LayoutManager的onLayoutChildren方法。LayoutManager自己對這個方法沒有進行實現，因此必須得看看它的子類，這裏咱們就來看看LinearLayoutManager。

因爲LinearLayoutManager的onLayoutChildren方法比較長，這裏不可能貼出完整的代碼，因此這裏我先對這個方法作一個簡單的概述，方便你們理解。

1. 肯定錨點的信息，這裏面的信息包括：1.Children的佈局方向，有start和end兩個方向；2. mPosition和mCoordinate，分別表示Children開始填充的position和座標。

2. 調用detachAndScrapAttachedViews方法，detach掉或者remove掉RecyclerView的Children。這一點原本不在本文的講解範圍內，可是爲了後續對RecyclerView的緩存機制有更好的瞭解，這裏特別的提醒一下。

3. 根據錨點信息，調用fill方法進行Children的填充。這個過程當中根據錨點信息的不一樣，可能會調用兩次fill方法。

接下來，咱們看看代碼：

public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
    // layout algorithm:
    // 1) by checking children and other variables, find an anchor coordinate and an anchor
    //  item position.
    // 2) fill towards start, stacking from bottom
    // 3) fill towards end, stacking from top
    // 4) scroll to fulfill requirements like stack from bottom.
    // create layout state
    // ······
    // 第一步
    final View focused = getFocusedChild();
    if (!mAnchorInfo.mValid || mPendingScrollPosition != NO_POSITION
            || mPendingSavedState != null) {
        mAnchorInfo.reset();
        mAnchorInfo.mLayoutFromEnd = mShouldReverseLayout ^ mStackFromEnd;
        // calculate anchor position and coordinate
        updateAnchorInfoForLayout(recycler, state, mAnchorInfo);
        mAnchorInfo.mValid = true;
    }
    // ······
    // 第二步
    detachAndScrapAttachedViews(recycler);
    mLayoutState.mIsPreLayout = state.isPreLayout();
    // 第三步
    if (mAnchorInfo.mLayoutFromEnd) {
        // fill towards start
        updateLayoutStateToFillStart(mAnchorInfo);
        mLayoutState.mExtra = 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.mExtra = 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.mExtra = extraForStart;
            fill(recycler, mLayoutState, state, false);
            startOffset = mLayoutState.mOffset;
        }
    } else {
        // fill towards end
        updateLayoutStateToFillEnd(mAnchorInfo);
        mLayoutState.mExtra = 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.mExtra = 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.mExtra = extraForEnd;
            fill(recycler, mLayoutState, state, false);
            endOffset = mLayoutState.mOffset;
        }
    }
    // ······
}

相信從上面的代碼均可以找出每一步的執行。如今，咱們來詳細分析每一步。首先來看第一步--肯定錨點的信息。

要想看錨點信息的計算過程，咱們能夠從updateAnchorInfoForLayout方法裏面來找出答案，咱們來看看updateAnchorInfoForLayout方法：

private void updateAnchorInfoForLayout(RecyclerView.Recycler recycler, RecyclerView.State state,
        AnchorInfo anchorInfo) {
    // 第一種計算方式
    if (updateAnchorFromPendingData(state, anchorInfo)) {
        return;
    }
    // 第二種計算方式
    if (updateAnchorFromChildren(recycler, state, anchorInfo)) {
        return;
    }
    // 第三種計算方式
    anchorInfo.assignCoordinateFromPadding();
    anchorInfo.mPosition = mStackFromEnd ? state.getItemCount() - 1 : 0;
}

我相信經過上面的代碼註釋，你們都能明白updateAnchorInfoForLayout方法到底幹了嘛，這裏我簡單分析一下這三種肯定所作的含義，具體是怎麼作的，這裏就不討論，由於這裏面的細節太多了，深刻的討論容易將咱們聰明無比的大腦搞暈😂。

1. 第一種計算方式，表示含義有兩種：1.RecyclerView被重建，期間回調了onSaveInstanceState方法，因此目的是爲了恢復上次的佈局；2.RecyclerView調用了scrollToPosition之類的方法，因此目的是讓RecyclerView滾到準確的位置上去。因此，錨點的信息根據上面的兩種狀況來計算。

2. 第二種計算方法，從Children上面來計算錨點信息。這種計算方式也有兩種狀況：1. 若是當前有擁有焦點的Child，那麼有當前有焦點的Child的位置來計算錨點；2. 若是沒有child擁有焦點，那麼根據佈局方向(此時佈局方向由mLayoutFromEnd來決定)獲取可見的第一個ItemView或者最後一個ItemView。

3. 若是前面兩種方式都計算失敗了，那麼採用第三種計算方式，也就是默認的計算方式。

以上就是updateAnchorInfoForLayout方法所作的事情，這裏就不詳細糾結每種計算方式的細節，有興趣的同窗能夠看看。

至於第二步，調用detachAndScrapAttachedViews方法對全部的ItemView進行回收,這部分的內容屬於RecyclerView緩存機制的部分，本文先在這裏埋下一個伏筆，後續專門講解RecyclerView會詳細的分析它，因此這裏就不講解了。

接下來咱們來看看第三步，也就是調用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);

    }
     // ······
}