Android嵌套滑动逻辑浅析

时间 2019-11-08

原文原文链接

问题分析

嵌套滑动一直是Android中比较棘手的问题, 根本缘由是Android的事件分发机制致使的.致使嵌套滑动难处理的关键缘由在于当子控件消费了事件, 那么父控件就不会再有机会处理这个事件了, 因此一旦内部的滑动控件消费了滑动操做, 外部的滑动控件就再也没机会响应这个滑动操做了.html

嵌套滑动

不过这个问题终于在LOLLIPOP(SDK21)以后终于有了官方的解决方法, 就是嵌套滑动机制. 在分析具体的代码逻辑以前, 下面先简单介绍下嵌套滑动的一些基本知识.
嵌套滑动机制能够理解为一个约定, 原生的支持嵌套滑动的控件都是依据这个约定来实现嵌套滑动的, 例如CoordinatorLayout, 因此若是你自定义的控件也遵照这个约定, 那么就能够跟原生的控件进行嵌套滑动了.java

基本原理

嵌套滑动的基本原理是在子控件接收到滑动一段距离的请求时, 先询问父控件是否要滑动, 若是滑动了父控件就通知子控件它消耗了一部分滑动距离, 子控件就只处理剩下的滑动距离, 而后子控件滑动完毕后再把剩余的滑动距离传给父控件.
经过这样的嵌套滑动机制, 在一次滑动操做过程当中android

父控件和子控件都有机会对滑动操做做出响应, 尤为父控件可以分别在子控件处理滑动距离以前和以后对滑动距离进行响应.数组

这解决了事件分发机制缺点引发的问题.bash

版本之别

在看具体的代码以前先说下嵌套滑动相关方法的一些我认为值得注意的地方.ide

LOLLIPOP(SDK21)以后

为何说这个是官方的解决方法? 由于ui

嵌套滑动的相关逻辑做为普通方法直接写进了最新的(SDK21以后)View和ViewGroup类.this

普通方法是指这个方法不是继承自接口或者其余类, 例如View#dispatchNestedScroll, 能够看到官方标注了Added in API level 21标示, 也就是说这是在SDK21版本以后添加进去的一个普通方法.spa

向前兼容

而SDK21以前的版本翻译

官方在android.support.v4兼容包中提供了两个接口NestedScrollingChild和NestedScrollingParent, 还有两个辅助类NestedScrollingChildHelper和NestedScrollingParentHelper来帮助控件实现嵌套滑动.

这个兼容的原理很简单

两个接口NestedScrollingChild和NestedScrollingParent分别定义上面提到的View和ViewParent新增的普通方法

在嵌套滑动中会要求控件要么是继承于SDK21以后的View或ViewGroup, 要么实现了这两个接口, 这是控件可以进行嵌套滑动的前提条件.
那么怎么知道调用的方法是控件自有的方法, 仍是接口的方法? 在代码中是经过ViewCompat和ViewParentCompat类来实现.

ViewCompat和ViewParentCompat经过当前的Build.VERSION.SDK_INT来判断当前版本, 而后选择不一样的实现类, 这样就能够根据版本选择调用的方法.

例如若是版本是SDK21以前, 那么就会判断控件是否实现了接口, 而后调用接口的方法, 若是是SDK21以后, 那么就能够直接调用对应的方法.

辅助类

除了接口兼容包还提供了NestedScrollingChildHelper和NestedScrollingParentHelper两个辅助类, 这两个辅助类实际上就是对应View和ViewParent中新增的普通方法, 代码就不贴了, 简单对比下就能够发现, 对应方法实现的逻辑基本同样, 因此

只要在接口方法内对应调用辅助类的方法就能够兼容嵌套滑动了.

例如在NestedScrollingChild#startNestedScroll方法中调用NestedScrollingChildHelper#startNestedScroll.
题外话: 这里实际用了代理模式来让SDK21以前的控件具备了新增的方法.

默认处理逻辑

虽然View和ViewGroup(SDK21以后)自己就具备嵌套滑动的相关方法, 可是默认状况是是不会被调用, 由于View和ViewGroup自己不支持滑动, 因此

自己不支持滑动的控件即便有嵌套滑动的相关方法也不能进行嵌套滑动.

上面已经说到要让控件支持嵌套滑动

首先要控件类具备嵌套滑动的相关方法, 要么仅支持SDK21以后版本, 要么实现对应的接口, 为了兼容低版本, 更经常使用到的是后者.
由于默认的状况是不会支持滑动的, 因此控件要在合适的位置主动调起嵌套滑动的方法.

接下来经过分析相对简单的支持嵌套滑动的容器NestedScrollView来了解下怎样主动调起嵌套滑动的方法, 以及嵌套滑动的具体逻辑.

从NestedScrollView看嵌套机制

说完上面一大通, 终于能够开始分析源码来了解嵌套滑动机制起做用的具体逻辑了.
NestedScrollView简单地说就是支持嵌套滑动的ScrollView, 内部逻辑简单, 并且它既能够是内控件, 也能够是外控件, 因此选择分析它来了解嵌套滑动机制.

注意 : 由于NestedScrollingChildHelper和NestedScrollingParent这两个辅助类的实现跟View和ViewGroup中的对应方法是同样的, 并且View和ViewGroup的源码没有使用兼容类, 因此下面分析相关方法的时候源码都使用View和ViewGroup中的代码.

上面已经说了嵌套滑动是从startNestedScroll开始, 因此先看看哪里调用了这个方法, 在源码里一搜就能知道有两个地方调用了这个方法.

onInterceptTouchEvent中ACTION_DOWN的状况
onTouchEvent中ACTION_DOWN的状况

由于ACTION_DOWN是滑动操做的开始事件, 因此当接收到这个事件的时候尝试找对应的外控件. 只有找到了外控件才有后续的嵌套滑动的逻辑发生.
关于NestedScrollView在这里的实现其实有个奇怪的地方, 提出一个问题, 不感兴趣的能够直接跳过这段.

既然内控件是发起者, 为何要在onInterceptTouchEvent也调用startNestedScroll呢?

由于事件传递的时候会先执行外控件的onInterceptTouchEvent, 也就是说第一个执行startNestedScroll的是最外层的NestedScrollView, 即便它找到了对应的外控件后续若是有子控件消费了这个事件, 也就是说不执行onTouchEvent方法, 那么找到外控件也没用的, 不清楚设计者的意图.

接着咱们看startNestedScroll是如何找对应的外控件的, 由于NestedScrollView#startNestedScroll调用了辅助方法的startNestedScroll, 因此下面直接贴View#startNestedScroll.

// View.javapublic 
boolean startNestedScroll(int axes) { 
    // ... 
    if (isNestedScrollingEnabled()) { 
        ViewParent p = getParent(); 
        View child = this; 
        while (p != null) { 
            try { 
                // 关键代码 
                if (p.onStartNestedScroll(child, this, axes)) { 
                    mNestedScrollingParent = p; 
                    p.onNestedScrollAccepted(child, this, axes); 
                    return true; 
                }
            } catch (AbstractMethodError e) { 
                // ... 
            } 
            if (p instanceof View) { 
                child = (View) p; 
            } 
            p = p.getParent(); 
        } 
    } 
    return false;
}复制代码

很是简单的逻辑遍历父控件, 调用父控件的onStartNestedScroll, 返回true表示找到了对应的外控件, 找到外控件后立刻调用onNestedScrollAccepted

从这里能够知道

外控件不必定是内控件的直接父控件, 但必定是最近的符合条件的外控件.

还能够肯定了上面关于onStartNestedScroll的方法说明, 返回true表示接收内控件的滑动信息.对于NestedScrollView#onStartNestedScroll内部逻辑很简单, 只要是竖直滑动方向就返回true, 因此能够知道

NestedScrollView不支持横向嵌套滑动.

接着被调用的是onNestedScrollAccepted, 看NestedScrollView#onNestedScrollAccepted

// NestedScrollView.java
@Overridepublic void onNestedScrollAccepted(View child, View target, int nestedScrollAxes) { 
        mParentHelper.onNestedScrollAccepted(child, target, nestedScrollAxes); 
        startNestedScroll(ViewCompat.SCROLL_AXIS_VERTICAL);
}复制代码

辅助类的方法很简单, 就是记录当前的滑动方向, 在这里NestedScrollView又调用startNestedScroll来找它本身的外控件, 这是为了连续嵌套NestedScrollView, 不过这是NestedScrollView本身的实现, 无论它.

找到了外控件后ACTION_DOWN事件就没嵌套滑动的事了, 要滑动确定会在onTouchEvent中处理ACTION_MOVE事件, 接着咱们看ACTION_MOVE事件是怎样处理的.

// NestedScrollView#onTouchEvent
case MotionEvent.ACTION_MOVE: 
    // ... 
    final int y = (int) MotionEventCompat.getY(ev, activePointerIndex); 
    int deltaY = mLastMotionY - y; 
    // 让外控件先处理滑动距离 
    if (dispatchNestedPreScroll(0, deltaY, mScrollConsumed, mScrollOffset)) { 
        deltaY -= mScrollConsumed[1];// 消耗滑动距离 
        // ... 
    } 
    // ... 
    if (mIsBeingDragged) { 
        // ... 
        // 内控件处理滑动距离 
        if (overScrollByCompat(0, deltaY, 0, getScrollY(), 0, range, 0, 
                      0, true) &amp;&amp; !hasNestedScrollingParent()) { 
            // ... 
        } 

        final int scrolledDeltaY = getScrollY() - oldY; 
        final int unconsumedY = deltaY - scrolledDeltaY; 
        if (dispatchNestedScroll(0, scrolledDeltaY, 0, unconsumedY, mScrollOffset)) { 
            // ... 
        } 
        // ... 
    } 
    break;复制代码

这部分是NestedScrollView可以处理嵌套滑动的关键代码了, 其余可以嵌套滑动的控件也应该在ACTION_MOVE中相似地处理滑动距离.

先计算出本次滑动距离deltaY, 这里有个小细节

deltaY等于上一次的Y坐标减去此次的Y坐标, 这意味着在相关方法中接收到的滑动距离参数中, 滑动距离 > 0表示手指向下滑动, 反之表示手指向上滑动. 这是由于在屏幕中Y轴正方向是向下的.

获得滑动距离deltaY后, 先把它传给dispatchNestedPreScroll, 而后在结果返回true的时候, delta会减去mScrollConsumed[1].

接着看dispatchNestedPreScroll干了什么

// View.java
public boolean dispatchNestedPreScroll(int dx, int dy,
                     @Nullable @Size(2) int[] consumed, @Nullable @Size(2) int[] offsetInWindow) {
    // ... 忽略状态判断 
    consumed[0] = 0; 
    consumed[1] = 0; 
    mNestedScrollingParent.onNestedPreScroll(this, dx, dy, consumed); 
    return consumed[0] != 0 || consumed[1] != 0; 
    // 其余状况返回false
}复制代码

忽略条件判断和offsetInWindow的相关处理, 先指出consumed就是上一步分析中的mScrollConsumed, dy就是deltaY.
由于dispatchNestedPreScroll的工做就是把滑动距离在内控件处理前分发给外控件, 因此这里的关键代码也很简单, 就是直接把相关的参数传给外控件的onNestedPreScroll, 而后只要外控件消耗了滑动距离(不论横向仍是竖向), 就会返回true

因此

外控件若是想在内控件以前消耗滑动距离仅须要在onNestedPreScroll把消耗的值放到数组中返回给内控件.

onNestedPreScroll是决定外控件的嵌套滑动逻辑的关键方法, 在不一样的控件中应该是根据须要有不一样的实现的, 而在NestedScrollView中就是直接询问它本身的外控件是否消耗滑动距离, 实现比较简单就不贴代码了.

在这里提醒下, 在咱们本身修改嵌套滑动逻辑的时候须要注意滑动距离的正负号和内控件处理consumed数组的方式. 不过这些都是些数字游戏, 不细说了.

好了, 如今外控件已经比内控件先处理了滑动距离了, 若是外控件没有彻底消耗掉全部滑动距离, 这时该内控件处理剩下的滑动距离了, 不一样的控件有不一样的滑动实现, 在NestedScrollView中经过NestedScrollView#overScrollByCompat来进行滑动, 而且滑动结束后经过比对滑动先后的scrollY值获得了内控件消耗的滑动距离, 而后获得剩下的滑动距离, 最后传给dispatchNestedScroll.

dispatchNestedScroll的逻辑跟dispatchNestedPreScroll几乎同样, 区别是它调用了外控件的onNestedScroll, 由于到这里已是处理滑动距离最后的机会了, 因此onNestedScroll不会再影响内控件的处理逻辑了.

到这里ACTION_MOVE事件就分析完毕了.

最后就是stopNestedScroll了, 代码就不贴了, 调用这个方法基本是新的滑动操做开始前, 或者滑动操做结束/取消, 代码逻辑就是进行一些变量的重置工做和调用onStopNestedScroll, 而onStopNestedScroll也相似.

整个嵌套滑动的基本逻辑就是这样. 注意这里虽然分析的是NestedScrollView, 但这表明了嵌套滑动的"约定"处理方式, 虽然不一样的控件实际的实现会有不一样不过应该遵循基本方法的调用顺序, 确保参数的含义和参数的处理方式.

总结

若是要支持嵌套滑动, 内控件和外控件要支持对应的方法, 为了兼容低版本通常经过实现NestedScrollingChild和NestedScrollingParent接口以及使用NestedScrollingChildHelper和NestedScrollingParent辅助类.
具体嵌套滑动逻辑主要是在onNestedPreScroll和onNestedScroll方法中.
父控件经过给数组赋值来把消耗的滑动距离传递给内控件.

感谢原创做者的独到的剖析！！

本文转载自：http://www.apkbus.com/blog-977752-79583.html