CoordinatorLayout 學習(二) - RecyclerView和AppBarLayout的聯動分析

  咱們都知道，若是想要使用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時，咱們先來看看它的基本結構，看看它有哪些方法，而且調用時機是什麼。

方法名	做用或者調用時機
layoutDependsOn	判斷兩個是否存在依賴關係。
onDependentViewChanged	當一個View發生變化(包括位置變化等變化)時，依賴其的View的Behavior都會回調這個方法。
onDependentViewRemoved	當一個View被移除時，依賴其的View的Behavior都會回調這個方法。

  Behavior比較經常使用的方法就是如上的，其實還有嵌套滑動一些列的方法，這裏就過多的解釋。   單純的看基類天然不能深刻理解這個類使用方式，咱們來看看它的實現類，主要是從兩個方面來分析：

1. AppBarLayout的幾個Behavior
2. RecyclerView經常使用的ScrollingViewBehavior

(1). AppBarLayout的Behavior分析

  AppBarLayout的Behavior是一個複雜的繼承關係，咱們先來看看相關類圖：

  整個繼承關係如上類圖，每一個類都負責其中一部分的功能，咱們來看看：

類名	做用
ViewOffsetBehavior	在ViewOffsetBehavior的內部，定義了兩個方法,分別是setTopAndBottomOffset和setLeftAndRightOffset，主要用來改變某個View的位置。
HeaderBehavior	在HeaderBehavior中，主要是實現了兩個事件分發相關的方法。在這個類裏面，主要處理AppBarLayout自己的事件，好比說，手指在AppBarLayout上面滑動。在這個類裏面，有一個很是噁心的設計，就是若是在AppBarLayout上面Fling的話，會將全部的Fling吃掉，不會傳遞到RecyclerView上面去。我我的感受，Google爸爸的這個設計有問題,待會詳細解釋一下。
BaseBeHavior	在BaseBehavior中，主要是實現了嵌套滑動的相關方法。

  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幾個方法：

方法	做用或者調用時機
getDownNestedPreScrollRange	計算AppBarLayout能在RecyclerView向下滑動以前，能提早向下滑動的距離。很是直觀的感覺是，一個View設置了SCROLL_FLAG_ENTER_ALWAYS時，當RecyclerView向下滑動時，該View首先向下滑動。該方法返回的值表示該View能向下滑動多少。
getUpNestedPreScrollRange	做用於getDownNestedPreScrollRange方法差很少，就是它表示向上能滑動的距離。
getDownNestedScrollRange	計算當RecyclerView滑動到頂部以後，AppBarLayout能向下滑動的距離。很是直觀的感覺是，一個View設置了SCROLL_FLAG_EXIT_UNTIL_COLLAPSED時，當RecyclerView滑動到頂部以後繼續滑動時，此時該View會向下滑動。該方法返回的值表示該View能向下滑動多少。
getTotalScrollRange	該方法表示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方法含義以下：

類名	做用
HeaderScrollingViewBehavior	重寫了onMeasureChild方法和onLayoutChild方法,主要負責RecyclerView的測量和佈局。
ScrollingViewBehavior	重寫了layoutDependsOn方法和onDependentViewChanged方法。主要是負責RecyclerView與AppBarLayout聯動。

  接下來，咱們一一的來分析。

(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事件。