之前为了开发需求,学习了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的目的。
整个流程就分析完了,看了这块的源码,感觉对这部分的内容理解又加深了一下,希望以后能有时间在多看看其他的源码,看源码的收获还是挺大的~