简介
MaterialDesign作为Android平台的应用设计规范，相信大家都有一定的了解，本文就以其中最为重要的一个控件CoordinatorLayout，结合源码做下剖析。阅读本文要求：1、熟悉Android控件绘制，2、了解动画，3、You`re a fucking kind person。本文所示源码版本是25.1.0。本文欢迎转载，不需要注明出处。
基本使用
CoordinatorLayout这个布局的作用，诚如其文档里描述的：
1.As a top-level application decor or chrome layout
2.As a container for a specific interaction with one or more child views
通常我们使用它来作为界面布局的根节点(本文中的“布局根节点”都指的布局文件中的)，用以实现MaterialDesign中的众多效果。
绘制流程
分析一个控件，自然少不了分析它的绘制流程，话不多说，现在就先来看看吧。
一、measure
protected void onMeasure(...) {
prepareChildren();
...
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 b = lp.getBehavior();
if (b == null || !b.onMeasureChild(...)) {
onMeasureChild(...);
}
...
}
...
setMeasuredDimension(width, height);
}其中mDependencySortedChildren其实是子控件集合，是由方法prepareChildren()初始化的；lp其实是一个CoordinatorLayout.LayoutParam对象，因为CoordinatorLayout有重写generateLayoutParams()、generateDefaultLayoutParams()、checkLayoutParams()方法；而接下来的关于Behavior的条件判断也很好理解，众所周知，ViewGroup类型的控件的测量过程有一个重要的任务，就是测量子控件的大小，在CoordinatorLayout中，我们可以看出，测量子控件这个任务是交由子控件的Behavior对象处理，而并不是子控件自身的onMeasure()方法，当然如果Behavior不处理，即Behavior.onMeasureChilde()返回false，才由CoordinatorLayout.onMeasureChiild()处理，而后者其实只是使用ViewGroup的逻辑；方法最后自然是要调用setMeasuredDimension()来设置CoordinatorLayout自身的大小。这里关于Behavior后文会有更详细的描述，同时你也许还会对mDependencySortedChildren集合有疑问，这个也放在后文描述。
二、layout
protected void onLayout(...) {
...
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(...)) {
onLayoutChild(child, layoutDirection);
}
}
}布局过程和测量过程一样，也是把子控件的布局逻辑优先交给Behavior处理。同上Behavior后文会有更详细的分析，这里暂且略过。那么就直接来看看CoordinatorLayout.onLayoutChild()是如何布局子控件的：
public void onLayoutChild(...) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
...
if (lp.mAnchorView != null) {
layoutChildWithAnchor(...);
} else if (lp.keyline >= 0) {
layoutChildWithKeyline(...);
} else {
layoutChild(...);
}
}方法里的3个layoutChildxxx()方法，功能都是一样的：计算子控件布局位置，调用child.layout()方法布局子控件。layoutChildWithAnchor()是根据锚控件确定位置，“锚控件”其实是CoordinatorLayout中的一种子控件间的依赖关系，这个在后文会的更详细的描述；layoutChild()是根据父控件确定位置；而layoutChildWithKeyline()则是根据keyline确定位置。前俩种方案，无论是锚控件还是父控件的位置都是已经确定了的，只要再结合其它如gravity、margin、padding等值能很好地计算出；那么接下来，我自然要解释下keyline是什么了。
keyline是MaterialDesign中一个非常好的布局解决方案，具体的定义可以参阅Keylines and spacing和Ratio keylines ，怎么使用我就不多赘述，这里我说说怎么实现这个特性的，不过，这里确有一个很大的遗憾：
private void layoutChildWithKeyline(...) {
...
int left = getKeyline(keyline) - childWidth;
int top = 0;
...
child.layout(left, top, left + childWidth, top + childHeight);
}
...
private int getKeyline(int index) {
...
return mKeylines[index];
}mKeylines数组存储就是在资源中定义好的keyline值，当然到这一步已经转换为像素了。而从int top = 0;可以看出来，我前面说的遗憾就是垂直方向的keyline并没有实现，相信大家在使用的时候就有所体会了，至于为什么，却是不得而知了。不过，即使CoordinatorLayout没有提供直接的解决方案，我们也是可以实现的。水平方向的用margin、padding；垂直方向可以用百分比布局。所以若界面设计真是以keyline布局的话，也是可以实现的。就目前而言，笔者认为keyline实为鸡肋。
三、draw
CoordinatorLayout的绘制过程就真没什么可以讲的了，还是延用着ViewGroup的绘制策略。
事件
关于事件分发的机制，在这里就不着笔墨了，我们还直接看看CoordinatorLayout是如何处理的吧。下面是事件拦截的逻辑：
private boolean performIntercept(...) {
...
getTopSortedChildren(topmostChildList);
// Let topmost child views inspect first
final int childCount = topmostChildList.size();
for (int i = 0; i < childCount; i++) {
...
if (!intercepted && b != null) {
switch (type) {
case TYPE_ON_INTERCEPT:
intercepted = b.onInterceptTouchEvent(...);
break;
case TYPE_ON_TOUCH:
intercepted = b.onTouchEvent(...);
break;
}
if (intercepted) {
mBehaviorTouchView = child;
}
}
...
}
...
return intercepted;
}显然CoordinatorLayout是否拦截事件，不是由自己决定的，也是交给Behavior处理。上面代码中的b就是子控件的Behavior对象。这里可以提前说下的是，Behavior的默认实现里onInterceptTouchEvent()与onTouchEvent()都返回false，也就是不拦截、不处理事件。getTopSortedChildren()的作用是对子控件排序，排序依据是子控件的elevation值，也就是控件的z轴的值。事件优先交给z值大的控件处理，并且一旦有子控件消费了事件，那么个事件就不会再传递给其它“更矮”的子控件了；这个消费了事件的子控件就叫mBehaviorTouchView。这个也正好契合MaterialDesign的设计理念。分析到这里，笔者多说下，关于这里排序的感受：前面说过在绘制过程中，CoordinatorLayout依然延用ViewGroup的绘制策略：根据布局文件自上而下，那为什么不和这里一样，根据elevation值来确定绘制顺序呢，不知各位又是何感想？好了，接下来看看onTouchEvent()方法：
public boolean onTouchEvent(MotionEvent ev) {
...
if (mBehaviorTouchView != null...) {
...
final LayoutParams lp = (LayoutParams) mBehaviorTouchView.getLayoutParams();
final Behavior b = lp.getBehavior();
if (b != null) {
handled = b.onTouchEvent(...);
}
}
// Keep the super implementation correct
if (mBehaviorTouchView == null) {
handled |= super.onTouchEvent(ev);
}
...
}在之前的performIntercept()方法里可以看到，事件只会被CoordinatorLayout的子控件拦截，所以，这里自然也是优先把事件传递给“拦截者”——mBehaviorTouchView处理了。
除了上面提到的这些方法外，CoordinantorLayout还实现了在5.0引入的嵌入滑动机制，不过关于这个机制，本文就不多赘述了。CoordinantorLayout重写了一系列的“onNested”方法，这里我只贴出一个，因为它们的逻辑大体都是相同的：
public boolean onStartNestedScroll(...) {
...
for (int i = 0; i < childCount; i++) {
...
viewBehavior.onStartNestedScroll(...);
...
}
...
}可以看出也是交给子控件的Behavior对象处理了。
以上便是CoordinatorLayout的绘制过程了，显然大部分逻辑都是交给Behavior处理了。
mDependencySortedChildren
我们知道，ViewGroup类型的控件把它的子控件都存储在了成员变量ViewGroup.mChildren这个数组中，这个数组中的元素，通常根据布局文件从上到下填充元素（其实是addView()方法）；而CoordinatorLayout定义了一个新的子控件集合，就是mDependencySortedChildren，填充这个集合时，需要依据子控件间的依赖关系。具体是个什么，来看看方法：
private void prepareChildren() {
...
for (int i = 0, count = getChildCount(); i < count; i++) {
final View view = getChildAt(i);
...
mChildDag.addNode(view);
...
for (int j = 0; j < count; j++) {
...
final LayoutParams otherLp = ...
if (otherLp.dependsOn(this, other, view)) {
...
mChildDag.addEdge(view, other);
}
}
}
// Finally add the sorted graph list to our list
mDependencySortedChildren.addAll(mChildDag.getSortedList());
// We also need to reverse the result since we want the start of the list to contain
// Views which have no dependencies, then dependent views after that
Collections.reverse(mDependencySortedChildren);
}上面就是在CoordinatorLayout的measure过程中调用的确定mDependencySortedChildren集合的方法。mDependencySortedChildren只是一个简单的线性表，子控件间的依赖关系其实是由mChildDag集合确定后，再给mDependencySortedChildren的。mChildDag的结构是一个有向无环图，这里笔者不会深入介绍这个结构的，就简要说明下便可：“edge”依赖于“node”，上面代码中第一层for循环把所有子控件添加到mChildDag中作为“node”，第二层for循环判断其它子控件与当前子控件是否存在依赖关系，若存在，就添加到对应“node”的“edge”中。依赖关系的确定是由方法CoordinatorLayout.LayoutParams.dependsOn()决定的：
boolean dependsOn(...) {
return dependency == mAnchorDirectChild
|| shouldDodge(...)
|| (...mBehavior.layoutDependsOn(...));
}判断依据一共有3种。第一种是锚控件判断，mAnchorDirectChild是当前子控件的锚控件；第二种“dodge”特性相信很少有人使用过，它指的控件间的规避策略，通过该特性可以实现类似于相对布局中的“align”特性，相关的布局属性有layout_insetEdge和layout_dodgeInsetEdges大家不妨去实际感受下，个人觉得是很不错的一个特性；第三种是由Behavior对象来判断的，下面是AppBarLayout.ScrollingViewBehavior.layoutDependsOn()方法：
public boolean layoutDependsOn(...) {
return dependency instanceof AppBarLayout;
}上面方法说明，所有指定Behavior对象为ScrollingViewBehavior的子控件都依赖于AppBarLayout。
回到prepareChildren()中，整个流程便是：由mChildDag先确定好依赖关系，再对其做拓扑排序，然后将结果添加到mDependencySortedChildren集合中，最后做下倒序。为何要做倒序，注释里也有说明，不过那是目的，原因在于上一步的拓扑排序，下面是DirectedAcyclicGraph中的排序方法：
private void dfs(final T node, final ArrayList<T> result, final HashSet<T> tmpMarked) {
if (result.contains(node)) {
// We've already seen and added the node to the result list, skip...
return;
}
if (tmpMarked.contains(node)) {
throw new RuntimeException("This graph contains cyclic dependencies");
}
// Temporarily mark the node
tmpMarked.add(node);
// Recursively dfs all of the node's edges
final ArrayList<T> edges = mGraph.get(node);
if (edges != null) {
for (int i = 0, size = edges.size(); i < size; i++) {
dfs(edges.get(i), result, tmpMarked);
}
}
// Unmark the node from the temporary list
tmpMarked.remove(node);
// Finally add it to the result list
result.add(node);
}在调用mChildDag.getSortedList()的时候，上面的排序方法会被调用到。不过，我这里只说结论，讲算法笔者不擅长。显然这是基于深度优先搜索的拓扑排序，最后得到的是一个去重后的线性序列，并且“edge”在“node”之前。但是我们必须先处理依赖项，比如，A依赖于B，则要先计算B的位置，才能计算A的位置。这就是上面做倒序的原因所在。
最后举个例子，如下图所示，EF依赖于D：
无论addView()先添加哪个控件，保存在mDependencySortedChildren集合中的顺序，D一定在EF之前，DEFBC是其中一种可能的顺序。
以上就是关于在CoordinatorLayout中新的子控件顺序的分析了，在CoordinatorLayout的measure和layout过程都是通过遍历mDependencySortedChildren来处理子控件的，这也就是说，在测量布局当前子控件时，它的依赖项已经先处理过了，如果有的话。关于有向无环图的拓扑排序，有兴趣的可以自己去找资料，就不在本文推荐了。
Behavior
通过上面的分析，我们知道，CoodinatorLayout的功能基本都是由Behavior实现的，这一节笔者就带大家来看看Behavior到底是什么东西。
测量
这里我以AppBarLayout.ScrollingViewBehavior为例，来说明Behavior测量CoordinatorLayout子控件的逻辑。请注意，本小节的说明都是基于为子控件指定的Behavior对象为ScrollingViewBehavior的情况。对于ScrollingViewBehavior而言，真正处理测量的方法在其父类HeaderScrollingViewBehavior中：
public boolean onMeasureChild(...) {
...
if (...) {
...
final View header = findFirstDependency(dependencies);
if (header != null) {
...
final int height = availableHeight - header.getMeasuredHeight()
+ getScrollRange(header);
...
parent.onMeasureChild(...);
return true;
}
}
return false;
}
上面方法中的findFirstDependency()查找到的其实就是AppBarLayout，也就是说header是一个AppBarLayout对象，availableHeight通常指的是CoordinatorLayout的高度，getScrollRange()是计算AppBarLayout的可滑动距离的。之所以要加上这个滑动距离，原因要结合布局过程说明，不过这里我可以告诉大家，不加的话，AppBarLayout滑动过程中，依赖于AppBarLayout的控件的布局位置会改变，这样CoordinatorLayout可能出现“留白”区域。下面来看下AppBarLayout的可滑动距离是如何计算的，跟踪进去会调用到AppBarLayout.getTotalScrollRange()方法：
public final int getTotalScrollRange() {
...
int range = 0;
for (int i = 0, z = getChildCount(); i < z; i++) {
...
final int flags = lp.mScrollFlags;
if ((flags & LayoutParams.SCROLL_FLAG_SCROLL) != 0) {
// We're set to scroll so add the child's height
range += childHeight + lp.topMargin + lp.bottomMargin;
...
} else {
...
}
}
return mTotalScrollRange = Math.max(0, range - getTopInset());
}上面代码中lp.mScrollFlags指的是为AppBarLayout的子控件指定的滑动方式，比如常给CollapsingToolbarLayout指定的布局属性app:layout_scrollFlags="scroll"。for循环中可以对range做累加，是因为AppBarLayout本身是一个LinearLayout的原故；计算可滑动距离，就是统计有哪些AppBarLayout的子控件是可以滑动的（由layout_scrollFlags判断）。
回到HeaderScrollingViewBehavior的测量子控件方法中，最后一步就是通过parent.onMeasureChild()来设置控件大小。
布局
同样这里我也以AppBarLayout.ScrollingViewBehavior为例，而且布局方法也在其父类HeaderScrollingViewBehavior中：
protected void layoutChild(...) {
...
available.set(..., header.getBottom() + lp.topMargin, ..., ...);
...
}上面代码被省略了很多，因为都不复杂，一些边检检测、gravity判断，很好理解；我挑出了我认为唯一需要说明的地方。header是AppBarLayout，available是一个Rect对象，指明控件在布局时的可使用空间，这里给定top值为header的bottom值，说明该子控件的位置在AppBarLayout的下方。为了实现AppBarLayout向上滑动时，子控件的bottom值不变，所以在测量过程时会加上AppBarLayout的可滑动距离。
事件及嵌入式滑动
本节我将以AppBarLayout.Behavior为例说明，这个是默认为AppBarLayout设置的Behavior。而把“事件”与“嵌入式滑动”这俩个内容放在一块讲，是因为在AppBarLayout.Behavior中，它们最终都会走到一个地方上去——滑动。
事件拦截及处理方法都在父类HeaderBehavior中，拦截事件的逻辑没什么好讲，下面是事件处理方法：
public boolean onTouchEvent(...) {
...
switch (MotionEventCompat.getActionMasked(ev)) {
...
case MotionEvent.ACTION_MOVE: {
...
if (mIsBeingDragged) {
...
scroll(...);
}
break;
}
case MotionEvent.ACTION_UP:
if (mVelocityTracker != null) {
...
fling(...);
}
...
}
...
}其它什么前置事件判断，滑动临界值检测等等步骤，我都略去了。可以说它们都是为上面的scroll()与fling()方法服务，不过现在暂时不作讲解。
接下来要说的是嵌入式滑动了，这些“onNestedXXX”方法，我列出其中重要的俩个：
public void onNestedScroll(...) {
if (dyUnconsumed < 0) {
...
scroll(...， minOffset, maxOffset);
...
}
...
}
public boolean onNestedFling(...) {
...
if (!consumed) {
...
flung = fling(...);
}
...
}笔者在剖析RecyclerView时有讲过，它的滑动分为scroll与fling两种。再看这里的滑动，如出一辙，也是分为scroll与fling，而且fling通过Scroller，最终也会进入scroll流程。在这里最终处理滑动的方法是AppBarLayout.Behavior.setHeaderTopBottomOffset()：
int setHeaderTopBottomOffset(...) {
...
setTopAndBottomOffset(interpolatedOffset);
...
}上面代码跟踪进入会调用到mViewOffsetHelper.setTopAndBottomOffset(offset);方法，mViewOffsetHelper是个工具类，提供方法View.offsetLeftAndRight()和View.offsetTopAndBottom()的兼容方案。它们的源代码我在这是就不分析了，作用就是平移控件。所以，AppBarLayout的滑动其实就是平移。
结束语
没什么好说的。
Written with StackEdit.
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
