CoordinatorLayout有一些很有意思的特性，设置anchor、NestedScroll配合Toolbar/TabLayout的显隐or伸缩、Fab的移动等。今天咱就来一探究竟！
CoordinatorLayout.LayoutParam中有一些不太一样的属性和元素，在此先进行介绍。
| 属性 | 对应xml属性 | 用途 |
|---|---|---|
AndchorId |
layout_anchor &layout_anchorGravity |
布局时根据自身gravity 与 layout_anchorGravity放置在被anchor的View中 |
Behavior |
layout_behavior |
辅助Coordinator对View进行layout、nestedScroll的处理 |
KeyLine |
layout_keyline & keylines |
给Coordinator设置了keylines（整数数组）后，可以为子View设置layout_keyline="i"使其的水平位置根据对应keylines[i]进行layout。 |
LastChildRect |
无 | 记录每一次Layout的位置，从而判断是否新的一帧改变了位置 |
注：
keyline是一个非常奇怪的属性，我在看源码时才第一次看到到这玩意，网上的资料也非常之少。分析下来，就是如果设置了keyline，那么gravity就会被无视，直接放置在对应的水平位置keyline上。CoordinatorLayout里面也没有其他的特性是根据keyline实现的，个人认为没卵用，本文对它的分析基本都会略过。
假设此时有两个View: A 和B，那么有两种情况会导致依赖关系：
- A的
anchor是B ； - A的
behavior对B有依赖（比如FloatingActionButton依赖SnackBar)。
依赖关系建立的前提是两个View在同一个Coordinatorlayout中。
CoordinatorLayout中维护了一个mDependencySortedChildren列表，里面含有所有的子View，按依赖关系排序，被依赖者排在前面。我们可以看一下用来排序的Comparator：
final Comparator<View> mLayoutDependencyComparator = new Comparator<View>() {
@Override
public int compare(View lhs, View rhs) {
if (lhs == rhs) {
return 0;
} else if (((LayoutParams) lhs.getLayoutParams()).dependsOn(
CoordinatorLayout.this, lhs, rhs)) {
return 1;
} else if (((LayoutParams) rhs.getLayoutParams()).dependsOn(
CoordinatorLayout.this, rhs, lhs)) {
return -1;
} else {
return 0;
}
}
};注意，在建立
mDependencySortedChildren并排序完成之后（在measure的第一步处理完成），每次对子View的遍历都是通过它进行顺序遍历，保证了被依赖的View最先被处理。
在CoordinatorLayout中定义了Behavior类，它是用来辅助layout的工具。如果一个CoordinatorLayout的直接子View设置了Behavior（或者通过类注解@DefaultBehavior指定Behavior），则该Behavior会储存在该View的LayoutParam中。
注意：不是CoordinatorLayout的直接子View，设置Behavior是无效的。你可以看到任何一处对于Behavior的处理都是直接
getChildCount（）遍历。
在Behavior中有几类功能，我们一一进行介绍：
Behavior中有两个函数：onInterceptTouchEvent、 onTouchEvent。在CoordinatorLayout每次触发对应事件的时候会选择一个最适合的子View的Behavior执行对应函数。我们来看一下CoordinatorLayout是怎么分发和处理Touch事件的：
intercept
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
MotionEvent cancelEvent = null;
final int action = MotionEventCompat.getActionMasked(ev);
// 重置响应的Behavoir
if (action == MotionEvent.ACTION_DOWN) {
resetTouchBehaviors();
}
// 在这里选择一个最佳Behavior进行处理
final boolean intercepted = performIntercept(ev, TYPE_ON_INTERCEPT);
if (cancelEvent != null) {
cancelEvent.recycle();
}
// 重置响应的Behavior
if (action == MotionEvent.ACTION_UP || action == MotionEvent.ACTION_CANCEL) {
resetTouchBehaviors();
}
return intercepted;
}在performIntercept去选择一个最适合的Behavior来进行处理，这个方法不仅用于onInterceptTouchEvent，并且也用于onTouchEvent，根据传入type不同来识别对应方法。我们来看看它的逻辑：
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;
// API>=21时，使用elevation由低到高排列View；API<21时，按View添加顺序排列
getTopSortedChildren(topmostChildList);
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();
// ...(省略代码) 如果此次判定intercept，则对上次的Behavior发送CANCEL事件。
// 根据传入type不同调用不同的方法
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;
}
}
//...(省略代码) 如果Behavior.blocksInteractionBelow()返回true，则不处理后续的事件。
}
topmostChildList.clear();
return intercepted;
}这部分比较简单，就俩函数：
layoutDependsOn：返回true则表示对另一个View有依赖关系；
onDependentViewChanged&onDependentViewRemoved：如果被依赖的View在正常layout之后仍有size/position上的变化，或者被remove掉，都会触发对应方法。
那么问题来了，CoordinatorLayout是怎么监听这个被依赖的View改变的事件的呢？
原来它里面有一个ViewTreeObserver.OnPreDrawListener，它在onMeasure的时候被添加到了ViewTreeObserver中，这样每一帧被绘制出来之前都会调用这个回调。
class OnPreDrawListener implements ViewTreeObserver.OnPreDrawListener {
@Override
public boolean onPreDraw() {
dispatchOnDependentViewChanged(false);
return true;
}
}这个dispatchOnDependentViewChanged里面代码比较多，就不放上来了，总结下来就是这样：
根据依赖关系遍历子View，对每一个View做如下操作
- 判断一下新的布局边界与lastChildRect是否相同，是则记录新的布局边界为lastChildRect，并继续后续流程，否则跳过；
- 对于之后每一个View，如果它依赖于本View，则调用它的
Behavior.onDependentViewChanged（如果有Behavior的话）。
至于onDependentViewRemoved，是在初始化的时候就会调用ViewGroup.setOnHierarchyChangeListener()方法设置一个OnHierarchyChangeListener，这样每次add和remove子View的时候就会接收到回调，同时对相应依赖关系的View进行处理。
onMeasureChild&onLayoutChild：如果重写了该方法并返回true，则CoordinatorLayout会使用Behavior对这个子View进行measure/layout。具体的可以见下面的Measure&Layout
CoordinatorLayout实现了NestedScrollingParent，当CoordinatorLayout内有一个支持NestedScroll的子View时，它的嵌套滑动事件通过NestedScrollingParent的回调分发到各直接子View的Behavior处理。虽然Behavior类没有实现NestedScrollingParent，但是实际上它的方法都有。有兴趣的同学可以去看看这个类，我们这里重点讲CoordinatorLayout的分发过程。
各个事件的分发过程类似，此处就举一个例子：
public boolean onStartNestedScroll(View child, View target, int nestedScrollAxes) {
boolean handled = false;
final int childCount = getChildCount();
for (int i = 0; i < childCount; i) {
final View view = getChildAt(i);
final LayoutParams lp = (LayoutParams) view.getLayoutParams();
final Behavior viewBehavior = lp.getBehavior();
if (viewBehavior != null) {
final boolean accepted = viewBehavior.onStartNestedScroll(this, view, child, target,
nestedScrollAxes);
handled |= accepted;
lp.acceptNestedScroll(accepted);
} else {
lp.acceptNestedScroll(false);
}
}
return handled;
}非常简单吧，就遍历一下直接子View，每个都调一下对应的回调方法，只要有任何一个子View的behavior消耗了这个事件，就算消耗了这个事件。
##2. Measure&Layout
我们知道，ViewGroup要把子View准确地放置到屏幕上都是要走onMeasure onLayout的，那么我们看看CoordinatorLayout在这里干了什么。
在看懂时请确保你明白measure/layout的意义以及基本用法，否则可能会导致身体不适=。=
最直接的就是看代码，如果不喜欢，可以跳过代码看总结。：
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
prepareChildren(); /* 解析依赖关系，并用1.2中提到的Comparator对View按依赖关系进行排序 */
ensurePreDrawListener(); /* 若PreDrawListener未添加，则添加到ViewTreeObserver */
//...(省略代码) 解析paddingmeasureSpec
final int childCount = mDependencySortedChildren.size();
for (int i = 0; i < childCount; i) {
final View child = mDependencySortedChildren.get(i);
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
//...(省略代码)处理keyline
int childWidthMeasureSpec = widthMeasureSpec;
int childHeightMeasureSpec = heightMeasureSpec;
//...(省略代码) 处理由于fitSystemWindows带来的padding
/* 如果childView有Behavior并且它的onMeasureChild返回true，则由behavior来对childView进行measure，否则就自己measure. */
final Behavior b = lp.getBehavior();
if (b == null || !b.onMeasureChild(this, child, childWidthMeasureSpec, keylineWidthUsed,
childHeightMeasureSpec, 0)) {
onMeasureChild(child, childWidthMeasureSpec, keylineWidthUsed,
childHeightMeasureSpec, 0);
}
/* 取最大的child width/height 加上margin 作为已经消耗的尺寸。 */
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));
}
/* 设置自身的measure尺寸 */
final int width = ViewCompat.resolveSizeAndState(widthUsed, widthMeasureSpec,
childState & ViewCompat.MEASURED_STATE_MASK);
final int height = ViewCompat.resolveSizeAndState(heightUsed, heightMeasureSpec,
childState << ViewCompat.MEASURED_HEIGHT_STATE_SHIFT);
setMeasuredDimension(width, height);
}总结下来，onMeasure干了这么几件事：
- 根据依赖关系对所有子View进行排序
- 保证OnPreDrawListener被添加
- 按依赖关系遍历子View:
- 如果子View有Behavior，并且它的
onMeasureChild返回true，则使用Behavior进行measure；否则直接使用measureSpec对子View进行measure； - 取子VIew最大的measure尺寸为已使用的measure尺寸。
- 如果子View有Behavior，并且它的
- 更新本身的Measure尺寸。
在onLayout中，我们可以看到CoordinatorLayout会对每一个子View依照以下判断顺序进行layout：
- 如果子View设置了
Behavior，并且该Behavior的behavior.onLayoutChild返回true，则使用behavior.onLayoutChild对该子View进行layout； - 如果Behavior不进行layout，则进入自身的
onLayoutChild()，内部依次进行如下判断：
- 如果子View设置了
Anchor，则调用layoutChildWithAnchor（根据anchor进行layout）； - 如果子View含有
keyline，则调用layoutChildWithKeyline（根据keyline进行layout）； - 如果以上判断都不符合，则直接将View根据padding/margin/measure结果按照
Gravity放置。
我们一一来看一下这些过程。
默认的Behavior的onLayoutChild都是返回false的，那么我们看看FloatingActionButton的默认Behavior是怎么处理的吧：
@Override
public boolean onLayoutChild(CoordinatorLayout parent, FloatingActionButton child,
int layoutDirection) {
// 检查该FAB是否依赖AppBarLayout
final List<View> dependencies = parent.getDependencies(child);
for (int i = 0, count = dependencies.size(); i < count; i) {
final View dependency = dependencies.get(i);
if (dependency instanceof AppBarLayout
&& updateFabVisibility(parent, (AppBarLayout) dependency, child)) {
break;
}
}
// 调用CoordinatorLayout的onLayoutChild对FAB进行layout
parent.onLayoutChild(child, layoutDirection);
// 在API < 21时，需要手动offset来让出阴影的位置
offsetIfNeeded(parent, child);
return true;
}这里主要是处理了如果FAB设置了AppBarLayout为anchor时（此时会对AppBarLayout有依赖），则当AppBarLayout的高度不足以显示FAB时将其隐藏）。
之后它会手动调用CoordinatorLayout自身的onLayoutChild方法进行layout，即上述判断的第二步，那我们继续往下看。
如果View设置了anchor，那么都会调用layoutWithAnchor进行layout，代码与解释如下：
private void layoutChildWithAnchor(View child, View anchor, int layoutDirection) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
final Rect anchorRect = mTempRect1;
final Rect childRect = mTempRect2;
/* 1. 找到被anchor的View的布局边界 */
getDescendantRect(anchor, anchorRect);
/* 2. 获取到被anchor的View布局边界之后，配合layout_anchorGravity与自身的gravity获取到最终要layout到的边界 */
getDesiredAnchoredChildRect(child, layoutDirection, anchorRect, childRect);
child.layout(childRect.left, childRect.top, childRect.right, childRect.bottom);
}这里用到的两个关键函数就是getDescendantRect与getDesiredAnchoredChildRect，它们的目的在我添加的注释中进行了解释，为保证文章的可读性就不再把代码放上来了，有兴趣的同学可以再自己去挖掘相应代码~~
如果之前的都不符合，就会走到这一步，我们看看它是怎么layout的：
private void layoutChild(View child, int layoutDirection) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
final Rect parent = mTempRect1;
parent.set(getPaddingLeft() lp.leftMargin,
getPaddingTop() lp.topMargin,
getWidth() - getPaddingRight() - lp.rightMargin,
getHeight() - getPaddingBottom() - lp.bottomMargin);
//...(省略代码) 处理由于fitsSystemWindows带来的inset
// 按照Gravity与measure尺寸在父控件里面找到自己的位置，并进行layout。
final Rect out = mTempRect2;
GravityCompat.apply(resolveGravity(lp.gravity), child.getMeasuredWidth(),
child.getMeasuredHeight(), parent, out, layoutDirection);
child.layout(out.left, out.top, out.right, out.bottom);
}##3 总结
CoordinatorLayout的特性总结下来就是两个方面：
- 可以设置anchor，被依赖的View变化自身也会变化；
- 可以设置behavior，当内部有支持嵌套滑动的控件时处理NestedScroll事件；
这两个特性导致的子View之间的依赖关系让界面的交互更有意思。有兴趣的同学可以再去看AppBarLayout、FloatingActionButton、SnackBar的源码~~