5CoordinatorLayout與AppBarLayout--嵌套滑動(dòng)

上文我們說(shuō)了AppBarLayout的簡(jiǎn)單滑動(dòng)遭垛，本篇主要介紹CoordinatorLayout下的嵌套滑動(dòng)相關(guān)知識(shí)火欧，本文對(duì)此做介紹

例子

按照慣例，先看效果，再談原理斩个×瑁可以看到在向上滑動(dòng)的時(shí)候，先滑動(dòng)AppBarLayout衰絮，AppBarLayout完全消失之后，在滑動(dòng)NestedScrollView磷醋。而在向下滑動(dòng)的時(shí)候猫牡，依然是先滑動(dòng)AppBarLayout，等AppBarLayout完全滑下來(lái)之后邓线，再滑動(dòng)NestedScrollView淌友。

代碼非常簡(jiǎn)單,如下所示，關(guān)鍵代碼就2句骇陈，toolbar內(nèi)的app:layout_scrollFlags="scroll|enterAlways"以及NestedScrollView內(nèi)的 app:layout_behavior="@string/appbar_scrolling_view_behavior"

<?xml version="1.0" encoding="utf-8"?>
<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true"
    tools:context="com.fish.behaviordemo.MainActivity">

    <android.support.design.widget.AppBarLayout
        android:layout_width="match_parent"
        android:theme="@style/AppTheme.AppBarOverlay"
        android:layout_height="wrap_content">

        <android.support.v7.widget.Toolbar
            android:id="@+id/toolbar"
            app:popupTheme="@style/AppTheme.PopupOverlay"
            android:layout_width="match_parent"
            android:layout_height="?attr/actionBarSize"
            android:background="?attr/colorPrimary"
            app:layout_scrollFlags="scroll|enterAlways" />
            <!--app:layout_scrollFlags="scroll" />-->


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


    <!--關(guān)鍵代碼-->
    <android.support.v4.widget.NestedScrollView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:layout_behavior="@string/appbar_scrolling_view_behavior">

        <LinearLayout
            android:id="@+id/linear"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:orientation="vertical">

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


    <android.support.design.widget.FloatingActionButton
        android:id="@+id/fab"

        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|end"
        android:layout_margin="@dimen/fab_margin"
        android:src="@android:drawable/ic_dialog_email"
        app:layout_behavior="com.fish.behaviordemo.fab.MyBehavior" />

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

解決方案

在分析原理前震庭，我們可以先想想，如果要自己實(shí)現(xiàn)該怎么實(shí)現(xiàn)你雌？
這個(gè)例子要求是器联，Toolbar可滑時(shí)，滑動(dòng)Toolbar婿崭，Toolbar滑完后拨拓，滑動(dòng)NestedScrollView∶フ唬滑動(dòng)時(shí)Toolbar優(yōu)先于NestedScrollView

簡(jiǎn)單想了下渣磷，至少有以下4種解決方案
1、最古老的實(shí)現(xiàn)方式就是授瘦，在Toolbar+ NestedScrollView的外層包一個(gè)NestedScrollView（簡(jiǎn)稱p） 醋界，重寫(xiě)p的onInterceptTouchEvent祟身，如果p可滑動(dòng)就攔截，若p不可滑動(dòng)物独，就交給c處理袜硫，p的高度要設(shè)置為toolbar+content的高度。這個(gè)方式有個(gè)缺點(diǎn)挡篓，那就是在一次滑動(dòng)過(guò)程中婉陷，如果p滑動(dòng)了，那c不可能滑動(dòng)官研，也就是說(shuō)不可能在一次滑動(dòng)過(guò)程中秽澳，既滑動(dòng)了p也滑動(dòng)了c，但是上面的例子是可以實(shí)現(xiàn)既滑動(dòng)p又滑動(dòng)c的
2戏羽、使用嵌套滑動(dòng)担神，同樣需要在Toolbar+ NestedScrollView的外層包一個(gè)NestedScrollView（簡(jiǎn)稱p），在p的onNestedPreScroll里處理滑動(dòng)事件始花，這個(gè)可以實(shí)現(xiàn)和例子一樣的效果妄讯，其實(shí)該例子用的就是嵌套滑動(dòng)的方法，只是更復(fù)雜一點(diǎn)
3酷宵、把NestedScrollView加一個(gè)header亥贸，剛好和Toolbar疊在一起，一開(kāi)始上滑的時(shí)候浇垦，NestedScrollView其實(shí)已經(jīng)在滑動(dòng)了炕置，但是我們看不出來(lái)，因?yàn)樵诨琱ead男韧，而toolbar監(jiān)視NestedScrollView的滑動(dòng)朴摊，然后滑動(dòng)自己。這種實(shí)現(xiàn)方式此虑，本質(zhì)是NestedScrollView一直在滑甚纲，而toolbar監(jiān)視到p滑動(dòng)之后自己再滑動(dòng),其實(shí)此時(shí)是2個(gè)view同時(shí)在滑動(dòng)
4、把NestedScrollView加一個(gè)padding寡壮，和Toolbar一樣大贩疙，然后設(shè)置android:clipToPadding="false"讹弯，再由toolbar監(jiān)視NestedScrollView的滑動(dòng)况既，然后滑動(dòng)自己，這個(gè)方法是方法3的一個(gè)變種组民，此時(shí)也是2個(gè)view同時(shí)在滑動(dòng)

原理分析

先大概講一下原理棒仍，不然看代碼會(huì)暈。

初始時(shí)NestedScrollView上滑會(huì)觸發(fā)CoordinatorLayout的onNestedPreScroll臭胜，在這里把滑動(dòng)分發(fā)給AppBarLayout莫其，觸發(fā)AppBarLayout的上移癞尚，以及NestedScrollView 的上移，看起來(lái)好像是CoordinatorLayout在滾動(dòng)一樣乱陡。

然后AppBarLayout由于上移逐漸消失浇揩，那么AppBarLayout就無(wú)法消耗滑動(dòng)事件，所以觸發(fā)NestedScrollView自己的滑動(dòng)
這里有坑憨颠，未獨(dú)占胳徽，可能被攔截。
下滑的時(shí)候也一樣爽彤，下滑觸發(fā)CoordinatorLayout的onNestedPreScroll养盗，分發(fā)給AppBarLayout，AppBarLayout如果可以滑适篙，就由AppBarLayout消費(fèi)掉往核，如果AppBarLayout不能滑，就NestedScrollView自己消費(fèi)嚷节。

AppBarLayout的滑動(dòng)聂儒，我們之前已經(jīng)說(shuō)過(guò)了。

子view與behavior

上滑源碼分析

嵌套滑動(dòng)初始化

我這里默認(rèn)大家對(duì)嵌套滑動(dòng)的知識(shí)有所了解硫痰，不了解的可以參考
我們先來(lái)找嵌套滑動(dòng)的鏈表薄货，

NestedScrollView-> CoordinatorLayout

CoordinatorLayout實(shí)現(xiàn)了NestedScrollingParent，所以是嵌套滑動(dòng)鏈上的NestedScrollView父節(jié)點(diǎn)碍论，會(huì)收到NestedScrollView滑動(dòng)的各種事件谅猾。
手指在屏幕上滑動(dòng)，會(huì)觸發(fā)NestedScrollView的move事件鳍悠。

再來(lái)看真正建立嵌套滑動(dòng)鏈表的代碼税娜，NestedScrollView調(diào)用startNestedScroll，會(huì)調(diào)用CoordinatorLayout的onStartNestedScroll
onStartNestedScroll內(nèi)的邏輯是遍歷子view藏研，如果子view的behavior的onStartNestedScroll返回true敬矩，那么調(diào)用acceptNestedScroll把mDidAcceptNestedScroll置為true。這里涉及到了behavior的另一個(gè)函數(shù)onStartNestedScroll蠢挡，這個(gè)函數(shù)有什么意義弧岳，CoordinatorLayout可以接收嵌套滑動(dòng)事件并且交給他的子view去處理，onStartNestedScroll就代表了子view是否愿意接收嵌套滑動(dòng)事件业踏。

   public boolean onStartNestedScroll(View child, View target, int nestedScrollAxes) {
        boolean handled = false;

        final int childCount = getChildCount();
        //遍歷子節(jié)點(diǎn)
        for (int i = 0; i < childCount; i++) {
            final View view = getChildAt(i);
            final LayoutParams lp = (LayoutParams) view.getLayoutParams();
            final Behavior viewBehavior = lp.getBehavior();
            if (viewBehavior != null) {
                final boolean accepted = viewBehavior.onStartNestedScroll(this, view, child, target,
                        nestedScrollAxes);
                handled |= accepted;

                lp.acceptNestedScroll(accepted);
            } else {
                lp.acceptNestedScroll(false);
            }
        }
        return handled;
    }
    
     void acceptNestedScroll(boolean accept) {
            mDidAcceptNestedScroll = accept;
        }

而看看本文的3個(gè)子view的behavior禽炬，AppBarLayout.ScrollingViewBehavior和MyBehavior的onStartNestedScroll都是返回默認(rèn)值false的，只有AppBarLayout.Behavior有可能返回true勤家「辜猓看下邊代碼

     @Override
        public boolean onStartNestedScroll(CoordinatorLayout parent, AppBarLayout child,
                View directTargetChild, View target, int nestedScrollAxes) {
            // Return true if we're nested scrolling vertically, and we have scrollable children
            // and the scrolling view is big enough to scroll
            final boolean started = (nestedScrollAxes & ViewCompat.SCROLL_AXIS_VERTICAL) != 0
                    && child.hasScrollableChildren()
                    && parent.getHeight() - directTargetChild.getHeight() <= child.getHeight();
                ...
            return started;
        }

要想返回true，得滿足3個(gè)條件伐脖，首先是縱向滑動(dòng)热幔，我們的NestedScrollView是縱向滑動(dòng)的乐设，滿足。然后AppBarLayout有可滑動(dòng)的子view绎巨，這里Toolbar內(nèi)寫(xiě)有app:layout_scrollFlags="scroll|..",所以的確存在可滑動(dòng)的子view近尚，滿足。
再看第三點(diǎn)CoordinatorLayout.getHeight() - NestedScrollView.getHeight() <= AppBarLayout.getHeight()

我們來(lái)看看這些高度分別是什么
在這里我們?cè)?jīng)詳細(xì)分析過(guò)CoordinatorLayout的measure和layout過(guò)程场勤，
假設(shè)屏幕高度為H肿男，navigatorbar高度為N，toolbar高度為T(mén)却嗡，狀態(tài)欄高度為S舶沛，那么CoordinatorLayout的高度為H-N，AppBarLayout高度為T(mén)窗价，NestedScrollView的高度是H-S-N(插一句如果toolbar不可滾如庭，那么NestedScrollView的高度為H-S-N-T,原因可以參考HeaderScrollingViewBehavior#onMeasureChild),所以上邊那個(gè)不等式就相當(dāng)于T>=S，一般來(lái)說(shuō)toolbar高度肯定大于statubar高度撼港，所以條件3滿足坪它。

三個(gè)條件滿足，返回true帝牡，建立嵌套滑動(dòng)鏈往毡，AppBarLayout的LayoutParams的mDidAcceptNestedScroll置為true。

開(kāi)始上滑

上滑一開(kāi)始是NestedScrollView的 dispatchNestedPreScroll靶溜，會(huì)發(fā)給上層CoordinatorLayout的onNestedPreScroll 代碼如下开瞭，然后CoordinatorLayout發(fā)給子view。只有l(wèi)p.mDidAcceptNestedScroll為true的才有資格接收嵌套事件罩息，這里就是發(fā)給AppBarLayout.Behavior的onNestedPreScroll嗤详。

    //CoordinatorLayout
  public void onNestedPreScroll(View target, int dx, int dy, int[] consumed) {
        int xConsumed = 0;
        int yConsumed = 0;
        boolean accepted = false;

        final int childCount = getChildCount();
        for (int i = 0; i < childCount; i++) {
            final View view = getChildAt(i);
            final LayoutParams lp = (LayoutParams) view.getLayoutParams();
            //等同于!lp.mDidAcceptNestedScroll
            if (!lp.isNestedScrollAccepted()) {
                continue;
            }

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

                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) {
            dispatchOnDependentViewChanged(true);
        }
    }

AppBarLayout.Behavior的onNestedPreScroll代碼如下所示，上滑的時(shí)候走的是L13瓷炮，獲取min=-AppBarLayout.getUpNestedPreScrollRange()葱色，getUpNestedPreScrollRange就是調(diào)用getTotalScrollRange，所以min是獲取可滑動(dòng)部分的高度的相反數(shù)（getTotalScrollRange的結(jié)果是toolbar的高度T）娘香。
然后調(diào)用scroll進(jìn)行滑動(dòng)（其實(shí)就是調(diào)用offsetTopAndBottom）苍狰，注意這里還有個(gè)返回值，返回的值就表示實(shí)際滑動(dòng)了多少烘绽，因?yàn)橛锌赡茉浇缌肆苷眩琧onsumed[1]代表的是真正滑動(dòng)的距離，會(huì)返回給NestedScrollView诀姚。如果沒(méi)有完全消費(fèi)掉這個(gè)move事件响牛，那么NestedScrollView還會(huì)滑動(dòng)。
再看傳入scroll的min和max赫段，這是范圍約束呀打，min為-T，max為0.

        //AppBarLayout.Behavior
       @Override
        public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child,
                View target, int dx, int dy, int[] consumed) {
            if (dy != 0 && !mSkipNestedPreScroll) {
                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;
                }
                consumed[1] = scroll(coordinatorLayout, child, dy, min, max);
            }
        }
        

   private int getUpNestedPreScrollRange() {
        return getTotalScrollRange();
    }

依賴滑動(dòng)

這里有一個(gè)問(wèn)題糯笙，上滑的時(shí)候會(huì)把滑動(dòng)事件分發(fā)給CoordinatorLayout而導(dǎo)致AppBarLayout滑動(dòng)贬丛，那為什么NestedScrollView也會(huì)滑動(dòng)呢?看他的behavior，AppBarLayout.ScrollingViewBehavior,如下所示给涕，可以看到他依賴于AppBarLayouts豺憔，會(huì)因?yàn)锳ppBarLayouts的位置改變而改變，所以此時(shí)其實(shí)是AppBarLayout和NestedScrollView一起在滑動(dòng)够庙，看起來(lái)就像是CoordinatorLayout在滑動(dòng)一樣恭应。但是還有個(gè)問(wèn)題，這個(gè)滑動(dòng)過(guò)程中耘眨，不需要調(diào)用onMeasure昼榛，onLayout，onDraw直接在gpu上操作剔难，所以不會(huì)調(diào)onPreDraw胆屿，那也不會(huì)調(diào)dispatchOnDependentViewChanged，所以onDependentViewChanged不應(yīng)該被調(diào)用啊偶宫，這是怎么回事非迹？實(shí)際上onDependentViewChanged不僅僅在onPreDraw里會(huì)被調(diào)用，嵌套滑動(dòng)過(guò)程中的onNestedPreScroll纯趋、onNestedScroll憎兽、onNestedPreFling、onNestedFling都會(huì)調(diào)用onDependentViewChanged

//AppBarLayout.ScrollingViewBehavior
        @Override
        public boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) {
            // We depend on any AppBarLayouts
            return dependency instanceof AppBarLayout;
        }

        @Override
        public boolean onDependentViewChanged(CoordinatorLayout parent, View child,
                View dependency) {
            offsetChildAsNeeded(parent, child, dependency);
            return false;
        }

下滑源碼分析

下滑的邏輯跟上滑類似吵冒，但有所不同唇兑。嵌套滑動(dòng)初始化，建立嵌套滑動(dòng)鏈表是一樣的桦锄，重點(diǎn)看看下滑的代碼扎附。看下滑的代碼结耀，關(guān)注L7,L8.min為-T留夜，getDownNestedPreScrollRange得到結(jié)果為T(mén)（why？）图甜，所以max為0碍粥。offset約束范圍是 [-T,0]

   @Override
        public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child,
                View target, int dx, int dy, int[] consumed) {
            if (dy != 0 && !mSkipNestedPreScroll) {
                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;
                }
                consumed[1] = scroll(coordinatorLayout, child, dy, min, max);
            }
        }

再仔細(xì)看看getDownNestedPreScrollRange,為何返回T呢？

  private int getDownNestedPreScrollRange() {
        if (mDownPreScrollRange != INVALID_SCROLL_RANGE) {
            // If we already have a valid value, return it
            return mDownPreScrollRange;
        }

        int range = 0;
        for (int i = getChildCount() - 1; i >= 0; i--) {
            final View child = getChildAt(i);
            final LayoutParams lp = (LayoutParams) child.getLayoutParams();
            final int childHeight = child.getMeasuredHeight();
            final int flags = lp.mScrollFlags;

            if ((flags & LayoutParams.FLAG_QUICK_RETURN) == LayoutParams.FLAG_QUICK_RETURN) {
                // First take the margin into account
                range += lp.topMargin + lp.bottomMargin;
                // The view has the quick return flag combination...
                if ((flags & LayoutParams.SCROLL_FLAG_ENTER_ALWAYS_COLLAPSED) != 0) {
                    // If they're set to enter collapsed, use the minimum height
                    range += ViewCompat.getMinimumHeight(child);
                } else if ((flags & LayoutParams.SCROLL_FLAG_EXIT_UNTIL_COLLAPSED) != 0) {
                    // Only enter by the amount of the collapsed height
                    range += childHeight - ViewCompat.getMinimumHeight(child);
                } else {
                    // Else use the full height
                    range += childHeight;
                }
            } else if (range > 0) {
                // If we've hit an non-quick return scrollable view, and we've already hit a
                // quick return view, return now
                break;
            }
        }
        return mDownPreScrollRange = Math.max(0, range - getTopInset());
    }

可以看出上述代碼是黑毅，查找滿足FLAG_QUICK_RETURN的view嚼摩，把他的高度統(tǒng)計(jì)下來(lái)，F(xiàn)LAG_QUICK_RETURN是什么，看下邊就是SCROLL_FLAG_SCROLL和SCROLL_FLAG_ENTER_ALWAYS枕面，我們的toolbar滿足條件愿卒，所以返回T
（如果for循環(huán)內(nèi)存在多個(gè)滿足FLAG_QUICK_RETURN的view，那第二個(gè)的margin會(huì)被計(jì)算進(jìn)去潮秘，但是本身高度不會(huì)算到range里面）

static final int FLAG_QUICK_RETURN = SCROLL_FLAG_SCROLL | SCROLL_FLAG_ENTER_ALWAYS;

去掉enterAlways

此時(shí)琼开，上滑的時(shí)候,先滑AppBarLayout，然后滑NestedScrollView枕荞，下滑的時(shí)候先滑NestedScrollView后滑AppBarLayout柜候。
為何會(huì)這樣呢？首先安裝嵌套滑動(dòng)的邏輯其實(shí)是NestedScrollView和CoordinatorLayout為嵌套父子view躏精，此處CoordinatorLayout把滑動(dòng)都交給了AppBarLayout渣刷。所以可以簡(jiǎn)單認(rèn)為AppBarLayout和NestedScrollView為嵌套父子view，那無(wú)論上滑下滑的時(shí)候矗烛，都是在pre的時(shí)候由AppBarLayout滑動(dòng)(step1)辅柴，然后NestedScrollView自己滑(step2)，然后再交由AppBarLayout滑動(dòng)(step3)高诺。怎么分配step1,step2,step3,AppBarlayout里有幾個(gè)變量mTotalScrollRange碌识，mDownPreScrollRange，mDownScrollRange就發(fā)揮作用了虱而，下滑的時(shí)候筏餐，先執(zhí)行step1，step1可以滑多遠(yuǎn)牡拇？mDownPreScrollRange魁瞪。然后執(zhí)行step2，step3惠呼，step3可以滑多遠(yuǎn)看mDownScrollRange导俘。而上滑的時(shí)候，只有step1剔蹋，step2旅薄，并沒(méi)有step3（可以看AppBarLayout.Behavior#onNestedScroll內(nèi)沒(méi)有對(duì)上滑的處理）。

去掉enterAlways為何下滑的邏輯會(huì)變呢泣崩？
因?yàn)閙DownPreScrollRange變了少梁，getDownNestedPreScrollRange里面此時(shí)就不會(huì)把toolbar高度算進(jìn)去，結(jié)果就是0.

   @Override
        public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child,
                View target, int dx, int dy, int[] consumed) {
            if (dy != 0 && !mSkipNestedPreScroll) {
                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;
                }
                consumed[1] = scroll(coordinatorLayout, child, dy, min, max);
            }
        }

下滑走L7矫付，此時(shí)
minOffset==maxOffset,所以其實(shí)就禁止了preScroll凯沪，enterAlways阻止了下拉的時(shí)候的preScroll。

那為何NestedScrollView滑完后买优，會(huì)滑動(dòng)AppBarLayout呢妨马？
此時(shí)子view滑完挺举，觸發(fā)父view CoordinatorLayout的onNestedScroll,CoordinatorLayout把這個(gè)交給AppBarLayout的behavior，此時(shí)是下滑烘跺，所以dyUnconsumed<0湘纵，走到L8，開(kāi)始滑動(dòng)液荸。

  @Override
        public void onNestedScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child,
                View target, int dxConsumed, int dyConsumed,
                int dxUnconsumed, int dyUnconsumed) {
            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);
                // Set the expanding flag so that onNestedPreScroll doesn't handle any events
                mSkipNestedPreScroll = true;
            } else {
                // As we're no longer handling nested scrolls, reset the skip flag
                mSkipNestedPreScroll = false;
            }
        }

可以看出無(wú)enteralways的時(shí)候下滑有何不同瞻佛，AppBarLayout滑動(dòng)在NestedScrollView之后（onNestedScroll）脱篙，而有enteralways的時(shí)候娇钱，AppBarLayout滑動(dòng)在NestedScrollView之前（onNestedPreScroll）。這個(gè)時(shí)候可以簡(jiǎn)單的把AppBarLayout和NestedScrollView看做嵌套滑動(dòng)里的父子绊困，子view滑前會(huì)問(wèn)父view是否滑（onNestedPreScroll）文搂，子view滑后，若未消耗完距離秤朗，會(huì)再問(wèn)一遍父view是否滑（onNestedScroll）煤蹭。這里的邏輯是一樣的，AppBarLayout可以在NestedScrollView滑前滑取视，也可以在NestedScrollView滑完之后滑硝皂，還可以在NestedScrollView之前滑一部分，之后再滑剩下的作谭。
而AppBarLayout內(nèi)有三個(gè)變量來(lái)記錄相關(guān)數(shù)據(jù)稽物，mTotalScrollRange，mDownPreScrollRange折欠，mDownScrollRange贝或。

mDownPreScrollRange代表子view滑之前，我可滑多少
mDownScrollRange代表子view滑之后锐秦，我可以滑多少
這里 有enterAlways時(shí)候咪奖， mTotalScrollRange= mDownPreScrollRange=T
無(wú)enterAlways時(shí)候， mTotalScrollRange= mDownScrollRange =T

總結(jié)

1酱床、CoordinatorLayout可以作為嵌套滑動(dòng)的父view羊赵，但他和一般的父view不一樣（一般的父view是傳給父父view處理）他收到嵌套滑動(dòng)事件之后，會(huì)發(fā)給子view處理扇谣。
2昧捷、上滑過(guò)程肯定是AppBarlayout優(yōu)先滑
3、下滑過(guò)程為AppBarlayout先滑(step1)揍堕，NestedScrollView再滑料身，AppBarlayout再滑，這個(gè)過(guò)程由mDownPreScrollRange和mDownScrollRange控制衩茸，受enterAlways影響

參考資料

http://android-developers.blogspot.com/2015/05/android-design-support-library.html
http://stackoverflow.com/questions/33984944/toolbar-overlaps-status-bar
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0717/3196.html
http://blog.csdn.net/qibin0506/article/details/50290421#reply
https://github.com/JakeWharton/DrawerBehavior
http://blog.csdn.net/eclipsexys/article/details/46349721
https://github.com/chrisbanes/cheesesquare (谷歌官方)

https://github.com/rufflez/SupportDesignLibrarySample
https://www.youtube.com/watch?v=Kz_s6DFjTcw
http://www.reibang.com/p/7caa5f4f49bd
http://www.reibang.com/p/360fd368936d