RecyclerView缓存机制 | scrap view 的生命周期

9,624 阅读5分钟

RecyclerView 内存性能优越,这得益于它独特的缓存机制。第一篇中遗留的一个问题还没有解决:复用表项时优先级最高的scrap view是用来干嘛的?这篇文章试着通过阅读源码来解答这个问题。

这是RecyclerView缓存机制系列文章的第四篇,系列文章的目录如下:

  1. RecyclerView 缓存机制 | 如何复用表项?

  2. RecyclerView 缓存机制 | 回收些什么?

  3. RecyclerView 缓存机制 | 回收到哪去?

  4. RecyclerView缓存机制 | scrap view 的生命周期

  5. RecyclerView 动画原理 | pre-layout,post-layout 与 scrap 缓存的关系

scrap view对应的存储结构是final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>();。理解成员变量用途的最好办法是 “搜索它在什么时候被访问” 。对于列表结构来说就相当于 1. 在什么时候往列表添加内容? 2. 在什么时候清空列表内容?

添加内容

全局搜索mAttachedScrap被访问的地方,其中只有一处调用了mAttachedScrap.add():

public final class Recycler {
         // 回收 ViewHolder 到 scrap 集合(mAttachedScrap或mChangedScrap),
        void scrapView(View view) {
            final ViewHolder holder = getChildViewHolderInt(view);
            if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID)
                    || !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) {
                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.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 {
         // 暂时将当可见表项进行分离并回收
        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);
            }
        }

        // 布局所有子表项
        public void onLayoutChildren(Recycler recycler, State state) {
            ...
            // 在填充表项之前回收所有表项
            detachAndScrapAttachedViews(recycler);
            ...
            // 填充表项
            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 class RecyclerView {
    public final class Recycler {
        // 清空 scrap 结构
        void clearScrap() {
            mAttachedScrap.clear();
            if (mChangedScrap != null) {
                mChangedScrap.clear();
            }
        }
    }
}

Recycler.clearScrap()清空了 scrap 列表。而它会在LayoutManager.removeAndRecycleScrapInt()中被调用:

public abstract static class LayoutManager {
         // 回收所有 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布局结束。

分析完了 scrap 结构的生命周期和作用后,不免产生新的疑问:什么场景下需要回收并复用屏幕中可见的表项?限于篇幅原因,在读原码长知识 | RecyclerView 预布局 ,后布局与 scrap 缓存的关系中做了详细分析。

总结

经过四篇文章的分析,RecyclerVeiw的四级缓存都分析完了,总结如下:

  1. Recycler有4个层次用于缓存ViewHolder对象,优先级从高到底依次为ArrayList<ViewHolder> mAttachedScrapArrayList<ViewHolder> mCachedViewsViewCacheExtension mViewCacheExtensionRecycledViewPool mRecyclerPool。如果四层缓存都未命中,则重新创建并绑定ViewHolder对象

  2. 缓存性能:

    缓存重新创建ViewHolder重新绑定数据
    mAttachedScrapfalsefalse
    mCachedViewsfalsefalse
    mRecyclerPoolfalsetrue
  3. 缓存容量:

    • mAttachedScrap:没有大小限制,但最多包含屏幕可见表项。
    • mCachedViews:默认大小限制为2,放不下时,按照先进先出原则将最先进入的ViewHolder存入回收池以腾出空间。
    • mRecyclerPool:对ViewHolderviewType分类存储(通过SparseArray),同类ViewHolder存储在默认大小为5的ArrayList中。
  4. 缓存用途:

    • mAttachedScrap:用于布局过程中屏幕可见表项的回收和复用。
    • mCachedViews:用于移出屏幕表项的回收和复用,且只能用于指定位置的表项,有点像“回收池预备队列”,即总是先回收到mCachedViews,当它放不下的时候,按照先进先出原则将最先进入的ViewHolder存入回收池。
    • mRecyclerPool:用于移出屏幕表项的回收和复用,且只能用于指定viewType的表项
  5. 缓存结构:

    • mAttachedScrapArrayList<ViewHolder>
    • mCachedViewsArrayList<ViewHolder>
    • mRecyclerPool:对ViewHolderviewType分类存储在SparseArray<ScrapData>中,同类ViewHolder存储在ScrapData中的ArrayList

推荐阅读

RecyclerView 系列文章目录如下:

  1. RecyclerView 缓存机制 | 如何复用表项?

  2. RecyclerView 缓存机制 | 回收些什么?

  3. RecyclerView 缓存机制 | 回收到哪去?

  4. RecyclerView缓存机制 | scrap view 的生命周期

  5. 读源码长知识 | 更好的RecyclerView点击监听器

  6. 代理模式应用 | 每当为 RecyclerView 新增类型时就很抓狂

  7. 更好的 RecyclerView 表项子控件点击监听器

  8. 更高效地刷新 RecyclerView | DiffUtil二次封装

  9. 换一个思路,超简单的RecyclerView预加载

  10. RecyclerView 动画原理 | 换个姿势看源码(pre-layout)

  11. RecyclerView 动画原理 | pre-layout,post-layout 与 scrap 缓存的关系

  12. RecyclerView 动画原理 | 如何存储并应用动画属性值?

  13. RecyclerView 面试题 | 列表滚动时,表项是如何被填充或回收的?

  14. RecyclerView 面试题 | 哪些情况下表项会被回收到缓存池?

  15. RecyclerView 性能优化 | 把加载表项耗时减半 (一)

  16. RecyclerView 性能优化 | 把加载表项耗时减半 (二)

  17. RecyclerView 性能优化 | 把加载表项耗时减半 (三)

  18. RecyclerView 的滚动是怎么实现的?(一)| 解锁阅读源码新姿势

  19. RecyclerView 的滚动时怎么实现的?(二)| Fling

  20. RecyclerView 刷新列表数据的 notifyDataSetChanged() 为什么是昂贵的?