Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化

之前为了开发需求,学习了NestedScrolling机制,并使用CoordinatorLayout、AppBarLayout、RecyclerView配合实现了相关的效果,还写了一篇关于分析原理的文章关于CoordinatorLayout AppBarLayout原理的一些分析,当时做完需求以后,内心其实是一只有种遗憾的,因为在使用RecyclerView时,对于向上滑动的fling效果其实是有问题的,滑动起来的感觉并不是连贯的,可以看一下这个效果:

Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第1张图片
old.gif

这个效果的体验其实并不是太好,因为向下fling时我们希望的效果是父布局可以在RecyclerView到达顶部时,如果没有消耗完fling时可以由父布局消耗从而继续滑动的,可是由于之前的实现方式,并没有办法用常规的办法达到这一点,Google也意识到了这个问题,所以在Android 8.0 扩展了NestedScrolling的相关接口,使得滑动可以变得更加顺畅了,效果如下,简直如丝般顺滑:


Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第2张图片
new.gif

在分析相关的原理之前,如果你们急需解决项目中的这种滑动不顺畅,可以先把解决方法告诉大家,那就是把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的


Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第3张图片
时序图1.png

可以看到,一旦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在改变前后的对比:


Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第4张图片
RecyclerView对比.png

然后ViewFlinger的执行方法中也作出了改变,在每次fling滑动之前会通知到Parent,在滑动结束之后会把剩余未消耗传递到Parent,也是解决这个问题的关键,对比如下:


Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第5张图片
ViewFlinger对比.png
Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第6张图片
ViewFlinger对比2.png

整个过程的分析

上面主要对8.0版本和之前版本的实现差别做了对比,现在通过对整个流程的分析,来解释Google时如何解决这个问题的,接着上面RecyclerView在fling开始的时候调用startNestedScroll方法开始,我们可以根据源码画出如下的流程图:


Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化_第7张图片
fling过程.png

这里涉及到的整个源码有点略多,所以大家可以根据流程图的过程去查看相应的源码,这里主要把这些过程分成几个组,然后只要看最关键的代码就可以了。

  • 第一组:流程图中的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的目的。

整个流程就分析完了,看了这块的源码,感觉对这部分的内容理解又加深了一下,希望以后能有时间在多看看其他的源码,看源码的收获还是挺大的~

你可能感兴趣的:(Android8.0对于CoordinatorLayout、RecyclerView 精准fling的优化)