上一篇深入解析AndroidDesign包——NestedScroll 已经说过了，在AndroidDesign包中主要有两个核心概念：一是NestedScroll，另一个就是Behavior。
相比于NestedScroll这个概念来说，Behavior分析起来会难很多，因为它几乎遍布了AndroidDesign包的每一个控件，种类繁多；另外Behavior提供了二十多个空方法给使用者来重写，主要分为四类：
1.与Touch事件相关的方法
2.与NestedScroll相关的方法
3.与控件依赖相关的方法（依赖这个概念可能接触的不多，就是如果A依赖B，那么当B变化时会通知A跟着变化）
4.其他方法，如测量和布局等
由此可见，Behavior的使用是非常灵活的，所以功能也是非常的强大。但是，对于越灵活的东西，就越难将它讲清除。它有一百种用法，总不能我就举出一百个例子来进行说明，因此本文只能起到一个抛砖引玉的作用，要真正融会贯通还得靠各位自己去揣摩。
从CoordinatorLayout入手
好好的干嘛扯到CoordinatorLayout呢？
如果你这么问那你就外行了，因为如果没有CoordinatorLayout，光有Behavior是啥用都没有滴。
CoordinatorLayout就是一个容器，主要功能就是为它里面的控件传递命令，更准确的说就是使用Behavior来让子控件们相互调用。
CoordinatorLayout有自己的LayoutParams类
public static class LayoutParams extends ViewGroup.MarginLayoutParams {
/**
* A {@link Behavior} that the child view should obey.
*/
Behavior mBehavior;
它的布局参数类定义的第一个属性就是Behavior，而且还有layout_behavior属性供布局文件使用，可在布局文件中为CoordinatorLayout内部的控件设置behavior对象。
另外，所有的Behavior的祖宗都是CoordinatorLayout.Behavior，这是一个静态-内部-虚拟类，头衔有点长~ 我们抓住这个静态内部类就算是抓到Behavior的精髓了。
除了以上两点，最重要的一层关系是：所有Behavior的方法都是在CoordinatorLayout中调用的，比如来了个NestedScroll事件，那么CoordinatorLayout会调用自己的onNestedScroll()方法，然后在方法内部，就会调用childView的behavior对应的onNestedScroll()方法了。
具体过程，我们来详细分析。
如何处理Touch相关事件
找到CoordinatorLayout中的Behavior类，可以发现该类中定义了如下两个方法：
public boolean onInterceptTouchEvent(CoordinatorLayout parent, V child, MotionEvent ev) {
return false;
}
public boolean onTouchEvent(CoordinatorLayout parent, V child, MotionEvent ev) {
return false;
}
很显然，这是拦截触摸事件和处理触摸事件的方法。
我们看看这两个方法是如何被CoordinatorLayout调用的。
先看onInterceptTouchEvent
根据View的事件体系可知，对事件是否拦截的处理在onInterceptTouchEvent()方法中，于是找到CoordinatorLayout的这个方法：
public boolean onInterceptTouchEvent(MotionEvent ev) {
MotionEvent cancelEvent = null;
final int action = MotionEventCompat.getActionMasked(ev);
// Make sure we reset in case we had missed a previous important event.
if (action == MotionEvent.ACTION_DOWN) {
resetTouchBehaviors();
}
//这里才是处理事件拦截的代码
final boolean intercepted = performIntercept(ev, TYPE_ON_INTERCEPT);
if (cancelEvent != null) {
cancelEvent.recycle();
}
if (action == MotionEvent.ACTION_UP || action == MotionEvent.ACTION_CANCEL) {
resetTouchBehaviors();
}
return intercepted;
}
从上面代码可知，真正的处理逻辑在performIntercept()方法中，注意它的第二个参数TYPE_ON_INTERCEPT。然后再看performIntercept方法：
private boolean performIntercept(MotionEvent ev, final int type) {
...
//遍历所有显示出来了的childView
for (int i = 0; i < childCount; i++) {
final View child = topmostChildList.get(i);
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
final Behavior b = lp.getBehavior();
if ((intercepted || newBlock) && action != MotionEvent.ACTION_DOWN) {
// 如果事件已经被拦截，那么向其他childView发送cancelEvent
//...省略代码...
continue;
}
if (!intercepted && b != null) {
switch (type) {
//如果事件未拦截，且childView设置了behavior，则进行拦截判断
case TYPE_ON_INTERCEPT:
intercepted = b.onInterceptTouchEvent(this, child, ev);
break;
case TYPE_ON_TOUCH:
intercepted = b.onTouchEvent(this, child, ev);
break;
}
if (intercepted) {
mBehaviorTouchView = child;
}
}
...
}
topmostChildList.clear();
return intercepted;
}
对代码进行简化之后，逻辑就很明显了。先从childView中取出LayoutParams对象，然后从LayoutParams对象中取出Behavior对象，如果performIntercept()方法第二个参数传进来的是TYPE_ON_INTERCEPT，则调用behavior.onInterceptTouchEvent()方法判断是否拦截事件。换句话说就是，是否拦截事件跟CoordinatorLayout本身没有一毛钱关系。
再看onTouchEvent
直接看CoordinatorLayout中的onTouchEvent()方法源码：
public boolean onTouchEvent(MotionEvent ev) {
boolean handled = false;
boolean cancelSuper = false;
MotionEvent cancelEvent = null;
final int action = MotionEventCompat.getActionMasked(ev);
//先判断mBehaviorTouchView是否为null，如果不为null，则不会执行后面的performIntercept()
//如果等于null，则调用performIntercept方法，该方法如果返回true会对mBehaviorTouchView赋值
if (mBehaviorTouchView != null
|| (cancelSuper = performIntercept(ev, TYPE_ON_TOUCH))) {
final LayoutParams lp = (LayoutParams) mBehaviorTouchView.getLayoutParams();
final Behavior b = lp.getBehavior();
if (b != null) {
handled = b.onTouchEvent(this, mBehaviorTouchView, ev);
}
}
// 经过上面的两重判断之后，如果mBehavior还是null，则说明childView不消费touch事件
// 那么该touch事件交给CoordinatorLayout的parent去处理
if (mBehaviorTouchView == null) {
handled |= super.onTouchEvent(ev);
}
...
return handled;
}
上面的代码加了注释之后，应该不需要多说什么了。
还是那句话，CoordinatorLayout本身也不会消费touch事件。
如何处理NestedScroll相关事件
先看Behavior中跟NestedScroll相关的方法
public boolean onStartNestedScroll(CoordinatorLayout coordinatorLayout,
V child, View directTargetChild, View target, int nestedScrollAxes) {
return false;
}
public void onNestedScrollAccepted(CoordinatorLayout coordinatorLayout, V child,
View directTargetChild, View target, int nestedScrollAxes) {
// Do nothing
}
public void onStopNestedScroll(CoordinatorLayout coordinatorLayout, V child, View target) {
// Do nothing
}
public void onNestedScroll(CoordinatorLayout coordinatorLayout, V child, View target,
int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed) {
// Do nothing
}
public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, V child, View target,
int dx, int dy, int[] consumed) {
// Do nothing
}
public boolean onNestedFling(CoordinatorLayout coordinatorLayout, V child, View target,
float velocityX, float velocityY, boolean consumed) {
return false;
}
public boolean onNestedPreFling(CoordinatorLayout coordinatorLayout, V child, View target,
float velocityX, float velocityY) {
return false;
}
大家不要被这么多方法给吓到了，如果你有阅读这篇文章深入解析Android Design包——NestedScroll 就能够发现，这些方法都是NestedScrollingParent接口中定义的方法。并且CoordinatorLayout本身是实现了NestedScrollingParent接口的，那么CoordinatorLayout会如何调用Behavior的这些方法呢？ 肯定是一一对应的来调用。
我想Google这么设计的目的应该是为了解耦，只要给控件提供一个Behavior就可以拥有NestedScrollingParent的功能，这样一来控件本身就与NestedScrollingParent完全无关了。
由于方法比较多，这里就不一一展示调用过程了，挑onNestedScroll方法来说一下吧。
先看CoordinatorLayout中的onNestedScroll方法：
@Override
public void onNestedScroll(View target, int dxConsumed, int dyConsumed,
int dxUnconsumed, int dyUnconsumed) {
final int childCount = getChildCount();
boolean accepted = false;
for (int i = 0; i < childCount; i++) {
final View view = getChildAt(i);
if (view.getVisibility() == GONE) {
continue;
}
final LayoutParams lp = (LayoutParams) view.getLayoutParams();
if (!lp.isNestedScrollAccepted()) {
continue;
}
//获取childView的behavior，并调用behavior的onNestedScroll方法
final Behavior viewBehavior = lp.getBehavior();
if (viewBehavior != null) {
viewBehavior.onNestedScroll(this, view, target, dxConsumed, dyConsumed,
dxUnconsumed, dyUnconsumed);
accepted = true;
}
}
if (accepted) {
onChildViewsChanged(EVENT_NESTED_SCROLL);
}
}
代码逻辑非常清晰，就是直接把nestedScroll事件通过behavior传递给childView去处理。
但是，我们注意到最后一段代码，调用了一个onChildViewsChanged()方法。
这个方法具体逻辑我们在下一小结分析，它主要是处理那些依赖控件的。之所以在此处加一句，是为了那些跟滑动控件存在依赖关系的其他控件，也可以做出响应。
如何处理依赖相关事件
接下来，我们来看看Behavior中依赖相关的方法
//判断child和dependency是否存在依赖关系
public boolean layoutDependsOn(CoordinatorLayout parent, V child, View dependency) {
return false;
}
//dependency发生改变时，回调此方法
public boolean onDependentViewChanged(CoordinatorLayout parent, V child, View dependency) {
return false;
}
//dependency被移除时，回调此方法
public void onDependentViewRemoved(CoordinatorLayout parent, V child, View dependency) {
}
要完成上面三个方法的使命，需要满足两点：
1.需要对CoordinatorLayout所有childView进行两两判断，看它们是否存在依赖关系。
2.当一个childView发生布局改变时，CoordinatorLayout需要回调通知与其有依赖关系的其他childView。
判断依赖关系
一个View在Android系统中的显示都是：onMeasure, onLayout, onDraw
所以先看onMeasure：
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
prepareChildren();
...
}
没想到第一句就看到重点了，prepareChildren就是为了整理CoordinatorLayout内部的childView，自然也会将childView之间的依赖关系确定好，来看代码：
private void prepareChildren() {
mDependencySortedChildren.clear(); //List<View>
mChildDag.clear(); //图结构 --- 无回路有向图
//遍历所有childView
for (int i = 0, count = getChildCount(); i < count; i++) {
final View view = getChildAt(i);
final LayoutParams lp = getResolvedLayoutParams(view);
lp.findAnchorView(this, view);
mChildDag.addNode(view);
//再次遍历，需要双重遍历才能将childView两两判断dependency
//将判断的结果保存在有向图mChildDag中
for (int j = 0; j < count; j++) {
if (j == i) {
continue;
}
final View other = getChildAt(j);
final LayoutParams otherLp = getResolvedLayoutParams(other);
//这个dependsOn方法就是判断依赖关系的，内部会调用Behavior.layoutDependsOn()方法
if (otherLp.dependsOn(this, other, view)) {
if (!mChildDag.contains(other)) {
mChildDag.addNode(other);
}
mChildDag.addEdge(view, other);
}
}
}
//将图中的数据排序，并保存在List中
mDependencySortedChildren.addAll(mChildDag.getSortedList());
//将List倒序设置，让被依赖的childView排在前面，依赖于它的排在后面
Collections.reverse(mDependencySortedChildren);
}
这里涉及到一种比较复杂的数据结构——无回路有向图，篇幅有限就不在这里多说，我们只要知道会调用layoutDependsOn方法来判断依赖关系，然后将数据最后保存在mDependencySortedChildren这个List中。
这个mDependencySortedChildren列表中保存的都是childView，不过是按照特定的顺序进行了排序：
如果childView被其他view依赖的次数最多，则排在最前面，以此类推。
至于依赖关系并没有保存，到时候要用到时，再次调用layoutDependsOn方法来判断，写到这里我好像明白了为什么要将依赖次数多的放列表前面了。
childView发生布局改变
OK，依赖关系确定了，那就看看当childView发生改变时，如何让依赖的view跟着改变。
其实在NestedScroll相关方法中，最后都会调用一句代码
if (accepted) {
onChildViewsChanged(EVENT_NESTED_SCROLL);
}
上面也有提到，这个方法就是处理依赖控件的变化的。在分析它之前，还有必要看看其他地方有没有调用此方法。
然后，就看到了在onAttachToWindow()方法中，为CoordinatorLayout设置了OnPreDrawListener 回调，也就是说在执行onDraw之前，回执行onPreDraw方法中的代码。
我们先来看OnPreDrawListener：
class OnPreDrawListener implements ViewTreeObserver.OnPreDrawListener {
@Override
public boolean onPreDraw() {
onChildViewsChanged(EVENT_PRE_DRAW);
return true;
}
}
onPreDraw()的代码很简单，就是执行onChildViewsChanged()方法，也就是说每次onDraw都会调用这个方法来处理依赖控件。
接下来重点看onChildViewsChanged()方法了。
final void onChildViewsChanged(@DispatchChangeEvent final int type) {
final int childCount = mDependencySortedChildren.size();
for (int i = 0; i < childCount; i++) {
final View child = mDependencySortedChildren.get(i);
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
// ... 省略了对anchor和inset相关的代码 ...
//可以说，上面的代码都是为了提升效率，下面的才是真正的处理逻辑
for (int j = i + 1; j < childCount; j++) {
final View checkChild = mDependencySortedChildren.get(j);
final LayoutParams checkLp = (LayoutParams) checkChild.getLayoutParams();
//获取对应的Behavior对象
final Behavior b = checkLp.getBehavior();
//判断依赖关系
if (b != null && b.layoutDependsOn(this, checkChild, child)) {
if (type == EVENT_PRE_DRAW && checkLp.getChangedAfterNestedScroll()) {
//当NestedScroll 和 Draw都会触发这个方法，
//这里二者只能有一个继续往下执行
checkLp.resetChangedAfterNestedScroll();
continue;
}
final boolean handled;
switch (type) {
case EVENT_VIEW_REMOVED:
// 调用Behavior对应的方法，通知依赖这个child的其他view
//这里的child的被依赖，checkChild是依赖于它
b.onDependentViewRemoved(this, checkChild, child);
handled = true;
break;
default:
// 除了删除事件，其他的都调用下面的方法
handled = b.onDependentViewChanged(this, checkChild, child);
break;
}
if (type == EVENT_NESTED_SCROLL) {
//这里跟上面的checkLp.getChangedAfterNestedScroll()对应
checkLp.setChangedAfterNestedScroll(handled);
}
}
}
}
...
}
同样的，为了突出处理逻辑，把一些代码省略掉了。
代码不长，希望大家根据我的注释读一下代码，自然就明白了。
其实，onChildViewsChanged这个方法也只是在调用Behavior的相关方法而已，也就是说如果childA依赖于childB，那么当childB发生布局变化时，childB的Behavior就会把这个变化同时作用到childA身上。
结语
说到这里，一句话总结CoordinatorLayout本身啥事儿也不干，全让底下的childView去干了。
而Behavior之所以强大，是因为在我们不修改View的情况下，可以对View的行为进行修改和控制。
本来是要举例说明一下Behavior的具体用法的，但是没想到一写一写已经这么长了，太长的文章不利于阅读，也不利于学习吸收，就只能把举例说明移到下一篇去写了。
这里大概说一下会分析一个什么样的示例吧。
布局层级大概就是下面这个样子
<CoordinatorLayout>
<AppBarLayout>
<CollapsingToolbarLayout />
</AppBarLayout>
<NestedScrollView />
</CoordinatorLayout>
这个例子涉及到四个控件，之所以选它来说明Behavior的用法是因为，这个例子中Android都为我们提供了相应的Behavior，分析起来也更有权威性。
如果大家感兴趣，就敬请期待吧~
网友评论