距离上一篇RecyclerView源码分析的文章已经过去了10多天，今天我们将来看看RecyclerView的动画机制。不过，本文不会分析ItemAnimator相关的知识，而是理解RecyclerView怎么执行ItemAnimator的，有关ItemAniamtor的知识，后面我会写专门的文章来分析。
本文参考资料：
注意，本文所有的代码都来自于27.1.1。
1. 概述
RecyclerView之所以受欢迎，有一部分的原因得归功于它的动画机制。我们可以通过RecyclerView的setItemAnimator方法来给每个Item设置在不同行为下，执行不同的动画，非常的简单。尽管我们知道怎么给RecyclerView设置动画，但是RecyclerView是怎么通过ItemAnimator来给每个Item实现动画，这里面的原理值得我们去研究和学习。
在正式分析RecyclerView的动画机制之前，我们先对几个词语有一个概念，我们来看看：
| 词语 | 含义 |
|---|---|
| Disappearance | 表示在动画之前，ItemView是可见的，动画之后就可不见了。这里的操作包括，remove操作和普通的滑动导致ItemView划出屏幕 |
| Appearance | 表示动画之前，ItemView是不可见，动画之后就可见了。这里的操作包括，add操作和普通的滑动导致ItemView划入屏幕 |
| Persistence | 表示动画前后，状态是不变的。这里面的操作包括，无任何操作 |
| change | 表示动画前后，状态是不变的。这里面的操作包括，change操作。 |
还有注意的一点就是，ViewHolder不是用来记录ItemView的位置信息，而是进行数据绑定的，所以在动画中，关于位置信息的记录不是依靠ViewHolder来实现的，而是依靠一个叫ItemHolderInfo的类实现的，在这个类里面，有四个成员变量，分别记录ItemView的left、top、right和bottom四个位置信息。
最后还需要注意一点就是，我们从RecyclerView的三大流程中可以得到，在RecyclerView的内部，dispatchLayout分为三步，其中dispathchLayoutStep1被称为预布局，在这里主要是保存ItemView的OldViewHolder,同时还会记录下每个ItemView在动画之前的位置信息;与之对应的dispathchLayoutStep3被称为后布局，主要结合真正布局和预布局的相关信息来实现进行动画，当然前提是RecyclerView本身支持动画。
本文打算从两个角度来分析RecyclerView的动画，一是从普通三大的流程来看，这是动画机制的核心所在；而是从Adapeter的角度上来看，看看我们每次在调用Adapter的notify相关方法之后，是怎么进行执行动画的(实际上也是回到三大流程里面)。
1. 再来看RecyclerView的三大流程
取这个题目，我感觉有特别的含义。首先，本次分析动画机制就是重新来看看三大流程，当然本次分三大流程肯定没有之前的那么仔细，其次侧重点也不同；其次，本次再来看RecyclerView的三大流程，还可以填之前在分析RecyclerView的三大流程留下的坑。
本次的分析重点在于dispathchLayoutStep1和dispathchLayoutStep3，不会分析完整的三大流程，所以，还有不懂RecyclerView三大流程的同学，可以参考我的文章:RecyclerView 源码分析(一) - RecyclerView的三大流程。
我们先来看看dispatchLayoutStep1方法：
private void dispatchLayoutStep1() {
// ······
if (mState.mRunSimpleAnimations) {
// Step 0: Find out where all non-removed items are, pre-layout
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;
}
final ItemHolderInfo animationInfo = mItemAnimator
.recordPreLayoutInformation(mState, holder,
ItemAnimator.buildAdapterChangeFlagsForAnimations(holder),
holder.getUnmodifiedPayloads());
mViewInfoStore.addToPreLayout(holder, animationInfo);
if (mState.mTrackOldChangeHolders && holder.isUpdated() && !holder.isRemoved()
&& !holder.shouldIgnore() && !holder.isInvalid()) {
long key = getChangedHolderKey(holder);
// This is NOT the only place where a ViewHolder is added to old change holders
// list. There is another case where:
// * A VH is currently hidden but not deleted
// * The hidden item is changed in the adapter
// * Layout manager decides to layout the item in the pre-Layout pass (step1)
// When this case is detected, RV will un-hide that view and add to the old
// change holders list.
mViewInfoStore.addToOldChangeHolders(key, holder);
}
}
}
if (mState.mRunPredictiveAnimations) {
// Step 1: run prelayout: This will use the old positions of items. The layout manager
// is expected to layout everything, even removed items (though not to add removed
// items back to the container). This gives the pre-layout position of APPEARING views
// which come into existence as part of the real layout.
// Save old positions so that LayoutManager can run its mapping logic.
saveOldPositions();
final boolean didStructureChange = mState.mStructureChanged;
mState.mStructureChanged = false;
// temporarily disable flag because we are asking for previous layout
mLayout.onLayoutChildren(mRecycler, mState);
mState.mStructureChanged = didStructureChange;
for (int i = 0; i < mChildHelper.getChildCount(); ++i) {
final View child = mChildHelper.getChildAt(i);
final ViewHolder viewHolder = getChildViewHolderInt(child);
if (viewHolder.shouldIgnore()) {
continue;
}
if (!mViewInfoStore.isInPreLayout(viewHolder)) {
int flags = ItemAnimator.buildAdapterChangeFlagsForAnimations(viewHolder);
boolean wasHidden = viewHolder
.hasAnyOfTheFlags(ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST);
if (!wasHidden) {
flags |= ItemAnimator.FLAG_APPEARED_IN_PRE_LAYOUT;
}
final ItemHolderInfo animationInfo = mItemAnimator.recordPreLayoutInformation(
mState, viewHolder, flags, viewHolder.getUnmodifiedPayloads());
if (wasHidden) {
recordAnimationInfoIfBouncedHiddenView(viewHolder, animationInfo);
} else {
mViewInfoStore.addToAppearedInPreLayoutHolders(viewHolder, animationInfo);
}
}
}
// we don't process disappearing list because they may re-appear in post layout pass.
clearOldPositions();
} else {
clearOldPositions();
}
onExitLayoutOrScroll();
stopInterceptRequestLayout(false);
mState.mLayoutStep = State.STEP_LAYOUT;
}
我将dispatchLayoutStep1方法分为2步(实际上从谷歌爸爸的注释，我们也可以得出来)。
- 找到每个没有被remove 掉的ItemView，将它的ViewHolder(OldViewHolder)放在
ViewInfoStore里面，同时还将它预布局的位置放在ViewInfoStore里面。这两个信息在后面做动画时都会用到。- 如果当前
RecyclerView的LayoutManager支持predictive item animations(supportsPredictiveItemAnimations方法返回true，我觉得用英语描述这种动画挺好的，因为我不知道怎么翻译)，会真正的进行预布局。在这一步，会先调用LayoutManager的onLayoutChildren进行一次布局，不过这次布局知识预布局，也就是说不是真正的布局，只是先确定每个ItemView的位置。预布局之后，此时取到的每个ItemView的ViewHolder和ItemHolderInfo，便是每个ItemView的最终信息。
第二步的信息与第一步的信息相互呼应，第一步是变化前的信息，第二步是变化后的信息。这些都是为dispatchLayout3阶段的动画做准备。其中，我们发现相对于第一步，第二步变得复杂了很多。不过，我们可以发现，不管怎么复杂，都是通过调用addToOldChangeHolders方法来保存当前ItemView的ViewHolder(在LayoutManager的onLayoutChildren方法前后，在同一个位置上，不一定是同一个ItemView,也不一定是同一个ViewHolder),然后调用addXXXLayout方法将位置信息(ItemHolderInfo)保存起来。
然后，我们再来看看dispatchLayoutStep3阶段:
private void dispatchLayoutStep3() {
mState.assertLayoutStep(State.STEP_ANIMATIONS);
startInterceptRequestLayout();
onEnterLayoutOrScroll();
mState.mLayoutStep = State.STEP_START;
// 将相关信息取到，然后添加到ViewInfoStore
if (mState.mRunSimpleAnimations) {
// Step 3: Find out where things are now, and process change animations.
// traverse list in reverse because we may call animateChange in the loop which may
// remove the target view holder.
for (int i = mChildHelper.getChildCount() - 1; i >= 0; i--) {
ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i));
if (holder.shouldIgnore()) {
continue;
}
long key = getChangedHolderKey(holder);
final ItemHolderInfo animationInfo = mItemAnimator
.recordPostLayoutInformation(mState, holder);
ViewHolder oldChangeViewHolder = mViewInfoStore.getFromOldChangeHolders(key);
if (oldChangeViewHolder != null && !oldChangeViewHolder.shouldIgnore()) {
// run a change animation
// If an Item is CHANGED but the updated version is disappearing, it creates
// a conflicting case.
// Since a view that is marked as disappearing is likely to be going out of
// bounds, we run a change animation. Both views will be cleaned automatically
// once their animations finish.
// On the other hand, if it is the same view holder instance, we run a
// disappearing animation instead because we are not going to rebind the updated
// VH unless it is enforced by the layout manager.
final boolean oldDisappearing = mViewInfoStore.isDisappearing(
oldChangeViewHolder);
final boolean newDisappearing = mViewInfoStore.isDisappearing(holder);
if (oldDisappearing && oldChangeViewHolder == holder) {
// run disappear animation instead of change
mViewInfoStore.addToPostLayout(holder, animationInfo);
} else {
final ItemHolderInfo preInfo = mViewInfoStore.popFromPreLayout(
oldChangeViewHolder);
// we add and remove so that any post info is merged.
mViewInfoStore.addToPostLayout(holder, animationInfo);
ItemHolderInfo postInfo = mViewInfoStore.popFromPostLayout(holder);
if (preInfo == null) {
handleMissingPreInfoForChangeError(key, holder, oldChangeViewHolder);
} else {
animateChange(oldChangeViewHolder, holder, preInfo, postInfo,
oldDisappearing, newDisappearing);
}
}
} else {
mViewInfoStore.addToPostLayout(holder, animationInfo);
}
}
// Step 4: Process view info lists and trigger animations
// 触发动画
mViewInfoStore.process(mViewInfoProcessCallback);
}
// 清理工作阶段
}
我将上面的代码分为3阶段。
- 获得相关的位置信息(ItemHolderInfo)，然后通过
addToPostLayout方法将位置保存在ViewInfoStore里面。- 调用
ViewInfoStore的process方法触发动画。- 进行相关的清理工作。
这里，我们重点关注前两步就行了。
其中第一步非常容易理解，先是获到当前ItemView的位置信息，保存在ViewInfoStore里面。其中，我们在这里发现，如果OldViewHolder不为空的话，会特别处理，为什么会这样处理的呢？其实这里考虑到change操作，因为change操作会涉及到两个ItemView的动画变化，所以，我们发现，如果一个ItemView调用的是animateChange方法进行动画开始，而不是走通用的逻辑(将位置信息通过addToPostLayout方法保存起来，然后调用process方法进行统一的调用)。
然后就是第二步。我们来看看ViewInfoStore的process方法,不过在我们在这方法之前，我们我们先看看ProcessCallback接口的几个方法。
| 方法 | 作用 |
|---|---|
| processDisappeared | 一个ItemView从可见到不可见会回调这个方法，主要是执行这种情况下的动画 |
| processAppeared | 一个ItemView从不可见到可见会回调这个方法。 |
| processPersistent | 一个ItemView动画前后状态为改变，这里面包括：本身未发生任何操作的ItemView、change操作的ItemView |
| unused | 一个ItemView的变化不支持动画会回调此方法，这里包括比如一个ItemView先是Appeared然后disappeared，这种情况RecyclerView找不到合适的动画；还有当前ItemView缺少preInfo，也就是在预布局未记录位置信息，也会调用此方法，这种情况经常是ItemView进行remove操作，但是Adapter调用的是notifyDataSetChanged方法 |
现在，我们正式的来看看process方法：
void process(ProcessCallback callback) {
for (int index = mLayoutHolderMap.size() - 1; index >= 0; index--) {
final ViewHolder viewHolder = mLayoutHolderMap.keyAt(index);
final InfoRecord record = mLayoutHolderMap.removeAt(index);
if ((record.flags & FLAG_APPEAR_AND_DISAPPEAR) == FLAG_APPEAR_AND_DISAPPEAR) {
// Appeared then disappeared. Not useful for animations.
callback.unused(viewHolder);
} else if ((record.flags & FLAG_DISAPPEARED) != 0) {
// Set as "disappeared" by the LayoutManager (addDisappearingView)
if (record.preInfo == null) {
// similar to appear disappear but happened between different layout passes.
// this can happen when the layout manager is using auto-measure
callback.unused(viewHolder);
} else {
callback.processDisappeared(viewHolder, record.preInfo, record.postInfo);
}
} else if ((record.flags & FLAG_APPEAR_PRE_AND_POST) == FLAG_APPEAR_PRE_AND_POST) {
// Appeared in the layout but not in the adapter (e.g. entered the viewport)
callback.processAppeared(viewHolder, record.preInfo, record.postInfo);
} else if ((record.flags & FLAG_PRE_AND_POST) == FLAG_PRE_AND_POST) {
// Persistent in both passes. Animate persistence
callback.processPersistent(viewHolder, record.preInfo, record.postInfo);
} else if ((record.flags & FLAG_PRE) != 0) {
// Was in pre-layout, never been added to post layout
callback.processDisappeared(viewHolder, record.preInfo, null);
} else if ((record.flags & FLAG_POST) != 0) {
// Was not in pre-layout, been added to post layout
callback.processAppeared(viewHolder, record.preInfo, record.postInfo);
} else if ((record.flags & FLAG_APPEAR) != 0) {
// Scrap view. RecyclerView will handle removing/recycling this.
} else if (DEBUG) {
throw new IllegalStateException("record without any reasonable flag combination:/");
}
InfoRecord.recycle(record);
}
}
其实process方法非常简单，就是通过相关的flag来调用ProcessCallback相关的方法。我们现在来同一个看看ProcessCallback的每个方法都怎么实现的。
private final ViewInfoStore.ProcessCallback mViewInfoProcessCallback =
new ViewInfoStore.ProcessCallback() {
@Override
public void processDisappeared(ViewHolder viewHolder, @NonNull ItemHolderInfo info,
@Nullable ItemHolderInfo postInfo) {
mRecycler.unscrapView(viewHolder);
animateDisappearance(viewHolder, info, postInfo);
}
@Override
public void processAppeared(ViewHolder viewHolder,
ItemHolderInfo preInfo, ItemHolderInfo info) {
animateAppearance(viewHolder, preInfo, info);
}
@Override
public void processPersistent(ViewHolder viewHolder,
@NonNull ItemHolderInfo preInfo, @NonNull ItemHolderInfo postInfo) {
viewHolder.setIsRecyclable(false);
if (mDataSetHasChangedAfterLayout) {
// since it was rebound, use change instead as we'll be mapping them from
// stable ids. If stable ids were false, we would not be running any
// animations
if (mItemAnimator.animateChange(viewHolder, viewHolder, preInfo,
postInfo)) {
postAnimationRunner();
}
} else if (mItemAnimator.animatePersistence(viewHolder, preInfo, postInfo)) {
postAnimationRunner();
}
}
@Override
public void unused(ViewHolder viewHolder) {
mLayout.removeAndRecycleView(viewHolder.itemView, mRecycler);
}
};
其实说到底，就是调用了animateXXX方法来实现，而animateXXX方法里面做了啥？其实没啥,就是调用了ViewCompat的postOnAnimation方法往任务队列后面post一个Runnable。代码如下：
void postAnimationRunner() {
if (!mPostedAnimatorRunner && mIsAttached) {
ViewCompat.postOnAnimation(this, mItemAnimatorRunner);
mPostedAnimatorRunner = true;
}
}
其中，上面的代码中，我们需要注意的是，postAnimationRunner每次只会被调用一次。那么如果在某一次操作中，会执行多个动画，怎么办呢？ProcessCallback每个回调方法都会调用animateXXX方法，而animateXXX方法会调用ItemAnimator对应的方法，在ItemAnimator里面，会将当前动画添加到一个数组里面，然后通过mItemAnimatorRunner调用ItemAnimator的runPendingAnimations方法，runPendingAnimations方法就是所有动画开始的起点。这里，我们就不讨论ItemAnimator内部的实现，后面有专门的文章来分析它。
2. 从Adapter角度来看动画执行的机制
我们知道，调用Adapter的notifyDataSetChanged方法，RecyclerView是不会执行动画的；而调用notifyItemRemoved之类的方法是有动画，这里我们从Adapter的角度来分析动画。跟ItemAnimator一样，这里我们也不会去分析Adapter,后面会有专门的文章分析它。
在分析Adapter之前，我们先来看一个东西，就是RecyclerView和Adapter怎么进行通信。
(1).通过观察者模式来实现RecyclerView 和Adapter的通信
我们思考这个问题之前，首先应该排除Addapter和RecyclerView是强耦合的，也就是说，Adapter内部持有一个RecyclerView对象。RecyclerView本身就是插拔式设计，如果Adapter和RecyclerView是强耦合，就违背了插拔式的设计思想。那么它俩究竟是怎么进行通信的呢？答案已经非常的明显了，两者是通过观察者模式来进行通信。
这其中，Adapter作为被观察者，RecyclerView作为观察者，当Adapter的数据发生改变时，会通知它的每个观察者。
RecyclerView本身设计又比较特殊，RecyclerView没有去实现Observer(这里暂且这么称呼)接口，而是内部持有一个Observer(RecyclerViewDataObserver)对象，进而监听Adapter的状态变化；当然Adapter也是如此，并没有去实现Observable接口，也是在内部持有一个Observable(AdapterDataObservable)对象。
我们来看Adapter的notify方法跟Observer的方法是怎么进行对应的。
| Adapter的notify方法 | 与之对应的Observer的方法 |
|---|---|
| notifyItemRemoved | notifyItemRangeRemoved |
| notifyItemChanged | notifyItemRangeChanged |
| notifyItemInserted | notifyItemRangeInserted |
| notifyItemMoved | notifyItemMoved |
调用到Observer的方法时，Observer会调用AdapterHelper相关的方法，在AdapterHelper内部会为每个操作创建一个UpdateOp对象,并且添加到一个PendingUpdate数组。我们来看看相关代码(以add为例)：
@Override
public void onItemRangeInserted(int positionStart, int itemCount) {
assertNotInLayoutOrScroll(null);
if (mAdapterHelper.onItemRangeInserted(positionStart, itemCount)) {
triggerUpdateProcessor();
}
}
如果onItemRangeInserted返回为true，就调用triggerUpdateProcessor方法。为什么这里需要判断是否调用triggerUpdateProcessor方法，其实是为了避免多次调用，比如一个操作，可能会导致多种动画执行，所以这里保证triggerUpdateProcessor方法只会被调用一次。
然后，我们来看看triggerUpdateProcessor方法：
void triggerUpdateProcessor() {
if (POST_UPDATES_ON_ANIMATION && mHasFixedSize && mIsAttached) {
ViewCompat.postOnAnimation(RecyclerView.this, mUpdateChildViewsRunnable);
} else {
mAdapterUpdateDuringMeasure = true;
requestLayout();
}
}
其实不管是if的执行语句，还是else里面，最终还是调用了requestLayout方法，重新走一遍三大流程。
可见而知，RecyclerView的三大流程到底多么重要。这次，我们看三大流程中的dispatchLayoutStep2方法。我们知道，在Observer阶段，每个操作其实都创建了一个UpdateOp对象，添加到PendingUpdate数组。那么数组里面的操作都是什么时候执行的呢？其实就是在dispatchLayoutStep2方法阶段：
private void dispatchLayoutStep2() {
// ······
mAdapterHelper.consumeUpdatesInOnePass();
// ······
}
真正执行PendingUpdate的操作是在AdapterHelper的consumeUpdatesInOnePass方法里面，我们来瞧瞧：
void consumeUpdatesInOnePass() {
// we still consume postponed updates (if there is) in case there was a pre-process call
// w/o a matching consumePostponedUpdates.
consumePostponedUpdates();
final int count = mPendingUpdates.size();
for (int i = 0; i < count; i++) {
UpdateOp op = mPendingUpdates.get(i);
switch (op.cmd) {
case UpdateOp.ADD:
mCallback.onDispatchSecondPass(op);
mCallback.offsetPositionsForAdd(op.positionStart, op.itemCount);
break;
case UpdateOp.REMOVE:
mCallback.onDispatchSecondPass(op);
mCallback.offsetPositionsForRemovingInvisible(op.positionStart, op.itemCount);
break;
case UpdateOp.UPDATE:
mCallback.onDispatchSecondPass(op);
mCallback.markViewHoldersUpdated(op.positionStart, op.itemCount, op.payload);
break;
case UpdateOp.MOVE:
mCallback.onDispatchSecondPass(op);
mCallback.offsetPositionsForMove(op.positionStart, op.itemCount);
break;
}
if (mOnItemProcessedCallback != null) {
mOnItemProcessedCallback.run();
}
}
recycleUpdateOpsAndClearList(mPendingUpdates);
mExistingUpdateTypes = 0;
}
虽然代码不少，但是我们发现了，最终的操作都是调用到了Callback接口里面了。而Callback做了什么呢？主要是做了两件事:
- 可能会更新一些ViewHolder的position
- 会更新一些ViewHolder的flag，比如说，remove的flag或者update的flag。
这部分的内容，我们后面分析Adapter会详细的分析，本文就不做过多的介绍了。
到这里，每个ViewHolder的position都更新完毕，并且每个ViewHolder的flag也已经更新完毕。这样，到了dispatchLayoutStep3阶段，就知道每个ViewHolder应该做什么动画。
然后，我们来看看为什么调用Adapter的notifyDataSetChanged方法不执行动画呢？
(2). 为什么notifyDataSetChanged方法不会执行动画呢？
notifyDataSetChanged方法会回调到Observer的notifyChanged方法里面，我们看看notifyChanged方法干什么：
@Override
public void onChanged() {
assertNotInLayoutOrScroll(null);
mState.mStructureChanged = true;
processDataSetCompletelyChanged(true);
if (!mAdapterHelper.hasPendingUpdates()) {
requestLayout();
}
}
在这个方法里面，我们需要特别关注processDataSetCompletelyChanged方法。我们来看看：
void processDataSetCompletelyChanged(boolean dispatchItemsChanged) {
mDispatchItemsChangedEvent |= dispatchItemsChanged;
mDataSetHasChangedAfterLayout = true;
markKnownViewsInvalid();
}
在processDataSetCompletelyChanged方法里面，调用了markKnownViewsInvalid方法所有的ViewHolder标记为了FLAG_INVALID。这个操作直接导致了，我们在预布局阶段不能正确获得每个ItemView的位置信息和OldViewHolder,进而导致在后布局阶段不能执行动画。这就是notifyDataSetChanged方法为什么不执行动画的原因。
3. 总结
RecyclerView的动画机制还是比较简单的，这里我们对它做一个简单的总结。
RecyclerView执行动画的机制在于，在预布局阶段将每个ItemView的位置信息和ViewHolder保存起来，在后布局阶段，根据每个ItemView的ViewHolderflag状态来判断执行什么动画，根据位置信息来判断怎么做动画。- Adapter的notify方法之所以能够执行动画，是因为他们在三大流程中给每个
ViewHolder打了响应的flag,包括remove的flag或者update的flag等。而在后布局中，正是根据flag来执行不同的动画的。notifyDataSetChanged方法之所以不支持动画，那是因为notifyDataSetChanged方法会使每个ViewHolder失效(打了FLAG_INVALID标记)，所以导致在预布局阶段，不能正确的获得每个ItemView的位置信息和ViewHolder，进而导致动画不能执行。
如果不出意外的话，下一篇文章将分析Adapter
