CoordinatorLayout源码分析-事件传递流程

我们知道，发生点击事件时，会首先调用ViewGroup的dispatchTouchEvent()方法，处理事件的分发，查看CoordinatorLayout并没有发现该方法，
由于它直接继承至ViewGroup，因此是默认的实现

public boolean dispatchTouchEvent(MotionEvent ev) {  
        if (disallowIntercept || !onInterceptTouchEvent(ev)) {  
            //由子view处理事件
            for (int i = count - 1; i >= 0; i--) {  
                final View child = children[i];  
                        if (child.dispatchTouchEvent(ev))  {  
                            mMotionTarget = child;  
                            return true;  
                        }  
            }  
        }  
    return target.dispatchTouchEvent(ev);  
}  

上面只是简单的流程，省略了很多代码，具体的事件传递机制分析可以查看郭神的两篇文章

Android事件分发机制完全解析，带你从源码的角度彻底理解(上)

Android事件分发机制完全解析，带你从源码的角度彻底理解(下)

可以看出，当disallowIntercept为true或onInterceptTouchEvent(ev)为false时，事件交由子view处理。disallowIntercept是指是否禁用掉事件拦截的功能，默认是false。
onInterceptTouchEvent(ev)的返回默认也是false，因此正常情况下会调用到子view的dispatchTouchEvent(ev)，而且当子view返回true时，viewgroup便无法处理后续的事件，也就是说它的onTouchEvent方法不会再调用了。

一般情况下，使用CoordinatorLayout时的布局如下

<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:visibility="visible">

    <android.support.design.widget.AppBarLayout
        android:id="@+id/appbar"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="vertical">

        <!--其他子view-->

    </android.support.design.widget.AppBarLayout>

    <android.support.v4.widget.NestedScrollView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        app:layout_behavior="@string/appbar_scrolling_view_behavior">

        <TextView
            />

    </android.support.v4.widget.NestedScrollView>

</android.support.design.widget.CoordinatorLayout>

它会包含两个子view，AppBarLayout和NestedScrollView，当然会有其他情况，暂不考虑。我们发现AppBarLayout和NestedScrollView都没有实现dispatchTouchEvent方法，
因此在默认情况下，事件会传递到onTouchEvent中，而AppBarLayout也没有实现onTouchEvent，因此接下来，便进入到NestedScrollView该方法中

            case MotionEvent.ACTION_MOVE:
                int deltaY = mLastMotionY - y; //滑动距离
                if (dispatchNestedPreScroll(0, deltaY, mScrollConsumed, mScrollOffset,
                        ViewCompat.TYPE_TOUCH)) {
                    deltaY -= mScrollConsumed[1];
                    vtev.offsetLocation(0, mScrollOffset[1]);
                    mNestedYOffset += mScrollOffset[1];
                }
                ...
                break;

我们知道，向上滑动时，一开始，顶部的appbar和scrollview一起滑动，当appbar达到固定高度时，便只有scrollview继续滚动。

向下滑动时，scrollview会先滚动，直到第一个item完全出现时，继续向下，appbar和scrollview就会一起滚动。两者是一个逆过来的过程。

这里抛些问题，一开始scrollview滚动时，是如何做到让appbar跟着滚动的呢？appbar最终到达一个高度便会固定在顶部，这个高度如何确定，又是如何实现固定在顶部的呢？其实答案都在dispatchNestedPreScroll()方法里，先简单说下，这里的mScrollConsumed
用于记录appbar消费了的距离

    //NestedScrollView.java

    private final NestedScrollingChildHelper mChildHelper;

    public boolean dispatchNestedPreScroll(int dx, int dy, int[] consumed, int[] offsetInWindow,
            int type) {
        return mChildHelper.dispatchNestedPreScroll(dx, dy, consumed, offsetInWindow, type);
    }

    //NestedScrollingChildHelper.java

    public boolean dispatchNestedPreScroll(int dx, int dy, @Nullable int[] consumed,
            @Nullable int[] offsetInWindow, @NestedScrollType int type) {
        if (isNestedScrollingEnabled()) {
            final ViewParent parent = getNestedScrollingParentForType(type);

            if (dx != 0 || dy != 0) {
                ViewParentCompat.onNestedPreScroll(parent, mView, dx, dy, consumed, type);
                return consumed[0] != 0 || consumed[1] != 0;
            } 
        }
        return false;
    }

    //ViewParentCompat.java

    public static void onNestedPreScroll(ViewParent parent, View target, int dx, int dy,
            int[] consumed, int type) {
        if (parent instanceof NestedScrollingParent2) {
            // First try the NestedScrollingParent2 API
            ((NestedScrollingParent2) parent).onNestedPreScroll(target, dx, dy, consumed, type);
        } 
    }

这里的parent是CoordinatorLayout，继承了NestedScrollingParent2接口，上面的跳转，最终走到onNestedPreScroll方法里

    //CoordinatorLayout.java

    public void onNestedPreScroll(View target, int dx, int dy, int[] consumed, int  type) {

        final int childCount = getChildCount();
        for (int i = 0; i < childCount; i++) {
            final View view = getChildAt(i);

            final LayoutParams lp = (LayoutParams) view.getLayoutParams();
            if (!lp.isNestedScrollAccepted(type)) {
                continue;
            }

            final Behavior viewBehavior = lp.getBehavior();
            if (viewBehavior != null) {
                mTempIntPair[0] = mTempIntPair[1] = 0;
                viewBehavior.onNestedPreScroll(this, view, target, dx, dy, mTempIntPair, type);

                xConsumed = dx > 0 ? Math.max(xConsumed, mTempIntPair[0])
                        : Math.min(xConsumed, mTempIntPair[0]);
                yConsumed = dy > 0 ? Math.max(yConsumed, mTempIntPair[1])
                        : Math.min(yConsumed, mTempIntPair[1]);

                accepted = true;
            }
        }

        consumed[0] = xConsumed;
        consumed[1] = yConsumed;

        if (accepted) {
            onChildViewsChanged(EVENT_NESTED_SCROLL);
        }
    }

这里，获取CoordinatorLayout的子view，通过lp.isNestedScrollAccepted()判断后，便会调用对应的onNestedPreScroll方法(NestedScrollView不能通过判断)。简单说下，appbarlayout的behavior是它的内部类Behavior，xml里为NestedScrollView配置的behavior则是ScrollingViewBehavior,也是appbarlayout的内部类

        //AppBarLayout#Behavior.java

        public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child,
                View target, int dx, int dy, int[] consumed, int type) {
            if (dy != 0) {
                int min, max;
                if (dy < 0) {
                    // We're scrolling down
                    min = -child.getTotalScrollRange();
                    max = min + child.getDownNestedPreScrollRange();
                } else {
                    // We're scrolling up
                    min = -child.getUpNestedPreScrollRange();
                    max = 0;
                }
                if (min != max) {
                    consumed[1] = scroll(coordinatorLayout, child, dy, min, max);
                }
            }
        }

在这段流程里，向上滑动dy>0，注释里也能看出来。这里的getUpNestedPreScrollRange用于判断范围，也就解释了上面的问题，appbar的固定高度是如何确定的，这里先跳过，走完滑动的流程后再分析。我们接着看scroll的实现

    //HeaderBehavior.java，是Behavior的父类

    final int scroll(CoordinatorLayout coordinatorLayout, V header,
            int dy, int minOffset, int maxOffset) {
        return setHeaderTopBottomOffset(coordinatorLayout, header,
                getTopBottomOffsetForScrollingSibling() - dy, minOffset, maxOffset);
    }

    int setHeaderTopBottomOffset(CoordinatorLayout parent, V header, int newOffset,
            int minOffset, int maxOffset) {
        final int curOffset = getTopAndBottomOffset();
        int consumed = 0;

        if (minOffset != 0 && curOffset >= minOffset && curOffset <= maxOffset) {
            // If we have some scrolling range, and we're currently within the min and max
            // offsets, calculate a new offset
            newOffset = MathUtils.clamp(newOffset, minOffset, maxOffset);

            if (curOffset != newOffset) {
                setTopAndBottomOffset(newOffset);
                // Update how much dy we have consumed
                consumed = curOffset - newOffset;
            }
        }

        return consumed;
    }

    //不一层层跟了，最终导致appbar移动的调用如下
    //ViewOffsetHelper.java

    private void updateOffsets() {
        ViewCompat.offsetTopAndBottom(mView, mOffsetTop - (mView.getTop() - mLayoutTop));
        ViewCompat.offsetLeftAndRight(mView, mOffsetLeft - (mView.getLeft() - mLayoutLeft));
    }

这里scroll有一个返回值赋值给consumed[1]，代表y轴的消费距离，也就是appbar的移动距离。当appbar没有到达固定高度时，会随着滑动，因此该值大于0，当appbar不再滑动，也就是固定在顶部时，该值便等于0。那么思绪回到最初的起点，也就是NestedScrollView的onTouchEvent中对于action_move的处理

            case MotionEvent.ACTION_MOVE:
                int deltaY = mLastMotionY - y; //滑动距离
                if (dispatchNestedPreScroll(0, deltaY, mScrollConsumed, mScrollOffset,
                        ViewCompat.TYPE_TOUCH)) {
                    deltaY -= mScrollConsumed[1];
                    vtev.offsetLocation(0, mScrollOffset[1]);
                    mNestedYOffset += mScrollOffset[1];
                }
                if (!mIsBeingDragged && Math.abs(deltaY) > mTouchSlop) {
                    final ViewParent parent = getParent();
                    if (parent != null) {
                        parent.requestDisallowInterceptTouchEvent(true);
                    }
                    mIsBeingDragged = true;

                }
                if (mIsBeingDragged) {
                    ...
                }
                break;

上述y轴消费的距离记录在了mScrollConsumed[1]中，在appbar未达到固定高度前，该值和deltaY相等，因此后面的判断Math.abs(deltaY) > mTouchSlop自然不成立。反之，当appbar达到固定高度不再滑动时，消费距离为0，deltaY自然大于mTouchSlop(该值用于是否滑动的判断，这里先忽略不计)，
接着调用parent.requestDisallowInterceptTouchEvent(true)，也就是开头提到的disallowIntercept标志，表示事件由自己接管(其实默认就是自己处理的，从开头的分析能看出来)，同时将mIsBeingDragged设置为true，表示正在滑动，继而导致后续判断成立，省略号里的就是对于scrollview本身滑动的处理了