CoordinatorLayout
終于到這個控件了，其實我的內心是忐忑的，因為我其實一直想要深入的理解 CoordinatorLayout+Behavior的原理，但是又苦于太難懂了，以前也零零碎碎研究過幾次，最后都以失敗告終。這次是沒辦法，MaterialDesign 篇到這里也快結束了，做事還是要有始有終，于是這兩天好好研究了一下，發現這東西其實也沒那么復雜。
CoordinatorLayout直接繼承了ViewGroup，說明最少重寫了 onMeasure和 onLayout 方法，說不定還有 onMeasureChild和 onLayoutChild 方法。然后我們在看，CoordinatorLayout 是用來處理嵌套滑動的，那么onTouchEvent()和 onInterceptTouchEvent()方法肯定也跑不掉。
好了，按照慣例，我們先從構造方法以及 attributes 屬性開始看吧。
attributes
<declare-styleable name="CoordinatorLayout">
<attr format="reference" name="keylines"/>
<attr format="reference" name="statusBarBackground"/>
</declare-styleable>
<declare-styleable name="CoordinatorLayout_Layout">
<attr name="android:layout_gravity"/>
<attr format="string" name="layout_behavior"/>
<attr format="reference" name="layout_anchor"/>
<attr format="integer" name="layout_keyline"/>
<attr name="layout_anchorGravity">
<flag name="top" value="0x30"/>
<flag name="bottom" value="0x50"/>
<flag name="left" value="0x03"/>
<flag name="right" value="0x05"/>
<flag name="center_vertical" value="0x10"/>
<flag name="fill_vertical" value="0x70"/>
<flag name="center_horizontal" value="0x01"/>
<flag name="fill_horizontal" value="0x07"/>
<flag name="center" value="0x11"/>
<flag name="fill" value="0x77"/>
<flag name="clip_vertical" value="0x80"/>
<flag name="clip_horizontal" value="0x08"/>
<flag name="start" value="0x00800003"/>
<flag name="end" value="0x00800005"/>
</attr>
<attr format="enum" name="layout_insetEdge">
<enum name="none" value="0x0"/>
<enum name="top" value="0x30"/>
<enum name="bottom" value="0x50"/>
<enum name="left" value="0x03"/>
<enum name="right" value="0x03"/>
<enum name="start" value="0x00800003"/>
<enum name="end" value="0x00800005"/>
</attr>
<attr name="layout_dodgeInsetEdges">
<flag name="none" value="0x0"/>
<flag name="top" value="0x30"/>
<flag name="bottom" value="0x50"/>
<flag name="left" value="0x03"/>
<flag name="right" value="0x03"/>
<flag name="start" value="0x00800003"/>
<flag name="end" value="0x00800005"/>
<flag name="all" value="0x77"/>
</attr></declare-styleable>
可以直接設置在 CoordinatorLayout 節點上的屬性有兩個
- keylines 一個比較奇怪的屬性，好像是一個布局解決方案吧。比較雞肋，沒有人用過它
- statusBarBackground 狀態欄背景顏色
剩下的都是只能作用在 CoordinatorLayout 的直接子節點上的屬性
- layout_behavior 這個屬性大家都很熟悉，因為Behavior 是嵌套滑動的精華。輔助Coordinator對View進行layout、nestedScroll的處理
- layout_anchor 將其固定在某個 view 上面，可以理解成依附
- layout_keyline 同上
- layout_anchorGravity 這個容易理解，依附在控件上的位置
- layout_insetEdge 用于避免布局之間互相遮蓋
- layout_dodgeInsetEdges 用于避免布局之間互相遮蓋
布局這一塊沒什么說的，CoordinatorLayout作為頂級節點，然后根據實際需求使用對應的控件和屬性就行了，這里我就不做過多的贅述。
源碼
首先，剛剛我們猜測了肯定會重寫 onMeasure 方法，那么我們就從 onMeasure 方法開始看。
onMeasure 方法里面有這么一段方法，我 copy 出來給大家看一下
for (int i = 0; i < childCount; i++) {
final View child = mDependencySortedChildren.get(i);
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
int keylineWidthUsed = 0;
if (lp.keyline >= 0 && widthMode != MeasureSpec.UNSPECIFIED) {
final int keylinePos = getKeyline(lp.keyline);
final int keylineGravity = GravityCompat.getAbsoluteGravity(
resolveKeylineGravity(lp.gravity), layoutDirection)
& Gravity.HORIZONTAL_GRAVITY_MASK;
if ((keylineGravity == Gravity.LEFT && !isRtl)
|| (keylineGravity == Gravity.RIGHT && isRtl)) {
keylineWidthUsed = Math.max(0, widthSize - paddingRight - keylinePos);
} else if ((keylineGravity == Gravity.RIGHT && !isRtl)
|| (keylineGravity == Gravity.LEFT && isRtl)) {
keylineWidthUsed = Math.max(0, keylinePos - paddingLeft);
}
}
int childWidthMeasureSpec = widthMeasureSpec;
int childHeightMeasureSpec = heightMeasureSpec;
if (applyInsets && !ViewCompat.getFitsSystemWindows(child)) {
// We're set to handle insets but this child isn't, so we will measure the
// child as if there are no insets
final int horizInsets = mLastInsets.getSystemWindowInsetLeft()
+ mLastInsets.getSystemWindowInsetRight();
final int vertInsets = mLastInsets.getSystemWindowInsetTop()
+ mLastInsets.getSystemWindowInsetBottom();
childWidthMeasureSpec = MeasureSpec.makeMeasureSpec(
widthSize - horizInsets, widthMode);
childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(
heightSize - vertInsets, heightMode);
}
final Behavior b = lp.getBehavior();
if (b == null || !b.onMeasureChild(this, child, childWidthMeasureSpec, keylineWidthUsed,
childHeightMeasureSpec, 0)) {
onMeasureChild(child, childWidthMeasureSpec, keylineWidthUsed,
childHeightMeasureSpec, 0);
}
widthUsed = Math.max(widthUsed, widthPadding + child.getMeasuredWidth() +
lp.leftMargin + lp.rightMargin);
heightUsed = Math.max(heightUsed, heightPadding + child.getMeasuredHeight() +
lp.topMargin + lp.bottomMargin);
childState = ViewCompat.combineMeasuredStates(childState,
ViewCompat.getMeasuredState(child));
}
這是一段遍歷子 View 的操作，首先判斷 keyLine，這個屬性我們不關心，直接跳過，然后就是獲取子 view 的 Behavior，然后判斷是否為空，在根據 Behavior 去 measure 子 view。這里我們能看到子 view 的 Behavior 是保存在 LayoutParams里面的，所以這個 LayoutParams 肯定是重寫的。然后我們 Behavior 一般是直接寫到 xml 布局的子節點上對吧，所以可以判斷子 view 的 Behavior 是在View 解析 xml 的時候，讀取到 Behavior 節點，然后賦值給 LayoutParams。LayoutInflate 的源碼我就不帶著大家去讀了，我貼出關鍵代碼
ViewGroup.LayoutParams params = null;
try {
params = group.generateLayoutParams(attrs);
} catch (RuntimeException e) {
// Ignore, just fail over to child attrs.
}
這里的group 就是 parent強轉的，子 View 的 LayoutParams 是通過父 view 的generateLayoutParams()創建，于是我們去看 CoordinatorLayout 的generateLayoutParams方法。
@Override
public LayoutParams generateLayoutParams(AttributeSet attrs) {
return new LayoutParams(getContext(), attrs);
}
額，尷尬了，直接去看構造方法把
LayoutParams(Context context, AttributeSet attrs) {
super(context, attrs);
final TypedArray a = context.obtainStyledAttributes(attrs,
R.styleable.CoordinatorLayout_Layout);
this.gravity = a.getInteger(
R.styleable.CoordinatorLayout_Layout_android_layout_gravity,
Gravity.NO_GRAVITY);
mAnchorId = a.getResourceId(R.styleable.CoordinatorLayout_Layout_layout_anchor,
View.NO_ID);
this.anchorGravity = a.getInteger(
R.styleable.CoordinatorLayout_Layout_layout_anchorGravity,
Gravity.NO_GRAVITY);
this.keyline = a.getInteger(R.styleable.CoordinatorLayout_Layout_layout_keyline,
-1);
insetEdge = a.getInt(R.styleable.CoordinatorLayout_Layout_layout_insetEdge, 0);
dodgeInsetEdges = a.getInt(
R.styleable.CoordinatorLayout_Layout_layout_dodgeInsetEdges, 0);
mBehaviorResolved = a.hasValue(
R.styleable.CoordinatorLayout_Layout_layout_behavior);
if (mBehaviorResolved) {
mBehavior = parseBehavior(context, attrs, a.getString(
R.styleable.CoordinatorLayout_Layout_layout_behavior));
}
a.recycle();
if (mBehavior != null) {
// If we have a Behavior, dispatch that it has been attached
mBehavior.onAttachedToLayoutParams(this);
}
}
好，這里我們可以看到，我們之前設置的一些layout_anchor、anchorGravity、layout_keyline、layout_behavior等屬性，我就不過多贅述了，今天的重點是 Behavior 呢，我們看parseBehavior()方法，這個方法創建了一個 Behavior
static Behavior parseBehavior(Context context, AttributeSet attrs, String name) {
if (TextUtils.isEmpty(name)) {
return null;
}
final String fullName;
if (name.startsWith(".")) {
// Relative to the app package. Prepend the app package name.
fullName = context.getPackageName() + name;
} else if (name.indexOf('.') >= 0) {
// Fully qualified package name.
fullName = name;
} else {
// Assume stock behavior in this package (if we have one)
fullName = !TextUtils.isEmpty(WIDGET_PACKAGE_NAME)
? (WIDGET_PACKAGE_NAME + '.' + name)
: name;
}
try {
Map<String, Constructor<Behavior>> constructors = sConstructors.get();
if (constructors == null) {
constructors = new HashMap<>();
sConstructors.set(constructors);
}
Constructor<Behavior> c = constructors.get(fullName);
if (c == null) {
final Class<Behavior> clazz = (Class<Behavior>) Class.forName(fullName, true,
context.getClassLoader());
c = clazz.getConstructor(CONSTRUCTOR_PARAMS);
c.setAccessible(true);
constructors.put(fullName, c);
}
return c.newInstance(context, attrs);
} catch (Exception e) {
throw new RuntimeException("Could not inflate Behavior subclass " + fullName, e);
}
}
可以看到，內部是通過反射的方式創建的Behavior，然后調用的兩個參數的構造函數，所以如果想要試用behavior就必須實現它的構造函數，不然就會報異常。哈哈，反正我第一次創建 Behavior 的時候運行時報錯了，說找不到兩個參數的構造方法。
好，接下來開始到重點了。measure 方法結束了之后，應該開始布局了，所以我們解析來去看 onLayout()方法
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
final int layoutDirection = ViewCompat.getLayoutDirection(this);
final int childCount = mDependencySortedChildren.size();
for (int i = 0; i < childCount; i++) {
final View child = mDependencySortedChildren.get(i);
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
final Behavior behavior = lp.getBehavior();
if (behavior == null || !behavior.onLayoutChild(this, child, layoutDirection)) {
onLayoutChild(child, layoutDirection);
}
}
}
遍歷子 view，如果 behavior.onLayoutChild()方法返回true，則不會調用 CoordinatorLayout 的 onLayouChild()方法，由此可得出結論，重寫 Behavior 的 onLayoutChild 方法是用來自定義當前 View 的布局方式。
此時，布局結束，我們的 CoordinatorLayout 靜態頁面已經完成，接下來，我們要看的是滑動的時候，CoordinatorLayout 怎么處理。
我們來簡單回顧一下 ViewGroup 的事件分發機制，首先 disPatchTouchEvent()被調用，然后調用 onInterceptTouchEvent 判斷是否允許事件往下傳，如果允許則丟給子 View的disPatchTouchEvent 來處理，如果不允許或者允許后子 view沒有消費掉事件，則 先后調用自己的 onTouchListener 和 OnTouchEvent來消費事件。
然后我們來根據這個順序看 CoordinatorLayout 的事件處理順序，首先看 disPatchTouchEvent 方法， 這個方法，沒有重寫，那么略過直接看 onInterceptTouchEvent 方法。
@Override
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()方法
private boolean performIntercept(MotionEvent ev, final int type) {
boolean intercepted = false;
boolean newBlock = false;
MotionEvent cancelEvent = null;
final int action = MotionEventCompat.getActionMasked(ev);
final List<View> topmostChildList = mTempList1;
getTopSortedChildren(topmostChildList);
// Let topmost child views inspect first
final int childCount = topmostChildList.size();
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) {
// Cancel all behaviors beneath the one that intercepted.
// If the event is "down" then we don't have anything to cancel yet.
if (b != null) {
if (cancelEvent == null) {
final long now = SystemClock.uptimeMillis();
cancelEvent = MotionEvent.obtain(now, now,
MotionEvent.ACTION_CANCEL, 0.0f, 0.0f, 0);
}
switch (type) {
case TYPE_ON_INTERCEPT:
b.onInterceptTouchEvent(this, child, cancelEvent);
break;
case TYPE_ON_TOUCH:
b.onTouchEvent(this, child, cancelEvent);
break;
}
}
continue;
}
if (!intercepted && b != null) {
switch (type) {
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;
}
}
// Don't keep going if we're not allowing interaction below this.
// Setting newBlock will make sure we cancel the rest of the behaviors.
final boolean wasBlocking = lp.didBlockInteraction();
final boolean isBlocking = lp.isBlockingInteractionBelow(this, child);
newBlock = isBlocking && !wasBlocking;
if (isBlocking && !newBlock) {
// Stop here since we don't have anything more to cancel - we already did
// when the behavior first started blocking things below this point.
break;
}
}
topmostChildList.clear();
return intercepted;
}
遍歷所有子 View，調用了符合條件的 view 的 Behavior.onInterceptTouchEvent/onTouchEvent方法
然后我們來看 onTouchEvent 方法
@Override
public boolean onTouchEvent(MotionEvent ev) {
boolean handled = false;
boolean cancelSuper = false;
MotionEvent cancelEvent = null;
final int action = MotionEventCompat.getActionMasked(ev);
if (mBehaviorTouchView != null || (cancelSuper = performIntercept(ev, TYPE_ON_TOUCH))) {
// Safe since performIntercept guarantees that
// mBehaviorTouchView != null if it returns true
final LayoutParams lp = (LayoutParams) mBehaviorTouchView.getLayoutParams();
final Behavior b = lp.getBehavior();
if (b != null) {
handled = b.onTouchEvent(this, mBehaviorTouchView, ev);
}
}
// Keep the super implementation correct
if (mBehaviorTouchView == null) {
handled |= super.onTouchEvent(ev);
} else if (cancelSuper) {
if (cancelEvent == null) {
final long now = SystemClock.uptimeMillis();
cancelEvent = MotionEvent.obtain(now, now,
MotionEvent.ACTION_CANCEL, 0.0f, 0.0f, 0);
}
super.onTouchEvent(cancelEvent);
}
if (!handled && action == MotionEvent.ACTION_DOWN) {
}
if (cancelEvent != null) {
cancelEvent.recycle();
}
if (action == MotionEvent.ACTION_UP || action == MotionEvent.ACTION_CANCEL) {
resetTouchBehaviors();
}
return handled;
}
重點在if (mBehaviorTouchView != null || (cancelSuper = performIntercept(ev, TYPE_ON_TOUCH))這句話上，如果先前有子 view 的Behavior 的 onInterceptTouchEvent 返回了 true，則直接調用這個子 view 的 Behavior 的 onTouchEvent。否則就繼續走一遍performIntercept(ev, TYPE_ON_TOUCH)，即：執行所有含有 Behavior 的子 view 的 Behavior.onTouchEvent方法。
咳咳~~好了， 上面兩個方法的各種邏輯判斷有點繞，我也是被繞了很久，沒看懂沒事，直接看杰倫
我們再來回過頭看這兩個方法，其最終都是調用了 Behavior 的 onInterceptTouchEvent 和 onTouchEvent 方法，然后各種條件判斷就是什么時候調用這兩個方法。
onInterceptTouchEvent
1.在 CoordinatorLayout 的 onInterceptTouchEvent 方法中杯調用 。
2.調用順序：按照 CoordinatorLayout 中 child 的添加倒敘進行調用
3.運行原理：
如果此方法在 down 事件返回 true，那么它后面的 view 的 Behavior 都執行不到此方法；并且執行 onTouchEvent 事件的時候只會執行此 view 的 Behavior 的 onTouchEvent 方法。
如果不是 down 事件返回 true，那么它后面的 view 的 Behavior 的 onInterceptTouchEvent 方法都會執行，但還是只執行第一個 view 的 Behavior 的 onTouchEvent 方法
如果所有的 view 的 Behavior 的onInterceptTouchEvent 方法都沒有返回 true，那么在 CoordinatorLayout 的 onTouchEvent 方法內會回調所有 child 的 Behavior 的 onTouchEvent 方法
4.CoordinatorLayout 的 onInterceptTouchEvent 默認返回 false，返回值由child 的 Behavior 的 onInterceptTouchEvent 方法決定onTouchEvent
1.在 CoordinatorLayout 的 onTouchEvent 方法中被調用
2.調用順序：同上
3.在上面 onInterceptTouchEvent 提到的所有 Behavior 的 onTouchEvent 都返回 false 的情況下，會遍歷所有 child 的此方法，但是只要有一個 Behavior 的此方法返回 true，那么后面的所有 child 的此方法都不會執行
4.CoordinatorLayout 的 onTouchEvent默認返回super.onTouchEvent()，如果有 child 的 Behavior 的此方法返回 true，則返回 true。
然后再來說一下嵌套滑動把，我們都知道 CoordinatorLayout 的內嵌套滑動只能用 NestedScrollView 和 RecyclerView，至于為什么呢。我相信很多人肯定點開過 NestedScrollView 和 RecyclerView 的源碼，細心的同學肯定會發現這兩個類都實現了NestedScrollingChild接口，而我們的 CoordinatorLayout 則實現了NestedScrollingParent的接口。這兩個接口不是這篇文章的重點，我簡單說一下，CoordinatorLayout 的內嵌滑動事件都是被它的子NestedScrollingChild實現類處理的。而子View 在滑動的時候，會調用NestedScrollingParent的方法，于是 CoordinatorLayout 再NestedScrollingParent的實現方法中，調用了 Behavior 的對應方法。
總結
好了，分析到這里，其實我感覺，我們更應該去了解一下NestedScrollingParent和NestedScrollingChild的嵌套滾動機制。簡單點說，就是 child（RecycleView） 在滾動的時候調用了 parent（CoordinatorLayout） 的 對應方法，而我們的 Behavior，則是在 parent 的回調方法中，處理了其他child 的伴隨變化。
本質上，我們可以通過自定義控件的方式實現，但是 Google幫我們封裝的這一套控件很解耦啊、很牛逼啊、很方便啊，所以我用它。
Behavior
直接看官網描述吧
Interaction behavior plugin for child views of CoordinatorLayout.
對 CoordinatorLayout 的 child 交互行為的插件。A Behavior implements one or more interactions that a user can take on a child view. These interactions may include drags, swipes, flings, or any other gestures.
一個child 的Behavior 可以實現一個或者多個 child 的交互，這些交互可以包括拖動、滑動、慣性以及其他手勢。
按照國際慣例，我們應該先看 Public methods。但是，As a Developer，我們是不需要持有 Behavior 引用的。所有的 Behavior CoordinatorLayout都已經幫我們管理好了，所以，我們可以先不用關心公共方法。
好了，那我們聊兩點大家需要關心的。
Dependent
Dependent: adj.依賴的
顧名思義，Dependent 就是依賴的意思。在 Behavior 中，就是使某個 View依賴一個指定的 view，使得被依賴的 view 的大小位置改變發生變化的時候，依賴的 view 也可以做出相應的動作。
常見的方法有兩個
- public boolean layoutDependsOn(CoordinatorLayout parent, V child, View dependency)
確定所提供的child 是否有另一個特點兄弟 View 的依賴
在一個CoordinatorLayout 布局里面，這個方法最少會被調用一次，如果對于一個給定的 child 和依賴返回 true，則父CoordinatorLayout 將：
1.在被依賴的view Layout 發生改變后，這個 child 也會重新 layout。
2.當依賴關系視圖的布局或位置變化時，會調用 onDependentViewChange
- public boolean onDependentViewChanged(CoordinatorLayout parent, V child, View dependency)
響應依賴 view 變化的方法
無論是依賴 view的尺寸、大小或者位置發生改變，這個方法都會被調用，一個 Behavior 可以使用此方法來適當的更新響應child
view 的依賴關系由layoutDependsOn 或者child 設置了another屬性來確定。
如果 Behavior 改變了 child 的大小或位置，它應該返回 true，默認返回 false。
好了，說了這么久，我們來動手寫一個小 Demo 吧。
大家都知道 FloatActionBar 在 CoordinatorLayout 布局中，處于屏幕底部時，然后 SnackBar 彈出來之后，會自動把 FloatActionBar 頂上去。就像醬紫
布局文件和代碼都賊簡單~如下
<android.support.design.widget.CoordinatorLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
xmlns:app="http://schemas.android.com/apk/res-auto"
tools:context=".TestActivity">
<android.support.design.widget.FloatingActionButton
android:id="@+id/bt"
android:layout_gravity="bottom|right"
app:layout_behavior=".behavior.FABBehavior"
android:layout_width="wrap_content"
android:text="FloatActionBar"
android:layout_height="wrap_content"/>
</android.support.design.widget.CoordinatorLayout>
findViewById(R.id.bt).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Snackbar.make(v,"自定義 FloatActionBar", 1500).show();
}
});
這里就不一步一步去糾結了，FloatingActionButton內部有一個默認的 Behavior，這個 Behavior 實現了很多效果，我們先跳過吧。
然后我們來自定義一個 FloatingActionButton，實現 SnackBar 彈出的時候頂上去。
實現思路：我們要在SnackBar 在彈出的時候跟著一起往上位移，也就是說我們要監聽 SnackBar 的位移事件，那么我們可以layoutDependsOn判斷目前發生變化的 view 是不是 SnackBar，如果是，則返回 true，onDependentViewChanged方法，在onDependentViewChanged里面改變 MyFloatingActionButton 的位置。
我要自己實現的效果：
代碼實現，xml 布局（這里我圖方便，就用一個 Button 代替了，樣式也沒改。。。主要是因為懶）
<android.support.design.widget.CoordinatorLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
xmlns:app="http://schemas.android.com/apk/res-auto"
tools:context=".TestActivity">
<Button
android:id="@+id/bt"
android:layout_gravity="bottom|right"
app:layout_behavior=".behavior.FABBehavior"
android:layout_width="wrap_content"
android:text="FloatActionBar"
android:layout_height="wrap_content"/>
</android.support.design.widget.CoordinatorLayout>
這里其實就是一個 CoordinatorLayout 里面包裹了一個 Button，關鍵代碼就是“app:layout_behavior=".behavior.FABBehavior"”，然后我們需要去寫這個 FABBehavior 就行了。邏輯很簡單，代碼如下：
public class FABBehavior extends CoordinatorLayout.Behavior {
public FABBehavior(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) {
return dependency instanceof Snackbar.SnackbarLayout;
}
@Override
public boolean onDependentViewChanged(CoordinatorLayout parent, View child, View dependency) {
float translationY = Math.min(0, dependency.getTranslationY() - dependency.getHeight());
child.setTranslationY(translationY);
return true;
}
}
很簡單的代碼邏輯，我就不寫注釋了，這里記得寫兩個參數的構造方法就行了。
然后我們再來看一個基于 Dependent 的 Demo
好了，直接貼代碼吧，很簡單的。
<?xml version="1.0" encoding="utf-8"?>
<android.support.design.widget.CoordinatorLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.design.widget.AppBarLayout
android:id="@+id/appbar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar">
<android.support.v7.widget.Toolbar
android:layout_width="match_parent"
android:layout_height="?attr/actionBarSize"
app:layout_scrollFlags="scroll|enterAlways"
app:navigationIcon="@mipmap/abc_ic_ab_back_mtrl_am_alpha"
app:title="標題">
</android.support.v7.widget.Toolbar>
</android.support.design.widget.AppBarLayout>
<android.support.v7.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:tag="Tag"
app:layout_behavior="@string/appbar_scrolling_view_behavior"/>
<TextView
android:layout_width="match_parent"
android:layout_height="48dp"
android:layout_gravity="bottom"
android:background="@color/colorPrimary_pink"
android:gravity="center"
android:text="我是底部導航欄"
android:textColor="@color/white"
app:layout_behavior=".behavior.BottomBehavior"/>
</android.support.design.widget.CoordinatorLayout>
好了，很簡單的布局，需要注意的是，這個的 RecycleView 也設置了一個 Behavior 哦，這個 Behavior 的使用我們在上一篇博客已經講過了哦。然后給我們的“底部導航欄設置一個 Behavior，使其在 RecycleView 向上滾動的時候能夠隱藏起來。直接貼代碼吧
public class BottomBehavior extends CoordinatorLayout.Behavior {
public BottomBehavior(Context context, AttributeSet attrs) {
super(context, attrs);
}
//依賴 AppBarLayout 的寫法
@Override
public boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) {
return dependency instanceof AppBarLayout;
}
@Override
public boolean onDependentViewChanged(CoordinatorLayout parent, View child, View dependency) {
int delta = dependency.getTop();
child.setTranslationY(-delta);
return true;
}
//-----------依賴 RecycleView 的寫法-----------
// @Override
// public boolean layoutDependsOn(CoordinatorLayout parent, final View child, View dependency) {
// boolean b = "Tag".equals(dependency.getTag());
// if (b && this.child == null) {
// this.child = child;
// ((RecyclerView) dependency).addOnScrollListener(mOnScrollListener);
// }
// return b;
// }
//
// View child;
// RecyclerView.OnScrollListener mOnScrollListener = new RecyclerView.OnScrollListener() {
// @Override
// public void onScrolled(RecyclerView recyclerView, int dx, int dy) {
// super.onScrolled(recyclerView, dx, dy);
// float translationY = child.getTranslationY();
// translationY += dy;
// translationY = translationY > 0 ? (translationY > child.getHeight() ? child.getHeight() : translationY) : 0;
// Log.e("translationY", translationY + "");
// child.setTranslationY(translationY);
// }
// };
}
這里我用了兩種實現方式，推薦使用第一種。因為第二種其實在 Activity 里面也是可以實現的。之所以講第二種寫法是因為，我們在layoutDependsOn里面是可以獲取到 CoordinatorLayout 里面所有child 的引用，直接 CoordinatorLayout.findViewWithTag()即可，然后我們可以為所欲為，哈哈哈，看實際需求吧。
Nested
Nested 機制要求 CoordinatorLayout 包含了一個實現了 NestedScrollingChild 接口的滾動控件，如 RecycleView、NestedScrollView、SwipeRefreshLayout等。然后我們 Behavior 里面的如下幾個方法會被回調哦~
onStartNestedScroll(View child, View target, int nestedScrollAxes)
onNestedPreScroll(View target, int dx, int dy, int[] consumed)
onNestedPreFling(View target, float velocityX, float velocityY)
onNestedScroll(View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed)
onNestedFling(View target, float velocityX, float velocityY, boolean consumed)
onStopNestedScroll(View target)
哦，對了，onStartNestedScroll 方法返回 ture表示要接受這個事件，后面的方法才會被調用哦。
看名字應該都能看得懂這些方法在哪里會被回調吧，好了，那我們來實現一個小 Demo 吧，看圖~
還是上面這個 Demo，xml 布局里面添加一個 FAB,給 FAB 設置一個 Tag，然后CoordinatorLayout.findViewWithTag()找到 FAB 的引用，onStarNestedScroll 返回 true 表示要接受這個事件，onNestedPreScroll 里面根據滾動的參數 dy 判斷是上滑還是下拉，然后調用 FAb 的 hide 和 show 方法即可。
public class BottomBehavior extends CoordinatorLayout.Behavior {
public BottomBehavior(Context context, AttributeSet attrs) {
super(context, attrs);
}
FloatingActionButton mFab;
@Override
public boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) {
if (mFab == null)
mFab = (FloatingActionButton) parent.findViewWithTag("FAB");
return dependency instanceof AppBarLayout;
}
@Override
public boolean onDependentViewChanged(CoordinatorLayout parent, View child, View dependency) {
int delta = dependency.getTop();
child.setTranslationY(-delta);
return true;
}
@Override
public boolean onStartNestedScroll(CoordinatorLayout coordinatorLayout, View child, View directTargetChild, View target, int nestedScrollAxes) {
return true;
}
@Override
public void onNestedPreScroll(CoordinatorLayout coordinatorLayout, View child, View target, int dx, int dy, int[] consumed) {
if (dy>10){
mFab.hide();
}else if (dy<-10){
mFab.show();
}
}
}
好了，寫完這幾個 Demo，Behavior 的知識點算是基本上講完了，可能有些同學還是一頭霧水。Wtah？這就講完了？ 我還沒學會定制那些牛逼的 Behavior動畫。
好吧，其實我也是先學了簡書、掘金上面好幾個熱門的 Behavior 應用，才開始研究源碼的。說實話，在寫這篇文章之前，我真的不會用 Behavior。
廢話說得有點多，沒講重點。那我先說重點吧，看懂了 Behavior 的原理再去看 Behavior 的 Demo 簡直不要太簡單。其實就是一些基本功底和一些屬性動畫的集成，讓就成了高大上的 Behavior 動畫。
來吧，分析幾個別人的 Behavior Demo。
分析之前先鄭重聲明：1、我沒有獲得作者的授權，如果覺得我侵權了，請聯系我。2、如果有評論措辭不當的地方還請多多包涵，僅代表個人觀點，不針對任何人。3、還沒想好，以后想到再添加
Demo1
原文地址：傳送門
我的項目中也用到了這個效果，當時我是基于 RecycleView 做了二次封裝實現的。蜜汁尷尬，看到前兩天學習 Behavior 的時候果斷重構了代碼。
Demo 實現分析：就是一個 AppBarLayout 使用了ScrollFlags 屬性實現了折疊效果，然后CollapsingToolbarLayout實現了圖片的視差滾動。關于 AppBarLayout 的使用請看我上一篇文章。然后再加了一個下拉放大的效果，這個需要我們自己定制。
1.繼承AppBarLayout.Behavior，在任意包含 CoordinatorLayout 的方法里面獲取使用 CoordinatorLayout.findViewWithTag()方法獲取到需要下拉放大的 ImageView，記得設置 ImageView 的ClipChildren屬性為 false。（不知道這個屬性功能的朋友自行找度娘或者 Google）
2.重新onNestedPreScroll，在這個方法里面去根據下拉距離Scale ImageView 即可。
3.手指松了之后還原，一個屬性動畫解決
4.沒有4了，已經實現，具體代碼去看別人的源碼吧，真的很容易實現，只是不知道的人不會而已。
Demo2
哈哈，是不是很酷炫，反正當時我看完之后感覺這一定是一個很酷炫的動畫。
不用，其實兩個 Behavior 就可以搞定了。
先來分析一下有哪些效果吧。
1.下拉放大封面圖片
2.上拉頭像跟著個人信息欄目往上走
3.上拉頭像縮小
4.個人信息欄和工具欄視差滾動
5.RecycleView 等其他欄目折疊完成再滾動
6.TabLayout 固定在頂部
實現：
1.參考上一個 Demo
2.給頭像設置layout_anchor屬性懸掛在某個控件上即可
3.給頭像設置一個 Behavior，使起 DependentAppBarLayout ，然后 Scale 即可。
4.給兩個 view 設置不同的layout_collapseParallaxMultiplier 系數即可，不知道這個屬性的回頭看我上一篇博客
5.給 RecycleView 設置AppBarLayout.ScrollingViewBehavior
6.可以放在 AppBarLayout 里面，layoutflag 不設置 scroll 屬性即可。
具體實現請參考源碼：傳送門
Demo3
傳送門
哈哈，大家自己去看吧，這些效果的實現用到的知識點我的 MaterialDesign系列都講過的。
另外，這幾個 Demo 以及我文中的那幾個 Demo，大家記得都去敲一遍代碼，敲了一篇就會了，真的，不騙你，
有話說
MaterialDesign 系列到這里就結束了，以后有時間再補充一下UI 篇吧。不過我這方面我也還是一知半懂的狀態，等以后有心得了會動筆的，這里我推薦扔物線的 HenCoder，我也在跟著學，業界良心之作，看完之后再也跟自定義 View 說 “No”，產品再也不會說“ 為什么 iOS 都實現了你們 Android 實現不了”。
