之前为了开发需求，学习了NestedScrolling机制，并使用CoordinatorLayout、AppBarLayout、RecyclerView配合实现了相关的效果，还写了一篇关于分析原理的文章关于CoordinatorLayout AppBarLayout原理的一些分析,当时做完需求以后，内心其实是一只有种遗憾的，因为在使用RecyclerView时，对于向上滑动的fling效果其实是有问题的，滑动起来的感觉并不是连贯的，可以看一下这个效果：
这个效果的体验其实并不是太好，因为向下fling时我们希望的效果是父布局可以在RecyclerView到达顶部时，如果没有消耗完fling时可以由父布局消耗从而继续滑动的，可是由于之前的实现方式，并没有办法用常规的办法达到这一点，Google也意识到了这个问题，所以在Android 8.0 扩展了NestedScrolling的相关接口，使得滑动可以变得更加顺畅了，效果如下，简直如丝般顺滑：
在分析相关的原理之前，如果你们急需解决项目中的这种滑动不顺畅，可以先把解决方法告诉大家，那就是把compileSdkVersion升到26然后使用26.1.0的相关控件
apply plugin: 'com.android.application'
android {
compileSdkVersion 26
buildToolsVersion '26.0.2'
.......
}
dependencies {
....
compile 'com.android.support:recyclerview-v7:26.1.0'
compile 'com.android.support:support-v4:26+'
compile 'com.android.support:design:26.1.0'
.....
}
这样改好之后，不需要改动一行代码，即可完美实现如丝般顺滑的fling。
问题发生的原因
RecyclerView中，fling的调用发生在滑动事件MotionEvent.ACTION_UP时，在25+版本之前RecycleView只是在fling的开始之前通知了Parent是否消耗fling以及将fling分发到parent，这只能做到Parent和RecyclerView同时fling或者Parent自己fling,在RecyclerView的fling过程中并没有通知Parent，在RecyclerView fling结束之后，Parent不能拿到剩余未消耗的距离，所以导致了这个不能连贯滑动的问题，25+版本的RecyclerView的fling方法如下：
public boolean fling(int velocityX, int velocityY) {
if (mLayout == null) {
Log.e(TAG, "Cannot fling without a LayoutManager set. " +
"Call setLayoutManager with a non-null argument.");
return false;
}
if (mLayoutFrozen) {
return false;
}
final boolean canScrollHorizontal = mLayout.canScrollHorizontally();
final boolean canScrollVertical = mLayout.canScrollVertically();
if (!canScrollHorizontal || Math.abs(velocityX) < mMinFlingVelocity) {
velocityX = 0;
}
if (!canScrollVertical || Math.abs(velocityY) < mMinFlingVelocity) {
velocityY = 0;
}
if (velocityX == 0 && velocityY == 0) {
// If we don't have any velocity, return false
return false;
}
if (!dispatchNestedPreFling(velocityX, velocityY)) {
final boolean canScroll = canScrollHorizontal || canScrollVertical;
dispatchNestedFling(velocityX, velocityY, canScroll);
if (mOnFlingListener != null && mOnFlingListener.onFling(velocityX, velocityY)) {
return true;
}
if (canScroll) {
velocityX = Math.max(-mMaxFlingVelocity, Math.min(velocityX, mMaxFlingVelocity));
velocityY = Math.max(-mMaxFlingVelocity, Math.min(velocityY, mMaxFlingVelocity));
mViewFlinger.fling(velocityX, velocityY);
return true;
}
}
return false;
}
后面的代码我就不贴了，给大家放一张时序图，表明RecyclerView的dispatchNestedPreFling和dispatchNestedFling是如何到达AppBarLayout的
可以看到，一旦fling事件开始之后，大家就各玩各的了。
网上的一些解决办法
我在之前做需求时，就对这个不能流畅滑动感觉特别无奈，本想着问题找到了，那我就把一些类继承一下重新实现一些方法呗，然后发现了基本上用到的类都是在design包下不对外开放的，顿时发现后路被堵死，前几天在简书上看到一个人实现的效果不错，他把所有相关的类都拷出来并且做了一些修改，我感觉思路挺不错的，文章的地址是支付宝首页交互三部曲 3 实现支付宝首页交互,可以看看他文章里面的github上的代码实现的效果，很不错。
当然我当时并没有像他这样解决这个问题，我在StackOverFlow看到了一个办法，这个方法可以保证RecyclerView在向下fling时，如果第一个元素的位置不超过我们设定的阀值，那么我们就可以让AppBarLayout和RecyclerView一起fling，实现效果其实相对于不做处理会好很多，主要就是覆写AppBarLayout.Behavior
public final class FlingBehavior extends AppBarLayout.Behavior {
private static final int TOP_CHILD_FLING_THRESHOLD = 3;
private boolean isPositive;
public FlingBehavior() {
}
public FlingBehavior(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean onNestedFling(CoordinatorLayout coordinatorLayout, AppBarLayout child, View target, float velocityX, float velocityY, boolean consumed) {
if (velocityY > 0 && !isPositive || velocityY < 0 && isPositive) {
velocityY = velocityY * -1;
}
//判断是否上滑,并且第一个元素是否在阀值内
if (target instanceof RecyclerView && velocityY < 0) {
final RecyclerView recyclerView = (RecyclerView) target;
final View firstChild = recyclerView.getChildAt(0);
final int childAdapterPosition = recyclerView.getChildAdapterPosition(firstChild);
consumed = childAdapterPosition > TOP_CHILD_FLING_THRESHOLD;
}
return super.onNestedFling(coordinatorLayout, child, target, velocityX, velocityY, consumed);
}
@Override
public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child, View target, int dx, int dy, int[] consumed) {
super.onNestedPreScroll(coordinatorLayout, child, target, dx, dy, consumed);
isPositive = dy > 0;
}
}
这样写好之后会比之前流畅很多
Android8.0的改变
Google也许也认识到了这个问题，可能反馈这个问题的人太多了吧，终于在Android8.0的版本里解决掉了这个问题，这个问题让他们来解决其实最合理，因为很多类都是不对外开放的，开发者如果自己解决肯定要把很多类自己考出来一份在修改一下，造成了不必要的浪费。
Google的解决办法还是挺厉害的，他们并没有头疼治头，而是把整个问题抽象出来，升级了NestedScrolling相关的接口，现在使用的都是NestedScrollingParent2和NestedScrollingChild2接口，用NestedScrollType来区分是touch触发的滑动还是非touch触发的滑动，例如NestedScrollingChild2继承自NestedScrollingChild定义如下：
public interface NestedScrollingChild2 extends NestedScrollingChild {
boolean startNestedScroll(@ScrollAxis int axes, @NestedScrollType int type);
void stopNestedScroll(@NestedScrollType int type);
boolean hasNestedScrollingParent(@NestedScrollType int type);
boolean dispatchNestedScroll(int dxConsumed, int dyConsumed,
int dxUnconsumed, int dyUnconsumed, @Nullable int[] offsetInWindow,
@NestedScrollType int type);
boolean dispatchNestedPreScroll(int dx, int dy, @Nullable int[] consumed,
@Nullable int[] offsetInWindow, @NestedScrollType int type);
}
可以发现CoordinatorLayout、RecyclerView目前实现的接口不在是NestedScrollingParent和NestedScrollingChild，而是NestedScrollingParent2和NestedScrollingChild2。
解决这个问题的主要办法就是要在RecyclerView的整个fling过程中通知到Parent进行一些处理，首先会在fling开始之前通知Parent做记录，然后在每次fling之前先通知Parent进行消耗，在自己每次fling之后如果有剩余没有消耗的距离，在继续传递给Parent，先看一下RecyclerView在改变前后的对比：
然后ViewFlinger的执行方法中也作出了改变，在每次fling滑动之前会通知到Parent，在滑动结束之后会把剩余未消耗传递到Parent，也是解决这个问题的关键，对比如下：
整个过程的分析
上面主要对8.0版本和之前版本的实现差别做了对比，现在通过对整个流程的分析，来解释Google时如何解决这个问题的，接着上面RecyclerView在fling开始的时候调用startNestedScroll方法开始，我们可以根据源码画出如下的流程图：
这里涉及到的整个源码有点略多，所以大家可以根据流程图的过程去查看相应的源码，这里主要把这些过程分成几个组，然后只要看最关键的代码就可以了。
- 第一组：流程图中的1-9过程
这个过程主要是在RecyclerView fling之前，记录一下ParentView，这个ParentView的type是TYPE_NON_TOUCH的，这样在接下来的处理过程当中，我们所有相关的ParentView都是在这里记录下来的View，如果此时ParentView不做处理，那么后续的操作都不回传递到ParentView当中，这个之前的NestedScrolling的方法的意思是一样的，只不过这里多了一个type。NestedScrollingChildHelper对应源码如下：
public boolean startNestedScroll(@ScrollAxis int axes, @NestedScrollType int type) {
if (hasNestedScrollingParent(type)) {
// Already in progress
return true;
}
if (isNestedScrollingEnabled()) {
ViewParent p = mView.getParent();
View child = mView;
while (p != null) {
if (ViewParentCompat.onStartNestedScroll(p, child, mView, axes, type)) {
setNestedScrollingParentForType(type, p);
ViewParentCompat.onNestedScrollAccepted(p, child, mView, axes, type);
return true;
}
if (p instanceof View) {
child = (View) p;
}
p = p.getParent();
}
}
return false;
}
- 第二组：流程图中的10-13过程
这里的思想就是NestScrolling的核心思想，在我未消耗之前，先传递给ParentView做消耗，我消耗剩余的部分，RecyclerView.ViewFlinger相关源码如下:
public void run() {
if (mLayout == null) {
stop();
return; // no layout, cannot scroll.
}
disableRunOnAnimationRequests();
consumePendingUpdateOperations();
// keep a local reference so that if it is changed during onAnimation method, it won't
// cause unexpected behaviors
final OverScroller scroller = mScroller;
final SmoothScroller smoothScroller = mLayout.mSmoothScroller;
if (scroller.computeScrollOffset()) {
final int[] scrollConsumed = mScrollConsumed;
final int x = scroller.getCurrX();
final int y = scroller.getCurrY();
int dx = x - mLastFlingX;
int dy = y - mLastFlingY;
int hresult = 0;
int vresult = 0;
mLastFlingX = x;
mLastFlingY = y;
int overscrollX = 0, overscrollY = 0;
//在这里传递
if (dispatchNestedPreScroll(dx, dy, scrollConsumed, null, TYPE_NON_TOUCH)) {
dx -= scrollConsumed[0];
dy -= scrollConsumed[1];
}
..................
}
}
NestedScrollingChildHelper的dispatchNestedPreScroll如下：
public boolean dispatchNestedPreScroll(int dx, int dy, @Nullable int[] consumed,
@Nullable int[] offsetInWindow, @NestedScrollType int type) {
if (isNestedScrollingEnabled()) {
//如果对应的type没有记录下来，那么不做处理直接返回false
final ViewParent parent = getNestedScrollingParentForType(type);
if (parent == null) {
return false;
}
if (dx != 0 || dy != 0) {
int startX = 0;
int startY = 0;
if (offsetInWindow != null) {
mView.getLocationInWindow(offsetInWindow);
startX = offsetInWindow[0];
startY = offsetInWindow[1];
}
if (consumed == null) {
if (mTempNestedScrollConsumed == null) {
mTempNestedScrollConsumed = new int[2];
}
consumed = mTempNestedScrollConsumed;
}
consumed[0] = 0;
consumed[1] = 0;
ViewParentCompat.onNestedPreScroll(parent, mView, dx, dy, consumed, type);
if (offsetInWindow != null) {
mView.getLocationInWindow(offsetInWindow);
offsetInWindow[0] -= startX;
offsetInWindow[1] -= startY;
}
return consumed[0] != 0 || consumed[1] != 0;
} else if (offsetInWindow != null) {
offsetInWindow[0] = 0;
offsetInWindow[1] = 0;
}
}
return false;
}
- 第三组: 流程图中的14-18过程
这个过程，就是解决之前不能够准确fling的关键步骤，因为之前的ViewFlinger对于没有消耗完的距离只是判断了除了自己消耗完以外，剩下的不是0那么就会做一些清除动画之类的操作，所以并没有给ParentView一个继续滑动的机会，这次除了判断不等于0的条件外，还要把剩余的距离传递给ParentView，给ParentView一个准确Fling的机会，ViewFlinger的dispatchNestedScroll方法会调用到NestedScrollingChildHelper的dispatchNestedScroll方法，然后根据流程图的顺序，一直调用到AppBarLayout的onNestedScroll方法，我们可以看一下AppBarLayout的onNestedScroll就会觉得恍然大悟：
public void onNestedScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child,
View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed,
int type) {
if (dyUnconsumed < 0) {
// If the scrolling view is scrolling down but not consuming, it's probably be at
// the top of it's content
scroll(coordinatorLayout, child, dyUnconsumed,
-child.getDownNestedScrollRange(), 0);
}
}
这里只做了一件事儿，翻译一下注释的意思就是，“dyUnconsumed<0的时候，说明View的内容正在向下滑动，并且没有消耗完滑动事件，可能是View已经到达了内容的顶部”，所以在出现了这种情况的时候，AppBarLayout回调用自己的scroll方法来继续消耗，从而达到了精准fling的目的。
整个流程就分析完了，看了这块的源码，感觉对这部分的内容理解又加深了一下，希望以后能有时间在多看看其他的源码，看源码的收获还是挺大的～
