RecyclerView緩存機制(scrap view)

這是RecyclerView緩存機制系列文章的第四篇,系列文章的目錄如下:

  1. RecyclerView緩存機制(咋復用?)
  2. RecyclerView緩存機制(回收些啥?)
  3. RecyclerView緩存機制(回收去哪?)
  4. RecyclerView緩存機制(scrap view)

第一篇中遺留的一個問題還沒有解決:復用表項時優先級最高的scrap view是用來干嘛的?這篇文章試著通過閱讀源碼來解答這個問題。

scrap view對應的存儲結構是final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>();。理解成員變量用途的最好辦法是 “搜索它在什么時候被訪問” 。對于列表結構來說就相當于 1. 在什么時候往列表添加內容? 2. 在什么時候清空列表內容?

添加內容

全局搜索mAttachedScrap被訪問的地方,其中只有一處調用了mAttachedScrap.add():

public final class Recycler {
        /**
         * Mark an attached view as scrap.
         * 回收ViewHolder到scrap集合(mAttachedScrap或mChangedScrap)
         *
         * <p>"Scrap" views are still attached to their parent RecyclerView but are eligible
         * for rebinding and reuse. Requests for a view for a given position may return a
         * reused or rebound scrap view instance.</p>
         * scrap view依然依附于它的父親。。。
         *
         * @param view View to scrap
         */
        void scrapView(View view) {
            final ViewHolder holder = getChildViewHolderInt(view);
            if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID)
                    || !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) {
                if (holder.isInvalid() && !holder.isRemoved() && !mAdapter.hasStableIds()) {
                    throw new IllegalArgumentException("Called scrap view with an invalid view."
                            + " Invalid views cannot be reused from scrap, they should rebound from"
                            + " recycler pool." + exceptionLabel());
                }
                holder.setScrapContainer(this, false);
                //添加到mAttachedScrap集合中
                mAttachedScrap.add(holder);
            } else {
                if (mChangedScrap == null) {
                    mChangedScrap = new ArrayList<ViewHolder>();
                }
                holder.setScrapContainer(this, true);
                //添加到mChangedScrap集合中
                mChangedScrap.add(holder);
            }
        }
}

沿著調用鏈繼續往上:

public abstract static class LayoutManager {
        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()) {
                removeViewAt(index);
                recycler.recycleViewHolderInternal(viewHolder);
            }
            //detach表項并入scrap集合
            else {
                detachViewAt(index);
                recycler.scrapView(view);
                mRecyclerView.mViewInfoStore.onViewDetached(viewHolder);
            }
        }
}

根據viewHolder的不同狀態,要么將其將其添加到mAttachedScrap集合,要么將其存入回收池。其中recycleViewHolderInternal()RecyclerView緩存機制(回收去哪?)分析過。
沿著調用鏈繼續向上:

public abstract static class LayoutManager {
        /**
         * Temporarily detach and scrap all currently attached child views. Views will be scrapped
         * into the given Recycler. The Recycler may prefer to reuse scrap views before
         * other views that were previously recycled.
         * 暫時將當可見表項進行分離并回收
         *
         * @param recycler Recycler to scrap views into
         */
        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);
            }
        }
       /**
         * Lay out all relevant child views from the given adapter.
         * 從給定的adapter布局所有的孩子
         */
        public void onLayoutChildren(Recycler recycler, State state) {
            ...
            //在填充表項之前回收所有表項
            detachAndScrapAttachedViews(recycler);
            ...
            if (mAnchorInfo.mLayoutFromEnd) {
                ...
                //填充表項
                fill(recycler, mLayoutState, state, false);
                ...
            }
            ...
        }
}

public class RecyclerView extends ViewGroup implements ScrollingView, NestedScrollingChild2 {
    //RecyclerView布局的第二步
    private void dispatchLayoutStep2() {
        ...
        mLayout.onLayoutChildren(mRecycler, mState);
        ...
    }
}
  • 在將表項一個個填充到列表之前會先將其先回收到mAttachedScrap中,回收數據的來源是LayoutManager的孩子,而LayoutManager的孩子都是屏幕上可見的表項。
  • 注釋中“暫時將當可見表項進行分離并回收”,既然是“暫時回收”,那待會必然會發生“復用”。復用邏輯可移步RecyclerView緩存機制(咋復用?)
  • 至此可以得出結論:mAttachedScrap用于屏幕中可見表項的回收和復用

清空內容

全局搜索mAttachedScrap被訪問的地方,其中只有一處調用了mAttachedScrap.clear():

public final class Recycler {
        void clearScrap() {
            mAttachedScrap.clear();
            if (mChangedScrap != null) {
                mChangedScrap.clear();
            }
        }
}

public abstract static class LayoutManager {
        /**
         * Recycles the scrapped views.
         * 回收所有scrapped view
         */
        void removeAndRecycleScrapInt(Recycler recycler) {
            final int scrapCount = recycler.getScrapCount();
            // Loop backward, recycler might be changed by removeDetachedView()
            //遍歷搜有scrap view并重置ViewHolder狀態
            for (int i = scrapCount - 1; i >= 0; i--) {
                final View scrap = recycler.getScrapViewAt(i);
                final ViewHolder vh = getChildViewHolderInt(scrap);
                if (vh.shouldIgnore()) {
                    continue;
                }
                vh.setIsRecyclable(false);
                if (vh.isTmpDetached()) {
                    mRecyclerView.removeDetachedView(scrap, false);
                }
                if (mRecyclerView.mItemAnimator != null) {
                    mRecyclerView.mItemAnimator.endAnimation(vh);
                }
                vh.setIsRecyclable(true);
                recycler.quickRecycleScrapView(scrap);
            }
            //清空scrap view集合
            recycler.clearScrap();
            if (scrapCount > 0) {
                mRecyclerView.invalidate();
            }
        }
}

沿著調用鏈向上:

public class RecyclerView extends ViewGroup implements ScrollingView, NestedScrollingChild2 {
    //RecyclerView布局的最后一步
    private void dispatchLayoutStep3() {
        ...
        mLayout.removeAndRecycleScrapInt(mRecycler);
        ...
}

至此可以得出結論:mAttachedScrap生命周期起始于RecyclerView布局開始,終止于RecyclerView布局結束。

總結

經過四篇文章的分析,RecyclerVeiw的四級緩存都分析完了,總結如下:

  1. Recycler有4個層次用于緩存ViewHolder對象,優先級從高到底依次為ArrayList<ViewHolder> mAttachedScrapArrayList<ViewHolder> mCachedViews、ViewCacheExtension mViewCacheExtensionRecycledViewPool mRecyclerPool。如果四層緩存都未命中,則重新創建并綁定ViewHolder對象

  2. 緩存性能:

    緩存 重新創建ViewHolder 重新綁定數據
    mAttachedScrap false false
    mCachedViews false false
    mRecyclerPool false true
  1. 緩存容量:
    • mAttachedScrap:沒有大小限制,但最多包含屏幕可見表項。
    • mCachedViews:默認大小限制為2,放不下時,按照先進先出原則將最先進入的ViewHolder存入回收池以騰出空間。
    • mRecyclerPool:對ViewHolderviewType分類存儲(通過SparseArray),同類ViewHolder存儲在默認大小為5的ArrayList中。
  2. 緩存用途:
    • mAttachedScrap:用于布局過程中屏幕可見表項的回收和復用。
    • mCachedViews:用于移出屏幕表項的回收和復用,且只能用于指定位置的表項,有點像“回收池預備隊列”,即總是先回收到mCachedViews,當它放不下的時候,按照先進先出原則將最先進入的ViewHolder存入回收池。
    • mRecyclerPool:用于移出屏幕表項的回收和復用,且只能用于指定viewType的表項
  3. 緩存結構:
    • mAttachedScrapArrayList<ViewHolder>
    • mCachedViewsArrayList<ViewHolder>
    • mRecyclerPool:對ViewHolderviewType分類存儲在SparseArray<ScrapData>中,同類ViewHolder存儲在ScrapData中的ArrayList
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,030評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,310評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,951評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,796評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,566評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,055評論 1 322
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,142評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,303評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,799評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,683評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,899評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,409評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,135評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,520評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,757評論 1 282
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,528評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,844評論 2 372