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