5CoordinatorLayout与AppBarLayout--嵌套滑动 上文我们说了AppBarLayout的简单滑动，本篇主要介绍CoordinatorLayout下的嵌套滑动相关知识，本文对此做介绍
例子
文章图片
按照惯例，先看效果，再谈原理。可以看到在向上滑动的时候，先滑动AppBarLayout，AppBarLayout完全消失之后，在滑动NestedScrollView。而在向下滑动的时候，依然是先滑动AppBarLayout，等AppBarLayout完全滑下来之后，再滑动NestedScrollView。
代码非常简单,如下所示，关键代码就2句，toolbar内的app:layout_scrollFlags="scroll|enterAlways"以及NestedScrollView内的 app:layout_behavior="@string/appbar_scrolling_view_behavior"

解决方案 在分析原理前，我们可以先想想，如果要自己实现该怎么实现？
这个例子要求是，Toolbar可滑时，滑动Toolbar，Toolbar滑完后，滑动NestedScrollView。滑动时Toolbar优先于NestedScrollView
简单想了下，至少有以下4种解决方案
1、最古老的实现方式就是，在Toolbar+ NestedScrollView的外层包一个NestedScrollView（简称p） ，重写p的onInterceptTouchEvent，如果p可滑动就拦截，若p不可滑动，就交给c处理，p的高度要设置为toolbar+content的高度。这个方式有个缺点，那就是在一次滑动过程中，如果p滑动了，那c不可能滑动，也就是说不可能在一次滑动过程中，既滑动了p也滑动了c，但是上面的例子是可以实现既滑动p又滑动c的
2、使用嵌套滑动，同样需要在Toolbar+ NestedScrollView的外层包一个NestedScrollView（简称p），在p的onNestedPreScroll里处理滑动事件，这个可以实现和例子一样的效果，其实该例子用的就是嵌套滑动的方法，只是更复杂一点
3、把NestedScrollView加一个header，刚好和Toolbar叠在一起，一开始上滑的时候，NestedScrollView其实已经在滑动了，但是我们看不出来，因为在滑head，而toolbar监视NestedScrollView的滑动，然后滑动自己。这种实现方式，本质是NestedScrollView一直在滑，而toolbar监视到p滑动之后自己再滑动,其实此时是2个view同时在滑动
4、把NestedScrollView加一个padding，和Toolbar一样大，然后设置android:clipToPadding="false"，再由toolbar监视NestedScrollView的滑动，然后滑动自己，这个方法是方法3的一个变种，此时也是2个view同时在滑动
原理分析 先大概讲一下原理，不然看代码会晕。
初始时NestedScrollView上滑会触发CoordinatorLayout的onNestedPreScroll，在这里把滑动分发给AppBarLayout，触发AppBarLayout的上移，以及NestedScrollView 的上移，看起来好像是CoordinatorLayout在滚动一样。
然后AppBarLayout由于上移逐渐消失，那么AppBarLayout就无法消耗滑动事件，所以触发NestedScrollView自己的滑动
这里有坑，未独占，可能被拦截。
下滑的时候也一样，下滑触发CoordinatorLayout的onNestedPreScroll，分发给AppBarLayout，AppBarLayout如果可以滑，就由AppBarLayout消费掉，如果AppBarLayout不能滑，就NestedScrollView自己消费。
AppBarLayout的滑动，我们之前已经说过了。
子view与behavior

view	behavior
AppBarLayout	AppBarLayout.Behavior
NestedScrollView	AppBarLayout.ScrollingViewBehavior
FloatingActionButton	MyBehavior

上滑源码分析 嵌套滑动初始化 我这里默认大家对嵌套滑动的知识有所了解，不了解的可以参考
我们先来找嵌套滑动的链表，
NestedScrollView-> CoordinatorLayout
CoordinatorLayout实现了NestedScrollingParent，所以是嵌套滑动链上的NestedScrollView父节点，会收到NestedScrollView滑动的各种事件。
手指在屏幕上滑动，会触发NestedScrollView的move事件。
再来看真正建立嵌套滑动链表的代码，NestedScrollView调用startNestedScroll，会调用CoordinatorLayout的onStartNestedScroll
onStartNestedScroll内的逻辑是遍历子view，如果子view的behavior的onStartNestedScroll返回true，那么调用acceptNestedScroll把mDidAcceptNestedScroll置为true。这里涉及到了behavior的另一个函数onStartNestedScroll，这个函数有什么意义，CoordinatorLayout可以接收嵌套滑动事件并且交给他的子view去处理，onStartNestedScroll就代表了子view是否愿意接收嵌套滑动事件。

public boolean onStartNestedScroll(View child, View target, int nestedScrollAxes) { boolean handled = false; final int childCount = getChildCount(); //遍历子节点 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个子view的behavior，AppBarLayout.ScrollingViewBehavior和MyBehavior的onStartNestedScroll都是返回默认值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个条件，首先是纵向滑动，我们的NestedScrollView是纵向滑动的，满足。然后AppBarLayout有可滑动的子view，这里Toolbar内写有app:layout_scrollFlags="scroll|..",所以的确存在可滑动的子view，满足。
再看第三点CoordinatorLayout.getHeight() - NestedScrollView.getHeight() <= AppBarLayout.getHeight()
我们来看看这些高度分别是什么
在这里我们曾经详细分析过CoordinatorLayout的measure和layout过程，
假设屏幕高度为H，navigatorbar高度为N，toolbar高度为T，状态栏高度为S，那么CoordinatorLayout的高度为H-N，AppBarLayout高度为T，NestedScrollView的高度是H-S-N(插一句如果toolbar不可滚，那么NestedScrollView的高度为H-S-N-T,原因可以参考HeaderScrollingViewBehavior#onMeasureChild),所以上边那个不等式就相当于T>=S，一般来说toolbar高度肯定大于statubar高度，所以条件3满足。
三个条件满足，返回true，建立嵌套滑动链，AppBarLayout的LayoutParams的mDidAcceptNestedScroll置为true。
开始上滑 上滑一开始是NestedScrollView的 dispatchNestedPreScroll，会发给上层CoordinatorLayout的onNestedPreScroll 代码如下，然后CoordinatorLayout发给子view。只有lp.mDidAcceptNestedScroll为true的才有资格接收嵌套事件，这里就是发给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代码如下所示，上滑的时候走的是L13，获取min=-AppBarLayout.getUpNestedPreScrollRange()，getUpNestedPreScrollRange就是调用getTotalScrollRange，所以min是获取可滑动部分的高度的相反数（getTotalScrollRange的结果是toolbar的高度T）。
然后调用scroll进行滑动（其实就是调用offsetTopAndBottom），注意这里还有个返回值，返回的值就表示实际滑动了多少，因为有可能越界了，consumed[1]代表的是真正滑动的距离，会返回给NestedScrollView。如果没有完全消费掉这个move事件，那么NestedScrollView还会滑动。
再看传入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(); }

依赖滑动
这里有一个问题，上滑的时候会把滑动事件分发给CoordinatorLayout而导致AppBarLayout滑动，那为什么NestedScrollView也会滑动呢?看他的behavior，AppBarLayout.ScrollingViewBehavior,如下所示，可以看到他依赖于AppBarLayouts，会因为AppBarLayouts的位置改变而改变，所以此时其实是AppBarLayout和NestedScrollView一起在滑动，看起来就像是CoordinatorLayout在滑动一样。但是还有个问题，这个滑动过程中，不需要调用onMeasure，onLayout，onDraw直接在gpu上操作，所以不会调onPreDraw，那也不会调dispatchOnDependentViewChanged，所以onDependentViewChanged不应该被调用啊，这是怎么回事？实际上onDependentViewChanged不仅仅在onPreDraw里会被调用，嵌套滑动过程中的onNestedPreScroll、onNestedScroll、onNestedPreFling、onNestedFling都会调用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; }

下滑源码分析 下滑的逻辑跟上滑类似，但有所不同。嵌套滑动初始化，建立嵌套滑动链表是一样的，重点看看下滑的代码。看下滑的代码，关注L7,L8.min为-T，getDownNestedPreScrollRange得到结果为T（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); } }

再仔细看看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，把他的高度统计下来，FLAG_QUICK_RETURN是什么，看下边就是SCROLL_FLAG_SCROLL和SCROLL_FLAG_ENTER_ALWAYS，我们的toolbar满足条件，所以返回T
（如果for循环内存在多个满足FLAG_QUICK_RETURN的view，那第二个的margin会被计算进去，但是本身高度不会算到range里面）

static final int FLAG_QUICK_RETURN = SCROLL_FLAG_SCROLL | SCROLL_FLAG_ENTER_ALWAYS;

去掉enterAlways 此时，上滑的时候,先滑AppBarLayout，然后滑NestedScrollView，下滑的时候先滑NestedScrollView后滑AppBarLayout。
为何会这样呢？首先安装嵌套滑动的逻辑其实是NestedScrollView和CoordinatorLayout为嵌套父子view，此处CoordinatorLayout把滑动都交给了AppBarLayout。所以可以简单认为AppBarLayout和NestedScrollView为嵌套父子view，那无论上滑下滑的时候，都是在pre的时候由AppBarLayout滑动(step1)，然后NestedScrollView自己滑(step2)，然后再交由AppBarLayout滑动(step3)。怎么分配step1,step2,step3,AppBarlayout里有几个变量mTotalScrollRange，mDownPreScrollRange，mDownScrollRange就发挥作用了，下滑的时候，先执行step1，step1可以滑多远？mDownPreScrollRange。然后执行step2，step3，step3可以滑多远看mDownScrollRange。而上滑的时候，只有step1，step2，并没有step3（可以看AppBarLayout.Behavior#onNestedScroll内没有对上滑的处理）。
去掉enterAlways为何下滑的逻辑会变呢？
因为mDownPreScrollRange变了，getDownNestedPreScrollRange里面此时就不会把toolbar高度算进去，结果就是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，此时
minOffset==maxOffset,所以其实就禁止了preScroll，enterAlways阻止了下拉的时候的preScroll。
那为何NestedScrollView滑完后，会滑动AppBarLayout呢？
此时子view滑完，触发父view CoordinatorLayout的onNestedScroll,CoordinatorLayout把这个交给AppBarLayout的behavior，此时是下滑，所以dyUnconsumed<0，走到L8，开始滑动。

@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; } }

可以看出无enteralways的时候下滑有何不同，AppBarLayout滑动在NestedScrollView之后（onNestedScroll），而有enteralways的时候，AppBarLayout滑动在NestedScrollView之前（onNestedPreScroll）。这个时候可以简单的把AppBarLayout和NestedScrollView看做嵌套滑动里的父子，子view滑前会问父view是否滑（onNestedPreScroll），子view滑后，若未消耗完距离，会再问一遍父view是否滑（onNestedScroll）。这里的逻辑是一样的，AppBarLayout可以在NestedScrollView滑前滑，也可以在NestedScrollView滑完之后滑，还可以在NestedScrollView之前滑一部分，之后再滑剩下的。
而AppBarLayout内有三个变量来记录相关数据，mTotalScrollRange，mDownPreScrollRange，mDownScrollRange。
mDownPreScrollRange代表子view滑之前，我可滑多少
mDownScrollRange代表子view滑之后，我可以滑多少
这里 有enterAlways时候， mTotalScrollRange= mDownPreScrollRange=T
无enterAlways时候， mTotalScrollRange= mDownScrollRange =T
总结 1、CoordinatorLayout可以作为嵌套滑动的父view，但他和一般的父view不一样（一般的父view是传给父父view处理）他收到嵌套滑动事件之后，会发给子view处理。
2、上滑过程肯定是AppBarlayout优先滑
3、下滑过程为AppBarlayout先滑(step1)，NestedScrollView再滑，AppBarlayout再滑，这个过程由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 (谷歌官方)
【5CoordinatorLayout与AppBarLayout--嵌套滑动】https://github.com/rufflez/SupportDesignLibrarySample
https://www.youtube.com/watch?v=Kz_s6DFjTcw
http://www.jianshu.com/p/7caa5f4f49bd
http://www.jianshu.com/p/360fd368936d

推荐阅读

• 

  南宁：房贷利率新政实施后买房能省多少钱？
• 

  drive|希捷推出 Xbox 专用外置 SSD：1TB 约 1095元，USB 3.2 Gen1 接口
• 

  农户贷款如何界定 「一般农户指什么」
• 

  java用什么软件写代码，JAVA用什么软件编写
• 

  不要吃发物 不要吃过甜过咸和酸性的食物
• 

  八角金盘的介绍-八角金盘的作用
• 

  flutter添加横线，flutter虚线边框
• 

  为什么戒烟后会发胖？
• 

  佛珠多肉烂根怎么办 佛珠多肉烂了怎么办
• 

  中国知名菜刀有什么牌子？中国十大菜刀品牌排行
• 

  从入门到精通，轻松应对各种错误 打印机1700代码解析
• 

  水果礼盒制作步骤大全图解 水果礼盒的制作技巧是怎么样的
• 

  支付宝花呗当面花怎么使用？使用方法及店铺详细介绍
• 

  恒为科技的军方服务器具有怎样的性能？ 恒为科技军方服务器怎么样
• 

  gis中画的图成无效的书签，gis图没了
• 

  工商银行主要业务有哪些
• 

  iphone皮套
• 

  爱普生1430喷墨机清零
• 

  关于vb.neteval的信息
• 

  非诚勿扰影视产业分析

• JAVA（抽象类与接口的区别&重载与重写&内存泄漏）
• Docker应用:容器间通信与Mariadb数据库主从复制
• 《真与假的困惑》???|《真与假的困惑》??? ——致良知是一种伟大的力量
• 第326天
• Shell-Bash变量与运算符
• 逻辑回归的理解与python示例
• Guava|Guava RateLimiter与限流算法
• 我和你之前距离
• CGI，FastCGI，PHP-CGI与PHP-FPM
• 原生家庭之痛与超越