RecyclerView 缓存机制 | 如何复用表项？(1)
RecyclerView 内存性能优越，这得益于它独特的缓存机制，这一篇以走读源码的方式探究 RecyclerView 的缓存机制。
引子
- 如果列表中每个移出屏幕的表项都直接销毁，移入时重新创建，很不经济。所以RecyclerView引入了缓存机制。
- 回收是为了复用，复用的好处是有可能免去两个昂贵的操作：
- 为表项视图绑定数据
- 创建表项视图
- 下面几个问题对于理解“回收复用机制”很关键：
- 回收什么？复用什么？
- 回收到哪里去？从哪里获得复用？
- 什么时候回收？什么时候复用？
这一篇试着从已知的知识出发在源码中寻觅未知的“RecyclerView复用机制”。
(ps: 下文中的 粗斜体字 表示引导源码阅读的内心戏)
寻觅
触发复用的众多时机中必然包含下面这种：“当移出屏幕的表项重新回到界面”。表项本质上是一个View，屏幕上的表项必然需要依附于一棵View树，即必然有一个父容器调用了addView()。而 RecyclerView继承自 ViewGroup，遂以RecyclerView.addView()为切入点向上搜寻复用的代码。
在RecyclerView.java中全局搜索“addView”，发现RecyclerView()并没有对addView()函数重载，但找到一处addView()的调用：
//RecyclerView是ViewGroup的子类
public class RecyclerView extends ViewGroup implements ScrollingView, NestedScrollingChild2 {
...
private void initChildrenHelper() {
mChildHelper = new ChildHelper(new ChildHelper.Callback() {
...
@Override
public void addView(View child, int index) {
if (VERBOSE_TRACING) {
TraceCompat.beginSection("RV addView");
}
//直接调用ViewGroup.addView()
RecyclerView.this.addView(child, index);
if (VERBOSE_TRACING) {
TraceCompat.endSection();
}
dispatchChildAttached(child);
}
}
}
...
}
复制代码以ChildHelper.Callback.addView()为起点沿着调用链继续向上搜寻，经历了如下方法调用：
ChildHelper.addView()LayoutManager.addViewInt()LayoutManager.addView()LinearLayoutManager.layoutChunk()：
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) {
//获得下一个表项
View view = layoutState.next(recycler);
...
LayoutParams params = (LayoutParams) view.getLayoutParams();
if (layoutState.mScrapList == null) {
//将表项插入到列表中
if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) {
addView(view);
} else {
addView(view, 0);
}
}
...
}
复制代码addView(view)中传入的view是函数layoutState.next()的返回值。猜测该函数是用来获得下一个表项的。表项不止一个，应该有一个循环不断的获得下一个表项才对。 沿着刚才的调用链继续往上搜寻，就会发现：的确有一个循环！
public class LinearLayoutManager extends RecyclerView.LayoutManager implements ItemTouchHelper.ViewDropHandler, RecyclerView.SmoothScroller.ScrollVectorProvider {
...
int fill(RecyclerView.Recycler recycler, LayoutState layoutState,
RecyclerView.State state, boolean stopOnFocusable) {
...
//recyclerview 剩余空间
int remainingSpace = layoutState.mAvailable + layoutState.mExtra;
LayoutChunkResult layoutChunkResult = mLayoutChunkResult;
//不断填充，直到空间消耗完毕
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
layoutChunkResult.resetInternal();
if (VERBOSE_TRACING) {
TraceCompat.beginSection("LLM LayoutChunk");
}
//填充一个表项
layoutChunk(recycler, state, layoutState, layoutChunkResult);
...
}
...
}
}
复制代码而fill()是在onLayoutChildren()中被调用：
/**
* Lay out all relevant child views from the given adapter.
* 布局所有给定adapter中相关孩子视图
*/
public void onLayoutChildren(Recycler recycler, State state) {
Log.e(TAG, "You must override onLayoutChildren(Recycler recycler, State state) ");
}
复制代码看完注释，感觉前面猜测应该是正确的。onLayoutChildren()是用来布局RecyclerView中所有的表项的。回头去看一下layoutState.next()，表项复用逻辑应该就在其中。
public class LinearLayoutManager {
static class LayoutState {
/**
* Gets the view for the next element that we should layout.
* 获得下一个元素的视图用于布局
*/
View next(RecyclerView.Recycler recycler) {
if (mScrapList != null) {
return nextViewFromScrapList();
}
//调用了Recycler.getViewForPosition()
final View view = recycler.getViewForPosition(mCurrentPosition);
mCurrentPosition += mItemDirection;
return view;
}
}
}
复制代码最终调用了Recycler.getViewForPosition()，Recycler是回收器的意思，感觉离想要找的“复用”逻辑越来越近了。 Recycler到底是做什么用的？ ：
public class RecyclerView {
/**
* A Recycler is responsible for managing scrapped or detached item views for reuse.
* Recycler负责管理scrapped和detached表项的复用
*/
public final class Recycler {
...
}
}
复制代码终于找到你~~ ，Recycler用于表项的复用！沿着Recycler.getViewForPosition()的调用链继续向下搜寻，找到了一个关键函数（函数太长了，为了防止头晕，只列出了关键节点）：
public class RecyclerView {
public final class Recycler {
/**
* Attempts to get the ViewHolder for the given position, either from the Recycler scrap,
* cache, the RecycledViewPool, or creating it directly.
* 尝试获得指定位置的ViewHolder，要么从scrap，cache，RecycledViewPool中获取，要么直接重新创建
*/
@Nullable
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
...
boolean fromScrapOrHiddenOrCache = false;
ViewHolder holder = null;
//0 从changed scrap集合中获取ViewHolder
if (mState.isPreLayout()) {
holder = getChangedScrapViewForPosition(position);
fromScrapOrHiddenOrCache = holder != null;
}
//1. 通过position从attach scrap或一级回收缓存中获取ViewHolder
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
...
}
if (holder == null) {
...
final int type = mAdapter.getItemViewType(offsetPosition);
//2. 通过id在attach scrap集合和一级回收缓存中查找viewHolder
if (mAdapter.hasStableIds()) {
holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),
type, dryRun);
...
}
//3. 从自定义缓存中获取ViewHolder
if (holder == null && mViewCacheExtension != null) {
// We are NOT sending the offsetPosition because LayoutManager does not
// know it.
final View view = mViewCacheExtension
.getViewForPositionAndType(this, position, type);
...
}
//4.从缓存池中拿ViewHolder
if (holder == null) { // fallback to pool
...
holder = getRecycledViewPool().getRecycledView(type);
...
}
//所有缓存都没有命中，只能创建ViewHolder
if (holder == null) {
...
holder = mAdapter.createViewHolder(RecyclerView.this, type);
...
}
}
boolean bound = false;
if (mState.isPreLayout() && holder.isBound()) {
// do not update unless we absolutely have to.
holder.mPreLayoutPosition = position;
}
//只有invalid的viewHolder才能绑定视图数据
else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) {
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
//获得ViewHolder后，绑定视图数据
bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs);
}
...
return holder;
}
}
}
复制代码- 函数的名字以“tryGet”开头，“尝试获得”表示可能获得失败，再结合注释中说的：“尝试获得指定位置的ViewHolder，要么从scrap，cache，RecycledViewPool中，要么直接重新创建。”猜测scrap，cache，RecycledViewPool是回收表项的容器，相当于表项缓存，如果缓存未命中则只能重新创建。
- 函数的返回值是
ViewHolder，难道回收和复用的是ViewHolder? 函数开头声明了局部变量ViewHolder holder = null;最终返回的也是这个局部变量，并且有4处holder == null的判断，这样的代码结构是不是有点像缓存？每次判空意味着上一级缓存未命中并继续尝试新的获取方法？缓存是不是有不止一种存储形式？ 让我们一次一次地看：
第一次尝试
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
...
if (mState.isPreLayout()) {
holder = getChangedScrapViewForPosition(position);
fromScrapOrHiddenOrCache = holder != null;
}
...
}
复制代码只有在mState.isPreLayout()为true时才会做这次尝试，这应该是一种特殊情况，先忽略。
第二次尝试
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
...
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
//下面一段代码蕴含着一个线索，买个伏笔，先把他略去
...
}
...
}
复制代码- 当第一次尝试失败后，尝试通过
getScrapOrHiddenOrCachedHolderForPosition()获得ViewHolder。 - 这里故意省略了一段代码，先埋个伏笔，待会分析。先沿着获取
ViewHolder的调用链继续往下：
//省略非关键代码
/**
* Returns a view for the position either from attach scrap, hidden children, or cache.
* 从attach scrap，hidden children或者cache中获得指定位置上的一个ViewHolder
*/
ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) {
final int scrapCount = mAttachedScrap.size();
// Try first for an exact, non-invalid match from scrap.
//1.在attached scrap中搜索ViewHolder
for (int i = 0; i < scrapCount; i++) {
final ViewHolder holder = mAttachedScrap.get(i);
if (!holder.wasReturnedFromScrap() && holder.getLayoutPosition() == position
&& !holder.isInvalid() && (mState.mInPreLayout || !holder.isRemoved())) {
holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP);
return holder;
}
}
//2.从移除屏幕的视图中搜索ViewHolder，找到了之后将他存入scrap回收集合中
if (!dryRun) {
View view = mChildHelper.findHiddenNonRemovedView(position);
if (view != null) {
final ViewHolder vh = getChildViewHolderInt(view);
mChildHelper.unhide(view);
int layoutIndex = mChildHelper.indexOfChild(view);
...
mChildHelper.detachViewFromParent(layoutIndex);
scrapView(view);
vh.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP
| ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST);
return vh;
}
}
// Search in our first-level recycled view cache.
//3.在缓存中搜索ViewHolder
final int cacheSize = mCachedViews.size();
for (int i = 0; i < cacheSize; i++) {
final ViewHolder holder = mCachedViews.get(i);
//若找到ViewHolder，还需要对ViewHolder的索引进行匹配判断
if (!holder.isInvalid() && holder.getLayoutPosition() == position) {
...
return holder;
}
}
return null;
}
复制代码依次从三个地方搜索ViewHolder：1. mAttachedScrap 2. 隐藏表项 3. mCachedViews，找到立即返回。
其中mAttachedScrap和mCachedViews作为Recycler的成员变量，用来存储一组ViewHolder：
public final class Recycler {
final ArrayList mAttachedScrap = new ArrayList<>();
...
final ArrayList mCachedViews = new ArrayList();
...
RecycledViewPool mRecyclerPool;
}
复制代码- 看到这里应该可以初步得出结论：RecyclerView回收机制中，回收复用的对象是
ViewHolder，且以ArrayList为结构存储在Recycler对象中。 RecycledViewPool mRecyclerPool;看着也像是回收容器，那待会是不是也会到这里拿ViewHolder?- 值得注意的是，当成功从
mCachedViews中获取ViewHolder对象后，还需要对其索引进行判断，这就意味着mCachedViews中缓存的ViewHolder只能复用于指定位置 ，打个比方：手指向上滑动，列表向下滚动，第2个表项移出屏幕，第4个表项移入屏幕，此时再滑回去，第2个表项再次出现，这个过程中第4个表项不能复用被回收的第2个表项的ViewHolder，因为他们的位置不同，而再次进入屏幕的第2个表项就可以成功复用。 待会可以对比一下其他复用是否也需要索引判断 - 回到刚才埋下的伏笔，把第二次尝试获取
ViewHolder的代码补全：
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
...
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
//下面一段代码蕴含这一个线索，买个伏笔，先把他略去
if (holder != null) {
//检验ViewHolder有效性
if (!validateViewHolderForOffsetPosition(holder)) {
// recycle holder (and unscrap if relevant) since it can not be used
if (!dryRun) {
// we would like to recycle this but need to make sure it is not used by
// animation logic etc.
holder.addFlags(ViewHolder.FLAG_INVALID);
if (holder.isScrap()) {
removeDetachedView(holder.itemView, false);
holder.unScrap();
} else if (holder.wasReturnedFromScrap()) {
holder.clearReturnedFromScrapFlag();
}
//若不满足有效性检验，则回收ViewHolder
recycleViewHolderInternal(holder);
}
holder = null;
} else {
fromScrapOrHiddenOrCache = true;
}
}
}
...
}
复制代码如果成功获得ViewHolder则检验其有效性，若检验失败则将其回收。好不容易获取了ViewHoler对象，一言不合就把他回收？难道对所有复用的 ViewHolder 都有这么严格的检验吗？ 暂时无法回答这些疑问，还是先把复用逻辑看完吧：
第三次尝试
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
...
//只有当Adapter设置了id，才会进行这次查找
if (mAdapter.hasStableIds()) {
holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),type, dryRun);
if (holder != null) {
// update position
holder.mPosition = offsetPosition;
fromScrapOrHiddenOrCache = true;
}
}
...
}
复制代码这一次尝试调用的函数名（“byId”）和上一次（“byPosition”）只是后缀不一样。上一次是通过表项位置，这一次是通过表项id。内部实现也几乎一样，判断的依据从表项位置变成表项id。为表项设置id属于特殊情况，先忽略。
作者：唐子玄
链接：https://juejin.cn/post/6844903778303344647
来源：掘金
