RecyclerView的缓存机制及使用策略

开发 前端
当RecyclerView不再需要某个ViewHolder时(例如,当列表项被完全移出屏幕并且缓存已满时),ViewHolder会被放入RecycledViewPool并最终可能被系统回收。

RecyclerView的缓存机制是为了提高列表滚动时的性能。采用了多级缓存策略来存储和复用视图(View),减少视图的创建和销毁,进而减少内存分配和GC的频率。

缓存层级

负责回收和复用ViewHolder的类是Recycler,负责缓存的主要就是这个类的几个成员变量。

public final class Recycler {

    // 存放可见范围内的 ViewHolder (但是在 onLayoutChildren 的时候,会将所有 View 都会缓存到这), 从这里复用的 ViewHolder 如果 position 或者 id 对应的上,则不需要重新绑定数据。
    final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>();
    // 存放可见范围内并且数据发生了变化的 ViewHolder,从这里复用的 ViewHolder 需要重新绑定数据。
    ArrayList<ViewHolder> mChangedScrap = null;
    // 存放 remove 掉的 ViewHolder,从这里复用的 ViewHolder 如果 position 或者 id 对应的上,则不需要重新绑定数据。
    final ArrayList<ViewHolder> mCachedViews = new ArrayList<ViewHolder>(); 
    // 默认值是 2
    private int mRequestedCacheMax = DEFAULT_CACHE_SIZE; 
    // 默认值是 2
    int mViewCacheMax = DEFAULT_CACHE_SIZE; 

    // 存放 remove 掉,并且重置了数据的 ViewHolder,从这里复用的 ViewHolder 需要重新绑定数据。 // 默认值大小是 5 
    RecycledViewPool mRecyclerPool; 
    // 自定义的缓存
    private ViewCacheExtension mViewCacheExtension; 
    }

RecyclerView的缓存机制主要由四个部分组成,它们按照从高到低的优先级排列:

  1. 「Scrap缓存(Scrap Heap)」

包括mAttachedScrap和mChangedScrap,也称为屏内缓存,因为它们主要用于保存屏幕内当前可见或者即将可见的ViewHolder。

mAttachedScrap:存放的是已添加到RecyclerView但与RecyclerView临时分离(例如在滚动或布局调整过程中)的ViewHolder。

mChangedScrap:存放的是数据已改变但尚未重新绑定数据的ViewHolder,通常用于动画播放等场景。

  1. 「Cache缓存(mCachedViews)」

又称离屏缓存,用于保存最新被移除(remove)但尚未被回收的ViewHolder。

缓存的大小是有限制的,默认最大数量为2(由DEFAULT_CACHE_SIZE定义)。

当需要展示新视图时,会首先检查Cache缓存中是否有可用的ViewHolder。

  1. 「ViewCacheExtension」

为开发者预留的缓存池,允许开发者自定义缓存策略,存储更多的或特定类型的ViewHolder。

开发者可以通过实现ViewCacheExtension接口来扩展缓存功能。

  1. 「RecycledViewPool(mRecyclerPool)」

终极的回收缓存池,用于存放被标识为废弃(即其他缓存池不再需要的)的ViewHolder。

这些ViewHolder已经被抹除了数据,需要重新绑定数据才能使用。

RecycledViewPool会根据不同的item类型创建不同的List来存储ViewHolder。

缓存使用策略

int fill(RecyclerView.Recycler recycler, LayoutState layoutState,
        RecyclerView.State state, boolean stopOnFocusable) {
    // max offset we should set is mFastScroll + available
    final int start = layoutState.mAvailable;
    //首选该语句块的判断,判断当前状态是否为滚动状态,如果是的话,则触发 recycleByLayoutState 方法
    if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) {
        // TODO ugly bug fix. should not happen
        if (layoutState.mAvailable < 0) {
            layoutState.mScrollingOffset += layoutState.mAvailable;
        }
        // 分析1----回收
        recycleByLayoutState(recycler, layoutState);
        }
    while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
        //分析2----复用
        layoutChunk(recycler, state, layoutState, layoutChunkResult);
    }
}

// 分析1----回收 
// 通过一步步追踪,我们发现最后调用的是 removeAndRecycleViewAt() 
public void removeAndRecycleViewAt(int index, @NonNull Recycler recycler) {
    final View view = getChildAt(index);
    //分析1-1
    removeViewAt(index);
    //分析1-2
    recycler.recycleView(view);
}
// 分析1-1
// 从 RecyclerView 移除一个 View 
public void removeViewAt(int index) {
    final View child = getChildAt(index);
    if (child != null) {
        mChildHelper.removeViewAt(index);
    }
}
//分析1-2 
// recycler.recycleView(view) 最终调用的是 recycleViewHolderInternal(holder) 进行回收 VH (ViewHolder)
void recycleViewHolderInternal(ViewHolder holder) {
    if (forceRecycle || holder.isRecyclable()) {
        //判断是否满足放进 mCachedViews 
        if (mViewCacheMax > 0 && !holder.hasAnyOfTheFlags(ViewHolder.FLAG_INVALID| ViewHolder.FLAG_REMOVED| ViewHolder.FLAG_UPDATE| ViewHolder.FLAG_ADAPTER_POSITION_UNKNOWN)){
            // 判断 mCachedViews 是否已满
            if (cachedViewSize >= mViewCacheMax && cachedViewSize > 0) {
                // 如果满了就将下标为0(即最早加入的)移除,同时将其加入到 RecyclerPool 中
                recycleCachedViewAt(0);
                cachedViewSize--;
                }  
            mCachedViews.add(targetCacheIndex, holder);
            cached = true;
            }
        //如果没有满足上面的条件,则直接存进 RecyclerPool 中    
        if (!cached) {
            addViewHolderToRecycledViewPool(holder, true);
            recycled = true;
         } 
     }
}

//分析2
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,
        LayoutState layoutState, LayoutChunkResult result) {
    //分析2-1
    View view = layoutState.next(recycler);
    if (layoutState.mScrapList == null) {
        if (mShouldReverseLayout == (layoutState.mLayoutDirection
                == LayoutState.LAYOUT_START)) {
            //添加到 RecyclerView 上
            addView(view);
        } else {
            addView(view, 0);
        }
    }
}
//分析2-1
//layoutState.next(recycler) 最后调用的是 tryGetViewHolderForPositionByDeadline() 这个方法正是 复用 核心的方法
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
        boolean dryRun, long deadlineNs) {
    // 0) If there is a changed scrap, try to find from there
    // 例如:我们调用 notifyItemChanged 方法时
    if (mState.isPreLayout()) {
        // 如果是 changed 的 ViewHolder 那么就先从 mChangedScrap 中找
        holder = getChangedScrapViewForPosition(position);
        fromScrapOrHiddenOrCache = holder != null;
    }
    // 1) Find by position from scrap/hidden list/cache
    if (holder == null) {
        //如果在上面没有找到(holder == null),那就尝试从通过 pos 在 mAttachedScrap/ mHiddenViews / mCachedViews 中获取
        holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
    }
    if (holder == null) {
        // 2) Find from scrap/cache via stable ids, if exists
        if (mAdapter.hasStableIds()) {
            //如果在上面没有找到(holder == null),那就尝试从通过 id 在 mAttachedScrap/ mCachedViews 中获取
            holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),
        }
        if (holder == null && mViewCacheExtension != null) {
            //这里是通过自定义缓存中获取,忽略
        }
        //如果在上面都没有找到(holder == null),那就尝试在 RecycledViewPool 中获取
        if (holder == null) { // fallback to pool
            holder = getRecycledViewPool().getRecycledView(type);
            if (holder != null) {
                //这里拿的是,要清空数据的
                holder.resetInternal();
            }
        }
        //如果在 Scrap / Hidden / Cache / RecycledViewPool 都没有找到,那就只能创建一个了。
        if (holder == null) {
            holder = mAdapter.createViewHolder(RecyclerView.this, type);
        }
    }
    return holder;
}
  • 「RecyclerView滚动时」:首先移除滑出屏幕的item,并将这些ViewHolder存入Cache缓存(mCachedViews)。如果Cache缓存已满,则将更旧的ViewHolder存入RecycledViewPool。
  • 「数据更新时」:如果屏幕内的某个item数据发生变化,但ViewHolder仍然可见,那么这个ViewHolder会被放入mChangedScrap。当需要重新绑定数据时,会从这个缓存中取出ViewHolder。
  • 「删除item时」:被删除的item对应的ViewHolder首先会进入Scrap缓存,然后可能会被移入Cache缓存或RecycledViewPool。

「注意」:当RecyclerView不再需要某个ViewHolder时(例如,当列表项被完全移出屏幕并且缓存已满时),ViewHolder会被放入RecycledViewPool并最终可能被系统回收。

缓存机制的好处

  • 「减少视图创建和销毁」:通过复用已有的ViewHolder,大大减少视图的创建和销毁次数,从而节省内存和提高性能。
  • 「优化滚动性能」:当滚动列表时,由于大部分视图都可以从缓存中快速获取,可以保持流畅的滚动体验。
  • 「降低GC频率」:由于减少了视图的创建和销毁,也降低了GC的频率,进一步提高了应用的性能。

责任编辑:武晓燕 来源: 沐雨花飞蝶
相关推荐

2021-03-29 11:51:07

缓存储存数据

2021-08-18 07:56:04

AndroidRecyclerVie复用

2018-11-30 09:03:55

HTTP缓存Web

2022-05-10 08:58:56

CacheHTTP

2011-07-11 15:28:19

MySQL索引优化

2015-10-08 16:40:50

缓存头像策略

2023-11-16 08:22:14

LruCacheAndroid

2009-06-18 14:51:12

Hibernate缓存Hibernate

2013-08-02 14:19:50

Java日志缓存

2009-11-23 17:56:44

PHP缓存机制

2023-02-24 16:46:25

Glide缓存机制

2009-06-17 15:43:03

Hibernate缓存

2023-05-04 16:10:13

缓存前端

2024-06-24 00:30:00

2019-03-20 09:11:50

Web缓存策略

2018-07-12 15:30:03

HTTP缓存机制

2019-03-22 09:50:52

WebJavaScript前端

2010-10-13 16:44:10

MySQL查询缓存机制

2009-11-09 17:55:13

WCF缓存

2016-03-09 09:54:47

Python开发缓存机制
点赞
收藏

51CTO技术栈公众号