RecyclerView 内存性能优越,这得益于它独特的缓存机制。第一篇中遗留的一个问题还没有解决:复用表项时优先级最高的scrap view
是用来干嘛的?这篇文章试着通过阅读源码来解答这个问题。
这是RecyclerView
缓存机制系列文章的第四篇,系列文章的目录如下:
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
的四级缓存都分析完了,总结如下:
-
Recycler
有4个层次用于缓存ViewHolder
对象,优先级从高到底依次为ArrayList<ViewHolder> mAttachedScrap
、ArrayList<ViewHolder> mCachedViews
、ViewCacheExtension mViewCacheExtension
、RecycledViewPool mRecyclerPool
。如果四层缓存都未命中,则重新创建并绑定ViewHolder
对象 -
缓存性能:
缓存 重新创建 ViewHolder
重新绑定数据 mAttachedScrap false false mCachedViews false false mRecyclerPool false true -
缓存容量:
mAttachedScrap
:没有大小限制,但最多包含屏幕可见表项。mCachedViews
:默认大小限制为2,放不下时,按照先进先出原则将最先进入的ViewHolder
存入回收池以腾出空间。mRecyclerPool
:对ViewHolder
按viewType
分类存储(通过SparseArray
),同类ViewHolder
存储在默认大小为5的ArrayList
中。
-
缓存用途:
mAttachedScrap
:用于布局过程中屏幕可见表项的回收和复用。mCachedViews
:用于移出屏幕表项的回收和复用,且只能用于指定位置的表项,有点像“回收池预备队列”,即总是先回收到mCachedViews
,当它放不下的时候,按照先进先出原则将最先进入的ViewHolder
存入回收池。mRecyclerPool
:用于移出屏幕表项的回收和复用,且只能用于指定viewType
的表项
-
缓存结构:
mAttachedScrap
:ArrayList<ViewHolder>
mCachedViews
:ArrayList<ViewHolder>
mRecyclerPool
:对ViewHolder
按viewType
分类存储在SparseArray<ScrapData>
中,同类ViewHolder
存储在ScrapData
中的ArrayList
中
推荐阅读
RecyclerView 系列文章目录如下: