我们都知道，如果想要使用CoordinatorLayout实现折叠布局，只有靠AppBarLayout才会生效。但是我们不禁有一个疑问，就是为什么AppBarLayout能够与RecyclerView联动，它是怎么知道RecyclerView上滑还是下滑的呢？这是本文分析的一个重点。
  本文参考资料：

1. 针对 CoordinatorLayout 及 Behavior 的一次细节较真
2. Android 源码分析 – 嵌套滑动机制的实现原理

  由于联动机制是建立在嵌套滑动的基础上，所以在阅读本文之前，建议熟悉一下Android中嵌套滑动的原理，有兴趣的同学也可以参考我上面的文章。
  本文打算采用由浅入深的方式来介绍联动机制，分别包括如下内容：

1. CoordinatorLayout的分析
2. Behavior的分析

1. CoordinatorLayout的分析

  在这里，我们先分析一下CoordinatorLayout整体结构，包括三大流程，以及Behavior的相关调用。我们都知道，在CoordinatorLayout中，Behavior是作为一个插件角色存在的，所以我们有必要分析一下，CoordinatorLayout是怎么使用这个插件。熟悉插件的整个流程之后，后续我们在自定义Behavior时就非常容易了。

(1). CoordinatorLayout的三大流程

  CoordinatorLayout的measure过程相较于其他View来说，还是稍微有一点特殊性。CoordinatorLayout作为协调者布局，自然需要处理各个View的依赖关系，所有View的依赖关系形成了图的数据结构，因此每个View测量和布局都可能会受到其他View的影响，所以先测量哪些View，后测量哪些View，这里面需要有特殊的要求，不能通过简单的线性规则来进行。
  因此，CoordinatorLayout的measure过程先要对图进行拓补排序，得到一个线性的数列，然后才能进行下面的操作。我们先来看看CoordinatorLayout的onMeasure方法：

    @Override    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {        // 1. 得到一个图mChildDag，其中存储的是View之间的依赖关系；        // 同时，还得到一个拓补排序的数组。        prepareChildren();        ensurePreDrawListener();        // 测量每个View    }

  整个过程我们可以将他分析两步：

1. 构造依赖关系图，通过拓补排序得到一个数组。
2. 根据拓补排序得到的数组顺序，来测量每个View。

  在这个过程中，我们可以发现了Behavior的影子，我们来看看代码：

            final Behavior b = lp.getBehavior();            if (b == null || !b.onMeasureChild(this, child, childWidthMeasureSpec, keylineWidthUsed,                    childHeightMeasureSpec, 0)) {                onMeasureChild(child, childWidthMeasureSpec, keylineWidthUsed,                        childHeightMeasureSpec, 0);            }

  从上面的代码中，我们可以发现，View会尝试将测量工作交付给它的Behavior,如果Behavior不测量，然后再调用onMeasureChild方法进行测量，这样做什么好处呢？有一个很大的特点就是Behavior的高扩展性，在一些特殊的交互下，这些都是必须的。
  这里我举一个例子，如图：

  上图的布局非常的简单，这里就直接贴代码：

<androidx.coordinatorlayout.widget.CoordinatorLayout        xmlns:android="http://schemas.android.com/apk/res/android"        xmlns:app="http://schemas.android.com/apk/res-auto"        android:id="@+id/coordinator"        android:layout_width="match_parent"        android:layout_height="match_parent">    <com.google.android.material.appbar.AppBarLayout            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:fitsSystemWindows="true">        <View                android:id="@+id/view"                android:layout_width="match_parent"                android:layout_height="50dp"                android:background="#5FF"                android:minHeight="50dp"                app:layout_scrollFlags="scroll|enterAlways|enterAlwaysCollapsed"/>        <View                android:layout_width="match_parent"                android:layout_height="50dp"                android:background="#500"                android:minHeight="50dp"/>    </com.google.android.material.appbar.AppBarLayout>    <androidx.recyclerview.widget.RecyclerView            android:id="@+id/recyclerView"            android:layout_width="match_parent"            android:layout_height="match_parent"            app:layout_behavior="@string/appbar_scrolling_view_behavior"/></androidx.coordinatorlayout.widget.CoordinatorLayout>

  效果非常的明显，就是AppBarLayout第一个View会折叠，但是第二个View不会折叠，那么这个就影响到RecyclerView的测量了，正常来说RecyclerView的高度应该等于CoordinatorLayout高度减去第二个View的高度，因为第二个View始终在屏幕当中。同理，如果AppBarLayout只有一个View，同时这个View还能折叠，那么RecyclerView的高度又不一样了。像这种不固定的测量规则，交给每个View的Behavior是最好的。
  同理，布局阶段也是如此，首先会交给Behavior尝试着布局，然后CoordinatorLayout再布局，这里就不详细介绍了。

(2).事件的协调

  CoordinatorLayout被定义为协调者布局，自然要起到协调的作用，那么它在哪里就行协调的呢？最大的体现就是，将子View传递上来的嵌套滑动事件进行分发。我总结一下相关方法：

1. 嵌套事件开始，会回调onStartNestedScroll方法。
2. 嵌套滑动开始，会回调onNestedPreScroll方法。
3. 嵌套滑动结束，会回调onNestedScroll方法。
4. 嵌套滑动的Fling开始，会回调onNestedPreFling方法。
5. 嵌套滑动的Fling结束，会回调onNestedFling方法。

  而CoordinatorLayout方法是怎么进行协调的呢？在每个方法的实现里面，都通过每个View的Behavior来分发，每个Behavior在根据实际情况判断是否消费，消费多少。
  我们在自定义Behavior时，还有一个问题存在。就是如果我们使用的自定义View，然后通过一个特殊的方法来滑动该View，在CoordinatorLayout里面将该View作为依赖的View都能随之移动，这种交互是怎么实现的呢？在这种情况下，我们根本不是嵌套滑动来响应的，而是通过一个OnPreDrawListener接口来实现的，这个接口在View执行onDraw方法之前被回调。同理，在这种情况下，只能实现联动，不能实现更多复杂的UI交互。

2.Behavior的分析

  分析Behavior时，我们先来看看它的基本结构，看看它有哪些方法，并且调用时机是什么。

  Behavior比较常用的方法就是如上的，其实还有嵌套滑动一些列的方法，这里就过多的解释。
  单纯的看基类自然不能深入理解这个类使用方式，我们来看看它的实现类，主要是从两个方面来分析：

1. AppBarLayout的几个Behavior
2. RecyclerView常用的ScrollingViewBehavior

(1). AppBarLayout的Behavior分析

  AppBarLayout的Behavior是一个复杂的继承关系，我们先来看看相关类图：

  整个继承关系如上类图，每个类都负责其中一部分的功能，我们来看看：

  AppBarLayout的Behavior整个结构差不多介绍清楚了，下面我来解释一下，为什么我觉得HeaderBehavior的设计有问题。

首先，我觉得不应该多出来HeaderBehavior这一层。HeaderBehavior主要作用是用来处理AppBarLayout的事件(传统事件)，将事件处理放在HeaderBehavior里面有一个很大的缺陷，就是从此以后，AppBarLayout的子View不支持嵌套滑动，因为在AppBarLayout这一层就断了；其次，就是有一个很大的问题，Fling事件在HeaderBehavior里面全部消耗了，本来可以将未消耗的Fling事件传递给RecyclerView的，但是这样的设计却很难将未消耗的Fling传递出去。
我的建议是将这部分事件方法在AppBarLayout内部实现，其中既能保证嵌套滑动不断层，又能保证将未消耗的Fling事件传递到它的Parent中去。

  在这里，我重点分析HeaderBehavior和BaseBeHavior。

(A). HeaderBehavior

  HeaderBehavior主要是对AppBarLayout的事件进行处理，这里我们主要看fling事件，看看这里为什么不能将fling事件传递给RecyclerView。

      case MotionEvent.ACTION_UP:        if (velocityTracker != null) {          velocityTracker.addMovement(ev);          velocityTracker.computeCurrentVelocity(1000);          float yvel = velocityTracker.getYVelocity(activePointerId);          fling(parent, child, -getScrollRangeForDragFling(child), 0, yvel);        }

  核心关键点就在fling方法的第二个参数和第三个参数，分别表示fling的最小距离和最大距离。因为最大距离是0，所以一旦AppBarLayout滑出屏幕，fling就停止了。
  针对这个问题，有很多解决办法，本文先不做描述，后续我会专门的文章来解决这个问题。

(B). BaseBeHavior

  BaseBeHavior的作用是主要两个：

1. 处理AppBarLayout的嵌套滑动。
2. 负责AppBarLayout的测量和布局。

  这里专门分析嵌套滑动，不对测量和布局做分析，因为比较简单。在分析之前，我们先来看AppBarLayout几个方法：

  BaseBeHavior主要实现了嵌套滑动的onStartNestedScroll、onNestedPreScroll、onNestedScroll``onStopNestedScroll这几个方法。接下来，我们来一一分析。
  首先，我们来看看onStartNestedScroll方法：

    @Override    public boolean onStartNestedScroll(        CoordinatorLayout parent,        T child,        View directTargetChild,        View target,        int nestedScrollAxes,        int type) {      // Return true if we're nested scrolling vertically, and we either have lift on scroll enabled      // or we can scroll the children.      final boolean started =          (nestedScrollAxes & ViewCompat.SCROLL_AXIS_VERTICAL) != 0              && (child.isLiftOnScroll() || canScrollChildren(parent, child, directTargetChild));      if (started && offsetAnimator != null) {        // Cancel any offset animation        offsetAnimator.cancel();      }      // A new nested scroll has started so clear out the previous ref      lastNestedScrollingChildRef = null;      // Track the last started type so we know if a fling is about to happen once scrolling ends      lastStartedType = type;      return started;    }

  这个方法表示意思非常的简单，就是判断AppBarLayout是否需要处理嵌套滑动，其中判断条件分别是，滑动方向是垂直滑动，其次此时还有空间可以滑动。
  然后，我们再来看看onNestedPreScroll方法：

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

   onNestedPreScroll方法要分为两种情况：1. RecyclerView向下滑动；2.RecyclerVIew向上滑动。这两种情况根据不同的Flag，计算能够滑动的距离。
  再次，就是onNestedScroll方法：

    @Override    public void onNestedScroll(        CoordinatorLayout coordinatorLayout,        T child,        View target,        int dxConsumed,        int dyConsumed,        int dxUnconsumed,        int dyUnconsumed,        int type,        int[] consumed) {      if (dyUnconsumed < 0) {        // If the scrolling view is scrolling down but not consuming, it's probably be at        // the top of it's content        consumed[1] =            scroll(coordinatorLayout, child, dyUnconsumed, -child.getDownNestedScrollRange(), 0);      }    }

  这个方法的调用，只需要考虑到一种情况—RecyclerView向上滑动滑动，并且滑到了顶部，此时设置了SCROLL_FLAG_EXIT_UNTIL_COLLAPSEDFlag的View该滑动了。
  最后就是onStopNestedScroll方法：

    @Override    public void onStopNestedScroll(        CoordinatorLayout coordinatorLayout, T abl, View target, int type) {      // onStartNestedScroll for a fling will happen before onStopNestedScroll for the scroll. This      // isn't necessarily guaranteed yet, but it should be in the future. We use this to our      // advantage to check if a fling (ViewCompat.TYPE_NON_TOUCH) will start after the touch scroll      // (ViewCompat.TYPE_TOUCH) ends      if (lastStartedType == ViewCompat.TYPE_TOUCH || type == ViewCompat.TYPE_NON_TOUCH) {        // If we haven't been flung, or a fling is ending        snapToChildIfNeeded(coordinatorLayout, abl);        if (abl.isLiftOnScroll()) {          abl.setLiftedState(abl.shouldLift(target));        }      }      // Keep a reference to the previous nested scrolling child      lastNestedScrollingChildRef = new WeakReference<>(target);    }

  onStopNestedScroll方法主要是对设置FLAG_SNAP的View做动画。
  到这里，我们发现一个问题，那就是BaseBeHavior没有重写Fling相关方法，但是实际情况是AppBarLayout能成功响应RecyclerView的Fling事件，这个是怎么实现的呢？
  最初，我以为是BaseBehavior会监听RecyclerView的位置变化，通过onDependentViewChanged方法来响应Fling事件，结果发现BaseBehavior根本没有实现这个方法，那BaseBehavior方法是怎么实现的呢？
  这个问题需要从RecyclerView的ViewFlinger找答案。对于不熟悉RecyclerView的同学来说，我来解释一下，ViewFlinger到底是什么。ViewFlinger主要是用来出来RecyclerView的Fling事件的。如果有同学对他感兴趣的话，可以参考我的文章：RecyclerView 源码分析(二) – RecyclerView的滑动机制。在ViewFlinger中有如下一段代码：

                if (dispatchNestedPreScroll(unconsumedX, unconsumedY, mReusableIntPair, null,                        TYPE_NON_TOUCH)) {                    unconsumedX -= mReusableIntPair[0];                    unconsumedY -= mReusableIntPair[1];                }

  从这段代码里面，我们可以发现，RecyclerView在Fling期间也会调用dispatchNestedPreScroll方法，从而调用到BaseBeHavior的onNestedPreScroll方法，所以onNestedPreScroll方法会处理两部分的滑动距离，包括正常滑动和Fling滑动。

(2).RecyclerView的Behavior分析

  RecyclerView的Behavior继承结构与AppBarLayout的类似，我们来看看类图：

  这其中，HeaderScrollingViewBehavior和ScrollingViewBehavior方法含义如下：

  接下来，我们一一的来分析。

(A).HeaderScrollingViewBehavior

  在这里，我们重点关注HeaderScrollingViewBehavior测量时如何考虑到AppBarLayout的有效高度，具体代码如下：

        int height = availableHeight + getScrollRange(header);        int headerHeight = header.getMeasuredHeight();        if (shouldHeaderOverlapScrollingChild()) {          child.setTranslationY(-headerHeight);        } else {          height -= headerHeight;        }

  我们发现，在计算RecyclerView的高度时，还加上了AppBarLayout的可以滑动的距离。也就是说，当我们首次进入界面时，表面上看RecyclerView布满屏幕，其实还有一部分在屏幕呢。
  同样的，布局也是考虑到AppBarLayout的，这里就不分析了。

(B). ScrollingViewBehavior

  ScrollingViewBehavior主要负责RecyclerView与AppBarLayout的联动，关键代码在于onDependentViewChanged方法：

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

  具体的实现这里就不分析了，非常的简单。

3. 总结

  到这里，本文的介绍结束了，这里做本文的内容做一个简单的总结。

1. CoordinatorLayout在测量阶段，会生成一个View的依赖图，然后对这个依赖图进行拓补排序得到一个数组，测量和layout的顺序都依据一个数组的。
2. CoordinatorLayout测量和布局View的工作首先会交给每个View的Behavior，如果不处理才自己处理。
3. AppBarLayout的Behavior分为三层，分别是：ViewOffsetBehavior，方便改变View的位置；HeaderBehavior用来处理AppBarLayout自身的事件；BaseBeHavior用来处理嵌套滑动的事件。RecyclerView的Behavior也分为三层：第一层与AppBarLayout的一样；HeaderScrollingViewBehavior负责RecyclerView的测量和布局；ScrollingViewBehavior处理RecyclerView与AppBarLayout的联动。

  如果不出意外的话，下篇文章我将介绍怎么自定义Behavior和处理AppBarLayout的fling事件。

原著是一个有趣的人,若有侵权,请通知删除