读源码涨知识---RecyclerView-预布局-，后布局与-scrap-缓存的关系(1)

最新推荐文章于 2024-07-12 22:23:43 发布

2401_84010744

最新推荐文章于 2024-07-12 22:23:43 发布

阅读量310

点赞数 5

分类专栏：程序员文章标签：缓存前端数据库

本文链接：https://blog.csdn.net/2401_84010744/article/details/138706226

版权

程序员专栏收录该内容

234 篇文章 2 订阅

订阅专栏

RecyclerView 为了做表项动画，对表项做了 2 次布局，第一次叫预布局pre-layout，第二次叫后布局post-layout。上一篇分析了“预布局的生命周期及其布局过程中填充了哪些表项？”。仍遗留了一些疑问，比如“2 次布局为何能互不影响？”，“如何优化 2 次布局的时间性能？”。这一篇继续以走读源码 + 断点调试的方式给出答案。

引子

这一篇的源码分析还是基于下面这个 Demo 场景：

列表中有两个表项（1、2），删除 2，此时 3 会从屏幕底部平滑地移入并占据原来 2 的位置。

为了实现该效果，RecyclerView的策略是：为动画前的表项先执行一次pre-layout，将不可见的表项 3 也加载到布局中，形成一张布局快照（1、2、3）。再为动画后的表项执行一次post-layout，同样形成一张布局快照（1、3）。比对两张快照中表项 3 的位置，就知道它该如何做动画了。

再此援引上一篇已经得出的结论：

RecyclerView为了实现表项动画，进行了 2 次布局（预布局 + 后布局），在源码上表现为LayoutManager.onLayoutChildren()被调用 2 次。

预布局的过程始于RecyclerView.dispatchLayoutStep1()，终于RecyclerView.dispatchLayoutStep2()。

在预布局阶段，循环填充表项时，若遇到被移除的表项，则会忽略它占用的空间，多余空间被用来加载额外的表项，这些表项在屏幕之外，本来不会被加载。

其中第三点表现在源码上，是这样的：

public class LinearLayoutManager {
// 布局表项
public void onLayoutChildren() {
// 不断填充表项
fill() {
while(列表有剩余空间){
// 填充单个表项
layoutChunk(){
// 让表项成为子视图
addView(view)
}
if (表项没有被移除) {
剩余空间 -= 表项占用空间
}
…
}
}
}
}

这是RecyclerView填充表项的伪码。以 Demo 为例，预布局阶段，第一次执行onLayoutChildren()，因表项 2 被删除，所以它占用的空间不会被扣除，导致while循环多执行一次，这样表项 3 就被填充进列表。

后布局阶段，会再次执行onLayoutChildren()，再把表项 1、3 填入列表。那此时列表中不是得有两个表项 1，两个表项 3，和一个表项 2 吗？

这显然是不可能的，用上一篇介绍的断点调试，运行 Demo，把断点断在addView()，发现后布局阶段再次调用该方法时，RecyclerView的子控件个数为 0。

先清空表项再填充

难道每次布局之前都会删掉现有布局中所有的表项？

从fill()开始，往上走查代码，果然发现了一个线索：

public class LinearLayoutManager {
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
…
// detach 并 scrap 表项
detachAndScrapAttachedViews(recycler);
…
// 填充表项
fill()
}

在填充表项之前，有一个 detach 操作：

public class RecyclerView {
public abstract static class LayoutManager {
public void detachAndScrapAttachedViews(@NonNull Recycler recycler) {
// 遍历所有子表项
final int childCount = getChildCount();
for (int i = childCount - 1; i >= 0; i–) {
final View v = getChildAt(i);
// 回收子表项
scrapOrRecycleView(recycler, i, v);
}
}
}
}

果不其然，在填充表项之前会遍历所有子表项，并逐个回收它们：

public class RecyclerView {
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);
} else {
// detach 表项
detachViewAt(index);
// scrap 表项
recycler.scrapView(view);
…
}
}
}
}

回收表项时，根据viewHolder的不同状态执行不同分支。硬看源码很难快速判断会走哪个分支，果断运行 Demo，断点调试一把。在上述场景中，所有表项都走了第二个分支，即在布局表项之前，对现有表项做了两个关键的操作：

detach 表项detachViewAt(index)
scrap 表项recycler.scrapView(view)

detach 表项

先看看 detach 表项是个什么操作：

public class RecyclerView {
public abstract static class LayoutManager {
ChildHelper mChildHelper;
// detach 指定索引的表项
public void detachViewAt(int index) {
detachViewInternal(index, getChildAt(index));
}

// detach 指定索引的表项
private void detachViewInternal(int index, @NonNull View view) {
…
// 将 detach 委托给 ChildHelper
mChildHelper.detachViewFromParent(index);
}
}
}

// RecyclerView 子表项管理类
class ChildHelper {
// 将指定位置的表项从 RecyclerView detach
void detachViewFromParent(int index) {
final int offset = getOffset(index);
mBucket.remove(offset);
// 最终实现 detach 操作的回调
mCallback.detachViewFromParent(offset);
}
}

LayoutManager会将 detach 任务委托给ChildHelper，ChildHelper再执行detachViewFromParent()回调，它在初始化ChildHelper时被实现：

public class RecyclerView {
// 初始化 ChildHelper
private void initChildrenHelper() {
// 构建 ChildHelper 实例
mChildHelper = new ChildHelper(new ChildHelper.Callback() {
@Override
public void detachViewFromParent(int offset) {
final View view = getChildAt(offset);
…
// 调用 ViewGroup.detachViewFromParent()
RecyclerView.this.detachViewFromParent(offset);
}
…
}
}
}

RecyclerView detach 表项的最后一步调用了ViewGroup.detachViewFromParent()：

public abstract class ViewGroup {
// detach 子控件
protected void detachViewFromParent(int index) {
removeFromArray(index);
}

// 删除子控件的最后一步
private void removeFromArray(int index) {
final View[] children = mChildren;
// 将子控件持有的父控件引用置空
if (!(mTransitioningViews != null && mTransitioningViews.contains(children[index]))) {
children[index].mParent = null;
}
final int count = mChildrenCount;
// 将父控件持有的子控件引用置空
if (index == count - 1) {
children[–mChildrenCount] = null;
} else if (index >= 0 && index < count) {
System.arraycopy(children, index + 1, children, index, count - index - 1);
children[–mChildrenCount] = null;
}
…
}
}

ViewGroup.removeFromArray()是容器控件移除子控件的最后一步（ViewGroup.removeView()也会调用这个方法）。

至此可以得出结论：

在每次向RecyclerView填充表项之前都会先清空现存表项。

目前看来，detach view和remove view差不多，它们都会将子控件从父控件的孩子列表中删除，唯一的区别是detach更轻量，不会触发重绘。而且detach是短暂的，被detach的 View 最终必须被彻底 remove 或者重新 attach。（下面就会马上把他们重新 attach）

scrap 表项

scrap 表项的意思是回收表项并将其存入mAttachedScrap列表，它是回收器Recycler中的成员变量：

public class RecyclerView {
public final class Recycler {
// scrap 列表
final ArrayList mAttachedScrap = new ArrayList<>();
}
}

mAttachedScrap是一个 ArrayList 结构，用于存储ViewHolder实例。

RecyclerView 填充表项前，除了会 detach 所有可见表项外，还会同时 scrap 它们：

scrapView()是回收器Recycler的方法，正是这个方法将表项回收到了mAttachedScrap列表中：

public class RecyclerView {
public final class Recycler {
void scrapView(View view) {
final ViewHolder holder = getChildViewHolderInt(view);
// 表项不需要更新，或被移除，或者表项索引无效时，将被会收到 mAttachedScrap
if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID)
|| !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) {
holder.setScrapContainer(this, false);
// 将表项回收到 mAttachedScrap 结构中
mAttachedScrap.add(holder);
} else {
// 只有当表项没有被移除且有效且需要更新时才会被回收到 mChangedScrap
if (mChangedScrap == null) {
mChangedScrap = new ArrayList();
}
holder.setScrapContainer(this, true);
mChangedScrap.add(holder);
}
}
}
}

scrapView()中根据ViewHolder状态将其会收到不同的结构中，同样地，硬看源码很难快速判断执行了那个分支，继续断点调试，Demo 场景中所有的表项都会被回收到mAttachedScrap结构中。（关于 mAttachedScrap 和 mChangedScrap 的区别会在后续文章分析）

分析至此，进一步细化刚才得到的结论：

在每次向RecyclerView填充表项之前都会先清空 LayoutManager 中现存表项，将它们 detach 并同时缓存入 mAttachedScrap列表中。

将结论应用在 Demo 的场景，即是：RecyclerView 在预布局阶段准备向列表中填充表项前，会清空现有的表项 1、2，把它们都 detach 并回收对应的 ViewHolder 到 mAttachedScrap列表中。

从缓存拿填充表项

预布局与 scrap 缓存的关系

缓存定是为了复用，啥时候用呢？紧接着的“填充表项”中就立马会用到：

public class LinearLayoutManager {
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
…
// detach 表项
detachAndScrapAttachedViews(recycler);
…
// 填充表项
fill()
}

int fill(RecyclerView.Recycler recycler, LayoutState layoutState,RecyclerView.State state, boolean stopOnFocusable) {
// 计算剩余空间
int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace;
// 不停的往列表中填充表项，直到没有剩余空间
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
// 填充单个表项
layoutChunk(recycler, state, layoutState, layoutChunkResult);
…
}
}

// 填充单个表项
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) {
// 获取下一个被填充的视图
View view = layoutState.next(recycler);
…
// 填充视图
addView(view);
…
}
}

填充表项时，通过layoutState.next(recycler)获取下一个该被填充的表项视图：

public class LinearLayoutManager {
static class LayoutState {
View next(RecyclerView.Recycler recycler) {
…
// 委托 Recycler 获取下一个该填充的表项
final View view = recycler.getViewForPosition(mCurrentPosition);
…
return view;
}
}
}

public class RecyclerView {
public final class Recycler {
public View getViewForPosition(int position) {
return getViewForPosition(position, false);
}
}

View getViewForPosition(int position, boolean dryRun) {
// 调用链最终传递到 tryGetViewHolderForPositionByDeadline()
return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView;
}
}

沿着调用链一直往下，最终走到了Recycler.tryGetViewHolderForPositionByDeadline()，在RecyclerView缓存机制（咋复用？）中对其做过详细介绍，援引结论如下：

在 RecyclerView 中，并不是每次绘制表项，都会重新创建 ViewHolder 对象，也不是每次都会重新绑定 ViewHolder 数据。
RecyclerView 填充表项前，会通过Recycler获取表项的 ViewHolder 实例。
Recycler在tryGetViewHolderForPositionByDeadline()方法中，前后尝试 5 次，从不同缓存中获取可复用的 ViewHolder 实例，其中第一优先级的缓存即是scrap结构。
从scrap缓存获取的表项不需要重新构建，也不需要重新绑定数据。

从 scrap 结构获取 ViewHolder 的源码如下：

public class RecyclerView {
public final class Recycler {
ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) {
ViewHolder holder = null;
…
// 从 scrap 结构中获取指定 position 的 ViewHolder 实例
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
…

最后

目前已经更新的部分资料：

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
ViewHolder 实例
if (holder == null) {
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
…

最后

目前已经更新的部分资料：

[外链图片转存中…(img-d43Uidse-1715396064325)]
[外链图片转存中…(img-TxmDeNuf-1715396064326)]
[外链图片转存中…(img-cuYuWpwl-1715396064327)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！

2401_84010744

关注

5
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
读源码涨知识---RecyclerView-预布局-，后布局与-scrap-缓存的关系(1)

目前已经更新的部分资料：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门，即可获取！ViewHolder 实例[外链图片转存中…(img-d43Uidse-1715396064325)][外链图片转存中…(img-TxmDeNuf-1715396064326)][外链图片转存中…(img-cuYuWpwl-1715396064327)]《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门，即可获取！
复制链接

扫一扫