版本：support-v7 25.3.1
发现问题
在对 性能优化-首页CPU占用优化 调研时发现，首页的OnCreateViewHolder存在高频次调用的情况，而常见的开源列表组件不存在此问题。
遂针对此问题，对recyclerview的复用机制进行分析。
缓存集合
1 mChangedScrap 表示数据已经改变的ViewHolder集合
2 mAttachedScrap 与RecyclerView尚未分离的ViewHolder集合
3 mCachedViews ViewHolder缓存集合，默认为2。
4 mViewCacheExtension 开发者可自定义集合
5 mRecyclerPool ViewHolder缓存池。 被用来做下一级的缓存。默认最大为五个。
缓存复用流程
从onCreateViewHolder的调用开始看
tryGetViewHolderForPositionByDeadline方法，也是复用机制的重点。
这是一个自带过期时间的view复用函数，返回的对象如果时间不允许，那么可能会是null或者未绑定的。
dryRun 控制使用完缓存之后，是否需要从缓存中删除。
1 从被改变的废料中获取组件
如果这里是一个改变了的废料，那么使用getChangedScrapViewForPosition函数去获取。
// 0) If there is a changed scrap, try to find from there
来看具体的实现方法，
ViewHolder getChangedScrapViewForPosition(int position)
2 根据 position 从已经改变的废料集合中搜索缓存
如果成功，则打回。 第二步 根据id查询废料缓存。
3 从隐藏或者缓存的组件集合中获取 根据posotion
getScrapOrHiddenOrCachedHolderForPosition // 1) Find by position from scrap/hidden list/cache
这里做了两件事情，第一个从缓存列表中获取holder，然后在验证其有效性。
其实这里的getScrapOrHiddenOrCachedHolderForPosition 方法是缓存的重点功能实现。
4 从隐藏和缓存组件集合中获取，根据ids
从自定义的扩展中读取缓存
略，项目中未使用此功能。
从RecyclerPool读取缓存
这级别的是一个根据view type 进行缓存的SparseArray对象。
收获
1） 加深了对RecyclerView 缓存机制的理解
2） 问题定位：
项目中的headview的高度比itemview的高度，高出很多倍。 所以在 当head view被回收的时候，缓存中的itemview数量不足以复用，导致多次调用手动实例化方法。
3） 优化建议：
使用了headview的情况下，建议head view的高度不要比正常的item高度超过太多。
这样可以使item的使用完全可以通过缓存消化，避免频繁的手动实例布局文件。
1426
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
