上一篇我们针对RecyclerView的绘制流程做了简单的分析,重点放在了dispatchLayoutStep2()这个真正对子View操作的函数上,它完成了:子View的添加(LinearLayoutManager通过ChildHelper添加)、测量、布局。
绘制流程虽然有了大概的了解,但却引出了很多问题:dispatchLayoutStep1()和dispatchLayoutStep3()有什么作用?ChildHelper如何管理子View?动画怎么产生?Recycler如何回收和提供ViewHolder?等等等等。
Recycler的问题这一篇依旧不讲(实在解耦得太好了以至于可以随时单独拿出来讲),我们下面着重来看一下数据变动下View的动画到底是如何产生的,顺带对上面的一些问题作出分析。
在网上看了好几篇博客都看得云里雾里,后来索性找到了参与编写RecyclerView的工程师写的解释RV动画的博客才梳理通了整个流程,大家可以直接去看原博客,我在跟源码的过程中会把对博客的理解写出来。
首先说明几个类。
AdapterHelper
这个类的介绍是Helper class that can enqueue and process adapter update operations,可以入列和执行adapter的更新操作,个人理解是AdapterHelper托管了Adapter的数据更新操作,即Adapter中Datas改变后调用的notifyItemXXX()都是由AdapterHelper来执行的,而且这个数据的变化到界面上的变化这之间是经历一个onLayout的,AdapterHelper将Adapter的操作记录为一个对象(UpdateOp),并且操作的结果映射在VH的position上,并通过onLayout的过程显示出来。重要的地方注释了, 还有很多方法没有列出来,到具体用到的时候再说。
class AdapterHelper implements OpReorderer.Callback {
//一些数据结构保存UpdateOp
private Pools.Pool mUpdateOpPool = new Pools.SimplePool(UpdateOp.POOL_SIZE);
final ArrayList mPendingUpdates = new ArrayList();
final ArrayList mPostponedList = new ArrayList();
final Callback mCallback;
Runnable mOnItemProcessedCallback;
final boolean mDisableRecycler;
//一个可以实现UpdateOp排序的类,似乎是因为对数据集的操作有优先级
final OpReorderer mOpReorderer;
private int mExistingUpdateTypes = 0;
AdapterHelper(Callback callback) {
this(callback, false);
}
//在RecyclerView初始化的时候我们新建了一个AdapterHelper,并且传入了一个实现了这个Callback的匿名内部类作为AdapterHelper和RV通信手段
AdapterHelper(Callback callback, boolean disableRecycler) {
mCallback = callback;
mDisableRecycler = disableRecycler;
mOpReorderer = new OpReorderer(this);
}
AdapterHelper addUpdateOp(UpdateOp... ops) {
Collections.addAll(mPendingUpdates, ops);
return this;
}
//封装各种操作
static class UpdateOp {
static final int ADD = 1;
static final int REMOVE = 1 << 1;
static final int UPDATE = 1 << 2;
static final int MOVE = 1 << 3;
static final int POOL_SIZE = 30;
int cmd;
int positionStart;
Object payload;
// holds the target position if this is a MOVE
int itemCount;
UpdateOp(int cmd, int positionStart, int itemCount, Object payload) {
this.cmd = cmd;
this.positionStart = positionStart;
this.itemCount = itemCount;
this.payload = payload;
}
...
}
....
//和RecyclerView通信的接口
static interface Callback {
...
}
}
ChildHelper
类的介绍是它是一个帮助RV管理child的类,一切和View的操作都被它承包了,就像上面AdapterHelper“拦截”了所有Adapter的操作一样。对于理解这个类我们需要知道一个非常重要的概念,就是它可以”hide”一些View,具体一点来说,它提供了两套API,分别用于操作所有的View和可见的View(指没有被hide)。像getChildAt, getChildCount这类正常的接口返回的是可见的View,而如果RV想对VG(ViewGroup)中所有的View进行访问,需要用“unfiltered”这样前缀的方法,比如getUnfilteredChildCount。这两套方法是针对LM(LayoutManager)的,并帮助动画的产生,这个后面再说。那么落地到这种功能如何实现的,就和其内部的成员有关。其中一个成员是mBucket,Bucket是一个Map,key是View,value是true/false(表示View是否特殊),另一个是mHiddenViews,这是一个保存了所有不可见的View的List。
class ChildHelper {
private static final boolean DEBUG = false;
private static final String TAG = "ChildrenHelper";
final Callback mCallback;
final Bucket mBucket;
final List mHiddenViews;
ChildHelper(Callback callback) {
mCallback = callback;
mBucket = new Bucket();
mHiddenViews = new ArrayList();
/**
* Returns the number of children that are not hidden.
*
* @return Number of children that are not hidden.
* @see #getChildAt(int)
*/
int getChildCount() {
return mCallback.getChildCount() - mHiddenViews.size();
}
/**
* Returns the total number of children.
*
* @return The total number of children including the hidden views.
* @see #getUnfilteredChildAt(int)
*/
int getUnfilteredChildCount() {
return mCallback.getChildCount();
}
boolean isHidden(View view) {
return mHiddenViews.contains(view);
}
...
/**
* Bitset implementation that provides methods to offset indices.
*/
static class Bucket {
final static int BITS_PER_WORD = Long.SIZE;
final static long LAST_BIT = 1L << (Long.SIZE - 1);
long mData = 0;
Bucket next;
void set(int index) {
if (index >= BITS_PER_WORD) {
ensureNext();
next.set(index - BITS_PER_WORD);
} else {
mData |= 1L << index;
}
}
boolean get(int index) {
if (index >= BITS_PER_WORD) {
ensureNext();
return next.get(index - BITS_PER_WORD);
} else {
return (mData & (1L << index)) != 0;
}
}
...
}
//和RV通信的接口
static interface Callback {
...
}
}
我们从Adapter#notifyItemRemoved()说起,如果我们添加了动画,这个方法会使动画效果显现出来,动画和dispatchLayoutStep1()还有dispatchLayoutStep3()相关,所以我们跟进一下这个方法。Adapter作为Observable,最终调用到了Observer的onItemRangeRemoved()。
//RecyclerViewDataObserver.java
//是RV的一个内部类
@Override
public void onItemRangeRemoved(int positionStart, int itemCount) {
assertNotInLayoutOrScroll(null);
//添加UpdateOp
if (mAdapterHelper.onItemRangeRemoved(positionStart, itemCount)) {
//申请重绘
triggerUpdateProcessor();
}
}
把REMOVE的UpdateOp添加到mPendingUpdates。
//AdapterHelper.java
boolean onItemRangeRemoved(int positionStart, int itemCount) {
mPendingUpdates.add(obtainUpdateOp(UpdateOp.REMOVE, positionStart, itemCount, null));
mExistingUpdateTypes |= UpdateOp.REMOVE;
return mPendingUpdates.size() == 1;
}
这里分享一个小技巧,我们在debug的时候可以使用条件断点,我设置的是点击按钮删除一个RV上的条目后条件成立停在onLayout(),这样方便于观察requestLayout()之后的layout发生了什么。
之后便会进入onLayout()
void dispatchLayout() {
...
if (mState.mLayoutStep == State.STEP_START) {
dispatchLayoutStep1();
...
dispatchLayoutStep2();
}
...
dispatchLayoutStep3();
...
}
这个方法一开始会调用mViewInfoStore.clear(),我们同样还是先来看一下ViewInfoStore这个模块。
ViewInfoStore
对这个类的注释是Keeps data about views to be used for animations,记录了view的一些数据以用来做动画。我们还是以注释的方式对重要的部分说明。总的来说,这个类会保存VH的InfoRecord,而InfoRecord中比较重要的成员是VH的prelayout后和postlayout后的itemView边界信息ItemHolderInfo。
class ViewInfoStore {
//可以看到这里用了两个数据结构存储了VH的信息,key是VH,value是InfoRecord
@VisibleForTesting
final ArrayMap mLayoutHolderMap = new ArrayMap<>();
@VisibleForTesting
final LongSparseArray mOldChangedHolders = new LongSparseArray<>();
...
//ViewInfoStore的静态内部类
static class InfoRecord {
// disappearing list 正在消失
static final int FLAG_DISAPPEARED = 1;
// appear in pre layout list 在prelayout出现
static final int FLAG_APPEAR = 1 << 1;
// pre layout, this is necessary to distinguish null item info
static final int FLAG_PRE = 1 << 2;
// post layout, this is necessary to distinguish null item info
static final int FLAG_POST = 1 << 3;
static final int FLAG_APPEAR_AND_DISAPPEAR = FLAG_APPEAR | FLAG_DISAPPEARED;
static final int FLAG_PRE_AND_POST = FLAG_PRE | FLAG_POST;
static final int FLAG_APPEAR_PRE_AND_POST = FLAG_APPEAR | FLAG_PRE | FLAG_POST;
int flags;
//VH的itemview的边界信息
@Nullable ItemHolderInfo preInfo;
@Nullable ItemHolderInfo postInfo;
static Pools.Pool sPool = new Pools.SimplePool<>(20);
...
}
...
}
//ItemAnimator.java
public static class ItemHolderInfo {
public int left;
public int top;
public int right;
public int bottom;
@AdapterChanges
public int changeFlags;
...
public ItemHolderInfo setFrom(RecyclerView.ViewHolder holder,
@AdapterChanges int flags) {
final View view = holder.itemView;
this.left = view.getLeft();
this.top = view.getTop();
this.right = view.getRight();
this.bottom = view.getBottom();
return this;
}
...
}
接下来我们继续看,以remove为例,dispatchLayoutStep1()也就是prelayout总体上做了这么几件事:
1.重排序所有UpdateOp。
2.依次执行所有UpdateOp事件,更新VH的position,如果VH被remove了标记它。
3.mViewInfoStore记录所有“可见的”的View的位置信息
4.用旧信息执行prelayout。
更具体的注释标注在了对应的方法(块)上面,大家可以进入方法对应查看,我就不把方法再具体拿出来了。总而言之,prelayout阶段RV把应该告诉LM的更新操作映射到了VH的mPreLayoutPosition上,LM根据mPreLayoutPosition进行布局,View的信息也被保存了一次。我们要记住既布局了旧信息,也布局了变化量(指的是因为更新而造成的新添加的View)
private void dispatchLayoutStep1() {
...
//1.重排序所有UpdateOp,比如move操作会排到末尾
//2.依次执行所有UpdateOp事件,更新VH的position(这里是前移mPosition,mPreLayoutPosition不变),如果VH被remove了标记它。
/*在2中,“会决定是否在prelayout之前把更新告诉LM”,
这里把更新告诉LM指的是把更新反应在VH的mPreposition上(VH中有mPosition、mPreLayoutPosition等成员,注意,prelayout中是使用的mPreLayoutPosition)mPosition是一定会更新的,mPreLayoutPosition则不一定。
如果RV决定不把更新再prelayout之前告诉LM,则会对VH更新时的参数applyToPreLayout传入false,mPosition更新了而mPreLayoutPosition则是旧值,反之mPreLayoutPosition则和mPosition同步。
当然,如何“决定”我们就不说了,有兴趣可以看下原文和源码。*/
processAdapterUpdatesAndSetAnimationFlags();
...
//这里最大最小position就是用的mPrelayoutPosition
findMinMaxChildLayoutPositions(mMinMaxLayoutPositions);
if (mState.mRunSimpleAnimations) {
//注意这里获取的是可见的View
int count = mChildHelper.getChildCount();
for (int i = 0; i < count; ++i) {
final ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i));
if (holder.shouldIgnore() || (holder.isInvalid() && !mAdapter.hasStableIds())) {
continue;
}
//3.(Adapter的更新操作有选择地反应到mPreLayoutPosition之后),mViewInfoStore记录所有“可见的”的View的位置信息
final ItemHolderInfo animationInfo = mItemAnimator
.recordPreLayoutInformation(mState, holder,
ItemAnimator.buildAdapterChangeFlagsForAnimations(holder),
holder.getUnmodifiedPayloads());
mViewInfoStore.addToPreLayout(holder, animationInfo);
...
}
}
if (mState.mRunPredictiveAnimations) {
//4.用旧信息执行prelayout(即使被removed也布局),并且布局因为remove而新出现的item。(这里的旧信息应该就是mPreLayoutPosition,而具体的实现是在确定最大最小position的时候以及确定Anchor的时候都是用的mPreLayoutPosition,大家可以单步进去来看)。
mLayout.onLayoutChildren(mRecycler, mState);
...
}
接下来我们对比看一下dispatchLayoutStep2()也就是postlayout过程,主要做了下面几件事:
5.RV把剩余的更新操作映射到VH上
6.执行postlayout操作
private void dispatchLayoutStep2() {
//5.RV把剩余的更新操作映射给VH
mAdapterHelper.consumeUpdatesInOnePass();
//6.执行postlayout(这里 似乎 是用了VH的mPosition,因为Anchor的布局位置被更新到0了),执行完毕后,RV中的内容和Adapter中的内容同步。
//还要说一句的是这个方法的最后部分有一个layoutForPredictiveAnimations(),对于add更新是有用的,因为我们在布局前会先detach所有View,如果是add产生的变化,在postlayout中会有view超出了layout的position范围而没有被layout,只存在于scrap列表中,我们这时候也要在显示区外layout出来,以产生正确的动画。
mLayout.onLayoutChildren(mRecycler, mState);
....
}
第一次布局(prelayout)和第二次布局(postlayout)过后,就可以开始执行动画相关的操作了,dispatchLayoutStep3()主要做了这么几件事:
7.mItemAnimator记录postlayout过后所有“可见的”View的信息。
8.确定VH的类型。
9.执行相应动画。
10.执行完动画后做一些回收工作。
private void dispatchLayoutStep3() {
if (mState.mRunSimpleAnimations) {
int count = mChildHelper.getChildCount();
for (int i = 0; i < count; ++i) {
long key = getChangedHolderKey(holder);
//7. mItemAnimator记录postlayout过后所有“可见的”View的信息。
final ItemHolderInfo animationInfo = mItemAnimator
.recordPostLayoutInformation(mState, holder);
ViewHolder oldChangeViewHolder = mViewInfoStore.getFromOldChangeHolders(key);
}
//8.确定VH的类型。
//9.执行相应动画。
mViewInfoStore.process(mViewInfoProcessCallback);
}
//10.执行完动画后做一些回收工作。
mLayout.removeAndRecycleScrapInt(mRecycler);
....
}
整个数据变动到动画产生的过程算是梳理清楚了,当然我现在水平还不够深入每一个细节去解释,动画的执行我也无意去深究。
总的来说(对于remove),在进入prelayout阶段之前,RV会决定是否将更新(UpdateOp)映射给VH,具体来说是VH的mPreLayoutPosition。prelayout阶段根据VH的mPreLayoutPosition确定锚点和最大最小位置后进行布局并多布局一个View,保存View的信息用作动画。postlayout阶段根据VH的mPosition布局,布局完之后数据和Adapter中同步。最后记录postlayout后的View信息并进行动画。
其实最大的收获是清楚了LayoutTransition和这里RV的Animation的区别,RV对remove和add都会进行“预处理”,以防item产生错误的动画,比如remove的时候view仅仅是“保持和移动”而并不是fade in。
下一篇我们来看一下VH从哪来以及到哪去——Recycler的作用,顺带把滑动也过一遍。