一.基本介紹

在平時的開發中我們或多或少地接觸過ListView，所以我們對ListView並不陌生。不過ListView存在某些缺點，所以谷歌又在ListView的基礎上推出了RecyclerView。記得RecyclerView剛推出時，網上許多文章都介紹了它的優點，甚至有人說RecyclerView可以完全取代ListView，我覺得這個說法太絕對了，雖然RecyclerView在ListView的基礎上優化了，但是實際應用中要使用哪個控制元件，還是要根據實際情況來看的。接下來我們從原始碼的角度瞭解RecyclerView，看看其與ListView的而區別。

二.原始碼解析

在看RecyclerView原始碼中的方法之前，我們有必要先看看RecyclerView原始碼中的內部類，這將更好地幫助我們看懂原始碼。所以我們先來看看其內部類。

·LayoutManager

LayoutManager 負責測量和擺放 item view，可以幫助我們實現普通的豎直，水平，網格等列表，在ListView中不存在這個內部類，所以使用ListView時，我們一般只能實現豎直方向列表。
在這個內部類中的大部分方法是實現測量child的大小，我們這裡不展開說。我們只說其中的一個方法，之所以說這個方法是因為我第一次看的時候，理解錯了，之後再看的時候雖然知道了實際的用途，但是卻存在疑問，到現在我也不太理解為什麼要這麼設定。先來看看這個方法吧。

 public void setAutoMeasureEnabled(boolean
 
 enabled) {
            mAutoMeasure = enabled;
        }

這個方法很簡單，只是設定mAutoMeasure的值，而mAutoMeasure只是用來標記是否自動測量（將AutoMeasure直接翻譯為自動測量了）。如果是自動測量，那麼就將所有的測量工作都交給LayoutManager來做，這好像就是本來設定LayoutManager的目的。而如果mAutoMeasure值為false，也就是不是自動測量了，根據原始碼裡面的說明，此時就應該由RecyclerView自己對child進行測量了。但是仔細閱讀原始碼和理解之後，發現無論是不是自動測量，最終測量都是由LayoutManager來做。
上面所說的問題也是我存在疑惑的地方，看起來mAutoMeasure這個變數並不是必需的，因為本來layoutManager的職責就包括測量item view。
所以請有理解這個設計意圖的讀者能幫我解惑，或者我上面的理解有錯的地方，懇請指正。

·Adapter

說起Adapter，我們都不陌生，因為在ListView裡面我們就有使用到Adapter，不過，RecyclerView對Adapter進行了改進。
在ListView中，我們可能會在Adapter寫一個內部類ViewHolder，減少不必要的findViewById操作。當然我們能自己選擇要不要做這一步優化。但是在RecyclerView中的Adapter原始碼中存在下面的方法。

 public final VH createViewHolder(ViewGroup parent, int viewType) {
            TraceCompat.beginSection(TRACE_CREATE_VIEW_TAG);
            final VH holder = onCreateViewHolder(parent, viewType);
            holder.mItemViewType = viewType;
            TraceCompat.endSection();
            return holder;
        }

從這裡看出RecyclerView強制我們必須使用ViewHolder，這樣做有什麼好處呢？ViewHolder快取了相關的View，當我們設定資料時，可以重複利用這些已經快取的子View去顯示不同item的資料，避免不必要的findViewById操作。

·Recycler

Recycler主要管理廢棄或分離的item的複用。這個類主要和LayoutManager配合使用。
接下來介紹這個類中幾個關鍵的變數和方法。

        //與RecyclerView繫結，但是已經標記了要移除或複用的ViewHolder列表
        ArrayList<ViewHolder> mAttachedScrap;

        //與RecyclerView分離的ViewHolder列表
        ArrayList<ViewHolder> mChangedScrap;

        //ViewHolder快取列表    
        ArrayList<ViewHolder> mCachedViews;

        //提供複用ViewHolder池
        RecycledViewPool mRecyclerPool;

        //開發者控制的ViewHolder快取
        ViewCacheExtension mViewCacheExtension;

        public View getViewForPosition(int position) {
            return getViewForPosition(position, false);
        }   

getViewForPosition（int）：獲取某個位置需要展示的View，先檢查是否有可複用的View，如果沒有就建立新的View並返回。
上面的具體過程如下：
a.檢查mChangedScrap，若匹配到則返回相應的ViewHolder。
b.檢查mAttachedScrap，操作同上。
c.檢查mViewCacheExtension，操作同上。
d.檢查mRecycledPool，操作同上。
e.如果上述操作都沒有成功，則執行Adapter.createViewHolder(),新建ViewHolder例項。
f.返回holder.itemView。

為什麼會按照上面次序檢查呢？這涉及到RecyclerView中的快取。一般系統預先提供了兩級快取，如果有特殊需求，可實現三級快取。這三級快取如下：
·第一級快取：這級快取主要用到的儲存容器有mCacheViews，mAttachedScrap和mChangedScrap。
·第二級快取：這級快取不是系統預先提供的，而是利用ViewCacheExtension充當附加的快取池，當RecyclerView從第一級快取找不到需要的View時，將會從ViewCacheExtension中找，這個快取時由開發者維護的，如果開發者不顯示設定它，則預設不會啟用。只有當我們有特殊需求時（例如在呼叫系統的快取池前返回一個特定的檢視），才會使用這級快取。
·第三級快取：這級的快取主要用到最強大的快取器RecycledViewPool。

·RecycledViewPool

上面說到RecycledViewPool是最強大的快取器，之所以這麼說是因為RecycledViewPool使我們能在RecycledView之間共享ViewHolder，所以其一般能繫結多個Adapter。

說完RecycledView中的內部類，接下來說說其內部的方法。RecycledView是一個控制元件，所以我們還是按照View的繪製流程來看RecycledView的原始碼。

·onMeasure

protected void onMeasure(int widthSpec, int heightSpec) {
       //如果LayoutManager為空則先初始化
        if (mLayout == null) {
            defaultOnMeasure(widthSpec, heightSpec);
            return;
        }
        if (mLayout.mAutoMeasure) {
            ...
                //如果RecycledView是第一次進行測量則呼叫 dispatchLayoutStep1()
            if (mState.mLayoutStep == State.STEP_START) {
                dispatchLayoutStep1();
            }
            ...
            dispatchLayoutStep2();

            //只要RecycledView中有一個child無法得到確切的寬高，就要重新測量
            if (mLayout.shouldMeasureTwice()) {
                  ...
                dispatchLayoutStep2();

            }
        } else {
            if (mHasFixedSize) {
                mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);
                return;
            }
           ...
        }
    }

上面只貼出了onMeasure的部分程式碼，從上面我們可以看出在測量過程中會呼叫dispatchLayoutStep1()和dispatchLayoutStep2()方法，所以接下來我們分別看看這兩個方法。

     /**
      根據原始碼的說明，我們可以知道這個方法會找出那些不需要移除的child，然後預先設定它們的位置
     */
     private void dispatchLayoutStep1() {
         ...
        if (mState.mRunSimpleAnimations) {      
            int count = mChildHelper.getChildCount();
            //遍歷找出不需要移除的child
            for (int i = 0; i < count; ++i) {
                 ....
                }
            }
        //預先設定不需要移除的child的位置
        if (mState.mRunPredictiveAnimations) {
              ...
            mLayout.onLayoutChildren(mRecycler, mState);
              ...
            for (int i = 0; i < mChildHelper.getChildCount(); ++i) {
                final View child = mChildHelper.getChildAt(i);
                final ViewHolder viewHolder = getChildViewHolderInt(child);
                if (viewHolder.shouldIgnore()) {
                    continue;
                }
                if (!mViewInfoStore.isInPreLayout(viewHolder)) {
                    int flags = ItemAnimator.buildAdapterChangeFlagsForAnimations(viewHolder);
                    boolean wasHidden = viewHolder
                            .hasAnyOfTheFlags(ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST);
                    if (!wasHidden) {
                        flags |= ItemAnimator.FLAG_APPEARED_IN_PRE_LAYOUT;
                    }
                    final ItemHolderInfo animationInfo = mItemAnimator.recordPreLayoutInformation(
                            mState, viewHolder, flags, viewHolder.getUnmodifiedPayloads());
                    if (wasHidden) {
                        recordAnimationInfoIfBouncedHiddenView(viewHolder, animationInfo);
                    } else {
                        mViewInfoStore.addToAppearedInPreLayoutHolders(viewHolder, animationInfo);
                    }
                }
            }
            ...
        } else {
            clearOldPositions();
        }
       ...
    }

 /**
    在這個方法裡面才真正根據View測得的狀態去設定其位置，這個方法可能會被多次呼叫（比如當Adapter中的資料發生改變），不過經過這個方法
    之後，View的寬高完全確定下來了。
*/
 private void dispatchLayoutStep2() {
        eatRequestLayout();
        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();
        resumeRequestLayout(false);
    }

·onLayout（）：在onLayout中會呼叫dispatchLayout（）方法， dispatchLayout（）實際就像layoutChildren（）的封裝，在這個方法完成對各個child位置的設定。具體實現還是呼叫了上面所說的dispatchLayoutStep1()和dispatchLayoutStep2()。在確保了這兩個方法已經呼叫之後，還會呼叫dispatchLayoutStep3()。
dispatchLayoutStep3()主要是儲存所有View相關的動畫資訊，然後觸發動畫和做一些必要的清理。

·onDraw（）：只是遍歷了所有的child並呼叫他們的onDraw（）方法。

關於RecycledView的部分原始碼介紹完了，通過學習原始碼和日常開發的使用，我們都能發現RecycledView和ListView的區別，雖然RecycledView比ListView效能好了一些，在佈局方面也靈活許多，但個人覺得RecycledView在使用上比ListView麻煩了一些。所以實際開發中選擇哪一個並不是絕對的，根據實際選擇合適的就行了，也不用一昧的擡高RecycledView的地位。