上一篇部落格從原始碼角度分析了RecyclerView讀取快取的步驟，讓我們對於RecyclerView的快取有了一個初步的理解，但對於RecyclerView的快取的原理還是不能理解。本篇部落格將從實際專案角度來理解RecyclerView的快取原理。
專案的截圖如下：

其中可以看到，這裡是一個我們經常使用RecycleView實現列表。右側輸出面板展示了ScrapView的最大數量，CacheView的數量和內容，Pool中存在的內容。左側面板展示了onBindViewHolder和onCreateViewHolder的過程。(Demo是基於一篇部落格的Demo的拓展:手摸手第二彈，視覺化 RecyclerView 快取機制

1.ScrapViews

起初，我對於這個快取的概念一直很模糊，我嘗試過很多方法想要將這個快取中的View讀取出來看看裡面的內容，但是發現這個快取的大小總是為0，這個就讓我很疑惑一個大
小總是為0的快取還有什麼作用？
無意中讀到了一篇部落格，這篇部落格對於RecyclerView提出了Detach和Remove的概念的區別，對於RecycleView的ScrapView進行了講解。

1.1 Detach和Remove

所以我們需要區分兩個概念，Detach和Remove

detach

: 在ViewGroup中的實現很簡單，只是將ChildView從ParentView的ChildView陣列中移除，ChildView的mParent設定為null, 可以理解為輕量級的臨時remove, 因
為View此時和View樹還是藕斷絲連, 這個函式被經常用來改變ChildView在ChildView陣列中的次序。View被detach一般是臨時的，在後面會被重新attach。
remove: 真正的移除，不光被從ChildView陣列中除名，其他和View樹各項聯絡也會被徹底斬斷(不考慮Animation/LayoutTransition這種特殊情況)， 比如焦點被清除，從TouchTarget中被移除等。

1.2 快取作用

首先我們要了解，任何一個ViewGroup都會經歷兩次onLayout的過程，對應的childView就會經歷detach和attach的過程，而在這個過程中，ScrapViews就起了快取的作用，這樣就不需要重複建立childView和bind。
所以ScrapView主要用於對於螢幕內的ChildView的快取，快取中的ViewHolder不需要重新Bind，快取時機是在onLayout的過程中，並且用完即清空

1.3 Demo驗證

我們可以看一下demo驗證一下我們的想法。
首先我們重寫了RecylclerView的onLayout方法。

@Override
    protected void onLayout(boolean changed, int l, int t, int r, int b) {
        onLayoutListener.beforeLayout();
        super.onLayout(changed, l, t, r, b);
        onLayoutListener.afterLayout();
    }

在beforLayout時設定通過反射將RecyclerView內部的mAttachedScrap替換成我們自己重寫的資料結構。

public void setAllCache() {
        try {
            Field mRecycler =
                    Class.forName("android.support.v7.widget.RecyclerView").getDeclaredField("mRecycler");
            mRecycler.setAccessible(true);
            RecyclerView.Recycler recyclerInstance =
                    (RecyclerView.Recycler) mRecycler.get(this);

            Class<?> recyclerClass = Class.forName(mRecycler.getType().getName());
            Field mAttachedScrap = recyclerClass.getDeclaredField("mAttachedScrap");
            mAttachedScrap.setAccessible(true);
            mAttachedScrap.set(recyclerInstance, mAttachedRecord);
            Field mCacheViews = recyclerClass.getDeclaredField("mCachedViews");
            mCacheViews.setAccessible(true);
            mCacheViews.set(recyclerInstance, mCachedRecord);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

為什麼要這樣做哪？這裡利用了Hook的思想。這樣的話，RecyclerView內部在對mAttachedScrap進行操作的時候，比如RecyclerView內部對於mAttachedScrap的新增是使用add(T t)這個方法，這樣我們設定的子類只要重寫這個add(T t)的方法，在新增的時候就會呼叫我們子類重寫的add方法。

    @Override
    public boolean add(T t) {
        RecyclerView.ViewHolder vh = (RecyclerView.ViewHolder) t;
        RcyLog.log(key + "新增---【position=" + vh.getAdapterPosition() + "】");
        if (canReset) {
            if (size() + 1 > lastSize) {
                maxSize = size() + 1;
            }
        }
        return super.add(t);
    }

    @Override
    public T remove(int index) {
        RecyclerView.ViewHolder vh = (RecyclerView.ViewHolder) get(index);
        RcyLog.log(key + "移除---【position=" + vh.getAdapterPosition() + "】");
        return super.remove(index);
    }

可以看到這裡，當RecyclerView內部對mAttachedScrap進行add和remove的時候，我們都會進行列印log。並且記錄一下maxSize。按照我們的猜想，RecyclerView會在onLayout的過程中對mAttachedScrap進行新增和移除操作，執行完後，mAttachedScrap的大小為0。


可以看到我們開啟應用Demo的這個操作，沒有做其他任何操作，僅僅是開啟，mAttachedScrap經歷了新增螢幕內9個ChildView的過程，並將9個ChildView移除的過程。而mAttachedScrap的大小剛好為螢幕內可以顯示的Item的數量。
為什麼說不需要重寫Bind哪？通過上篇部落格，我們從原始碼角度對RecyclerView的快取有了一個初步的瞭解：

//先從scrap中尋找
        for (int i = 0; i < scrapCount; i++) {
            final ViewHolder holder = mAttachedScrap.get(i);
            if (!holder.wasReturnedFromScrap() && holder.getLayoutPosition() == position
                    && !holder.isInvalid() && (mState.mInPreLayout || !holder.isRemoved())) {
                holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP);
                return holder;
            }
        }


         boolean bound = false;
        if (mState.isPreLayout() && holder.isBound()) {
            // do not update unless we absolutely have to.
            holder.mPreLayoutPosition = position;
        } else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) {
            //如果FLAG是ViewHolder.FLAG_UPDATE | ViewHolder.FLAG_INVALID,則需要調bind
            if (DEBUG && holder.isRemoved()) {
                throw new IllegalStateException("Removed holder should be bound and it should"
                        + " come here only in pre-layout. Holder: " + holder
                        + exceptionLabel());
            }
            final int offsetPosition = mAdapterHelper.findPositionOffset(position);
            bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs);
        }

可以看到，我們在Scrap中尋找的時候，是有一個判斷!holder.isInvalid()，而對於需要bind的時候判斷是否需要bind有一個判斷holder.isInvalid()。所以兩個條件是互斥的。

2.CacheViews

CacheViews其實就是和我們平常使用過程中息息相關的一個快取。CacheViews快取的特點是CacheViews內的快取在複用的時候不需要呼叫bind，也就是在滑動的過程中，免去了bind的過程，提高滑動的效率。
#### 2.1 快取原始碼
首先來看一下對於CacheViews內快取的獲取的原始碼：

/ /Search in our first-level recycled view cache.
final int cacheSize = mCachedViews.size();
for (int i = 0; i < cacheSize; i++) {
final ViewHolder holder = mCachedViews.get(i);
// invalid view holders may be in cache if adapter has stable ids as they can be
// retrieved via getScrapOrCachedViewForId
if (!holder.isInvalid() && holder.getLayoutPosition() == position) {
if (!dryRun) {
mCachedViews.remove(i);
}
if (DEBUG) {
Log.d(TAG, "getScrapOrHiddenOrCachedHolderForPosition(" + position
+ ") found match in cache: " + holder);
}
return holder;
}
}

首先我們通過原始碼可以知道CacheViews是一個ArrayList，可以看到獲取的時候是遍歷CacheViews，當快取的ViewHolder和所需要的position相同的並且有效才可以複用。
和上面分析的一樣，可以知道這個快取的ViewHolder是有效的才可以複用，所以在判斷是否需要bind的時候，就不需要重新bind了。
接著來看一下快取的原始碼：
既然是快取，那肯定是滑動過程中的比較直觀：
“`
@Override
public boolean onTouchEvent(MotionEvent e) {
case MotionEvent.ACTION_MOVE: {
………
if (scrollByInternal(
canScrollHorizontally ? dx : 0,
canScrollVertically ? dy : 0,
vtev)) {
getParent().requestDisallowInterceptTouchEvent(true);
}
……..
return true;
}

boolean scrollByInternal(int x, int y, MotionEvent ev) {
    ......
        if (x != 0) {
            consumedX = mLayout.scrollHorizontallyBy(x, mRecycler, mState);
            unconsumedX = x - consumedX;
        }
        if (y != 0) {
            consumedY = mLayout.scrollVerticallyBy(y, mRecycler, mState);
            unconsumedY = y - consumedY;
        }
       .......
    return consumedX != 0 || consumedY != 0;
}


可以看到這裡省略了部分程式碼，在onTouchEvent的ACTION_MOVE事件中，可以看到，這裡對canScrollVertically方法進行了判斷，並最終將偏移量傳給了scrollByInternal方法，而在scrollByInternal方法中，呼叫了LayoutManager的scrollVerticallyBy方法。而scrollVerticallyBy最後呼叫了scrollBy方法。

int scrollBy(int dy, RecyclerView.Recycler recycler, RecyclerView.State state) {
……
//呼叫了fill方法
final int consumed = mLayoutState.mScrollingOffset
+ fill(recycler, mLayoutState, state, false);
……
return scrolled;
}

可以看到fill方法又調回了前一篇部落格分析的**fill()**方法，這樣就很明顯了。而快取的原始碼其實上面部落格上面提到過一個方法onLayoutChild()方法裡面有個detachAndScrapAttachedViews“`方法。

public void detachAndScrapAttachedViews(Recycler recycler) {
        final int childCount = getChildCount();
        for (int i = childCount - 1; i >= 0; i--) {
            final View v = getChildAt(i);
            scrapOrRecycleView(recycler, i, v);
        }
    }

    /**
     * 1.Recycle操作對應的是removeView, View被remove後呼叫Recycler的recycleViewHolderInternal回收其ViewHolder
     2.Scrap操作對應的是detachView，View被detach後呼叫Reccyler的scrapView暫存其ViewHolder
     * @param recycler
     * @param index
     * @param view
     */
    private void scrapOrRecycleView(Recycler recycler, int index, View view) {
        final ViewHolder viewHolder = getChildViewHolderInt(view);
        if (viewHolder.shouldIgnore()) {
            if (DEBUG) {
                Log.d(TAG, "ignoring view " + viewHolder);
            }
            return;
        }
        if (viewHolder.isInvalid() && !viewHolder.isRemoved()
                && !mRecyclerView.mAdapter.hasStableIds()) {
            //注意這裡是remove
            removeViewAt(index);
            //往cacheview和pool中
            recycler.recycleViewHolderInternal(viewHolder);
        } else {
            //注意這裡是detach
            detachViewAt(index);
            //存到scrap中
            recycler.scrapView(view);
            mRecyclerView.mViewInfoStore.onViewDetached(viewHolder);
        }
    }

這裡就可以看到前面所說的Remove和Detach的區別，如果是remove，會執行recycleViewHolderInternal(viewHolder);方法，而這個方法最終會將ViewHolder加入CacheView和Pool中，而當是Detach，會將View加入到ScrapViews中，注意View和ViewHolder的區別，前面提到過，ScrapViews是對View的複用，而CacheView和Pool是對ViewHolder的複用。
既然是看CacheViews，那麼就看一下recycleViewHolderInternal方法。

void recycleViewHolderInternal(ViewHolder holder) {
        ......
        if (forceRecycle || holder.isRecyclable()) {
            if (mViewCacheMax > 0
                    && !holder.hasAnyOfTheFlags(ViewHolder.FLAG_INVALID
                    | ViewHolder.FLAG_REMOVED
                    | ViewHolder.FLAG_UPDATE
                    | ViewHolder.FLAG_ADAPTER_POSITION_UNKNOWN)) {
                // Retire oldest cached view
                int cachedViewSize = mCachedViews.size();
                //如果超過預設大小，則刪除第一個
                if (cachedViewSize >= mViewCacheMax && cachedViewSize > 0) {
                //從CacheViews中刪除第一個，並加入到Pool中
                    recycleCachedViewAt(0);
                    cachedViewSize--;
                }
        ......
                //加入快取
                mCachedViews.add(targetCacheIndex, holder);
                cached = true;
            }
            if (!cached) {
                //不然直接加入Pool中
                addViewHolderToRecycledViewPool(holder, true);
                recycled = true;
            }
        .......
    }

可以看到幾個關鍵邏輯：

1.如果超過預設大小，則會移除CacheViews中的第一個，並加入到Pool中，然後在將需要加入快取的ViweHolder加入到CacheView中。
2.如果不能加入到CacheViews中，則加入到Pool中。

2.2 Demo驗證

(1)進入應用
我們首先進入應用會發現當前CacheViews的大小是0，也就是說進入應用時沒有滑動，是沒有任何ViewHolder回收的，這不需要解釋吧。。。，而且Bind也只走了頁面渲染的0-8。

(2)向下滑動一個，第一個移除
這時我們向下滑動，加載出第9個

可以看到這時候除了載入了頁面的position=9，還提前加載出了position=10，執行了onBind，而這時，由於第一個移出介面，所以position=0也就被加入到了CacheViews中。
(3)向上滑動，再顯示第一個

這時候我們會發現幾個特別的點：

1.onBind的面板沒有新的Log，說明新出來的position=0沒有走onBind方法。
2.CacheViews中由剛才儲存的position=0和position=10，變成了position=10和position=9
由此可見：
CacheViews中快取的ViewHolder當被複用的時候是不會走Bind流程的

RecyclerPool

其實根據前一節的講解，我們已經對RecycleView的快取有了一個很具體的瞭解了，RecyclerPool其實是RecyclerView區分ListView的一個亮點。利用這級快取我們可以實現多個RecyclerView之間的ViewHolder的複用。（關於這一點的利用我準備在下一篇部落格對RecycleView使用的技巧進行舉例講解）

3.1 快取原始碼

首先我們看一下ReyclerPool的結構。

public static class RecycledViewPool {
    private static final int DEFAULT_MAX_SCRAP = 5;
    static class ScrapData {
        ArrayList<ViewHolder> mScrapHeap = new ArrayList<>();
        int mMaxScrap = DEFAULT_MAX_SCRAP;
        long mCreateRunningAverageNs = 0;
        long mBindRunningAverageNs = 0;
    }
    SparseArray<ScrapData> mScrap = new SparseArray<>();
    }

可以看到RecyclerPool內部其實是一個SparseArray，可想而知，key就是我們的ViewType，而Value是ArrayList。
我們來看一下RecyclerPool的put方法。

public void putRecycledView(ViewHolder scrap) {
        final int viewType = scrap.getItemViewType();
        final ArrayList<ViewHolder> scrapHeap = getScrapDataForType(viewType).mScrapHeap;
        if (mScrap.get(viewType).mMaxScrap <= scrapHeap.size()) {
            return;
        }
        if (DEBUG && scrapHeap.contains(scrap)) {
            throw new IllegalArgumentException("this scrap item already exists");
        }
        //重置ViewHolder
        scrap.resetInternal();
        scrapHeap.add(scrap);
    }

其中resetInternal方法值得我們注意。

void resetInternal() {
        mFlags = 0;
        mPosition = NO_POSITION;
        mOldPosition = NO_POSITION;
        mItemId = NO_ID;
        mPreLayoutPosition = NO_POSITION;
        mIsRecyclableCount = 0;
        mShadowedHolder = null;
        mShadowingHolder = null;
        clearPayload();
        mWasImportantForAccessibilityBeforeHidden = ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_AUTO;
        mPendingAccessibilityState = PENDING_ACCESSIBILITY_STATE_NOT_SET;
        clearNestedRecyclerViewIfNotNested(this);
    }

可以看到所有被put進入RecyclerPool中的ViewHolder都會被重置，這也就意味著RecyclerPool中的ViewHolder再被複用的時候是需要重新Bind的。這一點就可以區分和CacheViews中快取的區別。

總結

還是那篇Bugly部落格中的圖片吧（都怪我太懶了。。。）

看過上面的分析，這張圖片就很好理解了。

最後

給大家分享幾篇我認為不錯的RecyclerView原始碼分析的部落格吧，我的分析其中有些地方就是從這些部落格中學習來的。

下篇部落格可能是RecyclerView分析系列的結尾篇了，可能從實際使用角度分析一些我所瞭解的RecyclerView的一些進階知識