深入解析Android Design包——Behavior

上一篇深入解析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，分析起来也更有权威性。
如果大家感兴趣，就敬请期待吧~