CoordinateLayout onMeasure流程分析

先来看CoordinateLayout：

    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {        prepareChildren();        ensurePreDrawListener();        ...

开头就是两个关键方法 prepareChildren();和 ensurePreDrawListener();

 private void prepareChildren() {        mDependencySortedChildren.clear();        for (int i = 0, count = getChildCount(); i < count; i++) {            final View child = getChildAt(i);            final LayoutParams lp = getResolvedLayoutParams(child);            lp.findAnchorView(this, child);            mDependencySortedChildren.add(child);        }        // We need to use a selection sort here to make sure that every item is compared        // against each other        selectionSort(mDependencySortedChildren, mLayoutDependencyComparator);    }

先来看这个方法里的

    LayoutParams getResolvedLayoutParams(View child) {        final LayoutParams result = (LayoutParams) child.getLayoutParams();        if (!result.mBehaviorResolved) {            Class<?> childClass = child.getClass();            DefaultBehavior defaultBehavior = null;            while (childClass != null &&                    (defaultBehavior = childClass.getAnnotation(DefaultBehavior.class)) == null) {                childClass = childClass.getSuperclass();            }            if (defaultBehavior != null) {                try {                    result.setBehavior(defaultBehavior.value().newInstance());                } catch (Exception e) {                    Log.e(TAG, "Default behavior class " + defaultBehavior.value().getName() +                            " could not be instantiated. Did you forget a default constructor?", e);                }            }            result.mBehaviorResolved = true;        }        return result;    }

用反射的方法来解析注解生成behavior的实例，然后设置到LayoutParams里头并返回，这个处理的就是在类的头部用注解定义behavior的那种

@DefaultBehavior(MyBehavior.class)Class xxxxx{xxxx}

再来看
findAnchorView

        View findAnchorView(CoordinatorLayout parent, View forChild) {            if (mAnchorId == View.NO_ID) {                mAnchorView = mAnchorDirectChild = null;                return null;            }            if (mAnchorView == null || !verifyAnchorView(forChild, parent)) {                resolveAnchorView(forChild, parent);            }            return mAnchorView;        }

顾名思义，就是得到anchor标记的那个view了。比如在xml里头这样定义anchorapp:layout_anchor="@id/main.appbar",那么在LayoutParams构造方法里头就有相应的

     mAnchorId = a.getResourceId(R.styleable.CoordinatorLayout_LayoutParams_layout_anchor,View.NO_ID);

来获取相应的属性

来详细分析一下findAnchorView里头的函数

        /**         * Determine the anchor view for the child view this LayoutParams is assigned to.         * Assumes mAnchorId is valid.         */        private void resolveAnchorView(final View forChild, final CoordinatorLayout parent) {            mAnchorView = parent.findViewById(mAnchorId);//得到依赖的那个anchor view。。一句话就结束了。接下来就是对这个anchorview的合理性做检查            ....                View directChild = mAnchorView;                //肯定不能锚定coordinateLayout嘛                if (mAnchorView == parent) {                     throw new IllegalStateException(                            "View can not be anchored to the the parent CoordinatorLayout");                }                //沿着Anchorview的树向上检查                for (ViewParent p = mAnchorView.getParent();                        p != parent && p != null;                        p = p.getParent()) {                        //Anchor view也不能是依赖的view的子节点，要不然到底是谁决定谁呢？循环依赖了就                        if (p == forChild) {                        throw new IllegalStateException(                                "Anchor must not be a descendant of the anchored view");                        }                    }                    if (p instanceof View) {                        directChild = (View) p;                    }                }                mAnchorDirectChild = directChild;                //记录描定的那个孩子？？？            }         }

回到prepareChildren这个函数，我们找完了anchor的view并且记录在layoutparams里头之后，把view添加到mDependencySortedChildren这个ArrayList里头，并且紧接着进行排序
selectionSort(mDependencySortedChildren, mLayoutDependencyComparator);
顾名思义，就是一个选择排序，传入待排序数组和一个比较器。
先看一眼比较器：

    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;            }        }    };

如果左边view依赖右边就返回1，否则返回-1，就是按照依赖的顺序进行选择排序嘛。

看看那个依赖函数dependsOn的实现方式

        /**         * Check if an associated child view depends on another child view of the CoordinatorLayout.         *         * @param parent the parent CoordinatorLayout         * @param child the child to check         * @param dependency the proposed dependency to check         * @return true if child depends on dependency         */        boolean dependsOn(CoordinatorLayout parent, View child, View dependency) {            return dependency == mAnchorDirectChild                    || (mBehavior != null && mBehavior.layoutDependsOn(parent, child, dependency));        }

你看，之前保存的 mAnchorDirectChild就派上用场了，直接检查自己所保存的依赖的那个Anchor 的 view和当前传入的dependency是否一致，或者是在Behavior里头显式地重写layoutDependsOn来定义自己所依赖的view。

再看一样选择排序

    private static void selectionSort(final List<View> list, final Comparator<View> comparator) {        if (list == null || list.size() < 2) {            return;        }        final View[] array = new View[list.size()];        list.toArray(array);        final int count = array.length;        for (int i = 0; i < count; i++) {            int min = i;            for (int j = i + 1; j < count; j++) {                if (comparator.compare(array[j], array[min]) < 0) {//关键部分：比较器代码相应代码如下// if (((LayoutParams) rhs.getLayoutParams()).dependsOn(//                    CoordinatorLayout.this, rhs, lhs)) {//               return -1;//           }                    min = j;                }            }            if (i != min) {                // We have a different min so swap the items                final View minItem = array[min];                array[min] = array[i];                array[i] = minItem;            }        }        // Finally add the array back into the collection        list.clear();        for (int i = 0; i < count; i++) {            list.add(array[i]);        }    }}

当比较器的结果小于0的时候，就是右侧的参数依赖于左侧的那个参数，就返回-1，记录左侧的参数为min。综上，所以被依赖的view排在数组的前面，依赖他人的view排在数组的后面

总结起来，做完选择排序之后的mDependencySortedChildren会保证把被依赖的view排在最前面，而把依赖别人的view排在后面，第二次序才是view的添加次序（就是一开始被add加入mDependencySortedChildren的数组的次序）。

注意，这个mDependencySortedChildren是相当关键的一个数组，它成了后面几乎所有的遍历子view操作的那个顺序。其实也很好理解，对他人进行依赖的view必然是随着被依赖的那个view的变化而变化，那么我们自然要优先处理那个自变量，然后再处理因变量嘛。

接下来看
ensurePreDrawListener

    /**     * Add or remove the pre-draw listener as necessary.     */    void ensurePreDrawListener() {        boolean hasDependencies = false;        final int childCount = getChildCount();        //检查是否有依赖的存在        for (int i = 0; i < childCount; i++) {            final View child = getChildAt(i);            if (hasDependencies(child)) {                hasDependencies = true;                break;            }        }        if (hasDependencies != mNeedsPreDrawListener) {            if (hasDependencies) {                addPreDrawListener();            } else {                removePreDrawListener();            }        }    }

这段比较容易：检查是否有依赖的存在，有的话就调用addPreDrawListener(); 预绘制的监听器

    /**     * Add the pre-draw listener if we're attached to a window and mark that we currently     * need it when attached.     */    void addPreDrawListener() {        if (mIsAttachedToWindow) {            // Add the listener            if (mOnPreDrawListener == null) {                mOnPreDrawListener = new OnPreDrawListener();            }            final ViewTreeObserver vto = getViewTreeObserver();            vto.addOnPreDrawListener(mOnPreDrawListener);        }        // Record that we need the listener regardless of whether or not we're attached.        // We'll add the real listener when we become attached.        mNeedsPreDrawListener = true;    }

明显的，ViewTreeObserver加入一个监听器，在draw之前都会进行调用。那么自然是看看监听器到底写了什么鬼了

    class OnPreDrawListener implements ViewTreeObserver.OnPreDrawListener {        @Override        public boolean onPreDraw() {            dispatchOnDependentViewChanged(false);            return true;        }    }

跟踪关键函数，我们又到了一个重要的地方

    void dispatchOnDependentViewChanged(final boolean fromNestedScroll) {        final int layoutDirection = ViewCompat.getLayoutDirection(this);        final int childCount = mDependencySortedChildren.size();        for (int i = 0; i < childCount; i++) {            final View child = mDependencySortedChildren.get(i);//按照依赖的先后顺序取出子view！！            final LayoutParams lp = (LayoutParams) child.getLayoutParams();//取出子view的lp            // Check child views before for anchor            for (int j = 0; j < i; j++) {                final View checkChild = mDependencySortedChildren.get(j);//内循环，取出当前位置之前的所有的view（就是有可能对他们产生依赖的view，因为排在他前面嘛）                if (lp.mAnchorDirectChild == checkChild) {//如果是Anchor依赖                    offsetChildToAnchor(child, layoutDirection);//对当前view进行调整（我们知道anchor这种属性是随着被依赖的view变化的）                }            }            // Did it change? if not continue            //看看当前的view的Rect和上一次记录的Rect是否一致（就是上下左右四个值是不是一样啦）            final Rect oldRect = mTempRect1;            final Rect newRect = mTempRect2;            getLastChildRect(child, oldRect);//从这个view的LP里头得到上一次记录的这个view的Rect值，就是上下左右的值啦            getChildRect(child, true, newRect);            if (oldRect.equals(newRect)) {//比较是否有位置变化等                continue; //没变化就跳过后面步骤，直接检查下一个view的依赖            }            recordLastChildRect(child, newRect);//把View当前的Rect记录在这个view自己的LayoutParams里头（供下一次取出和比对）            // Update any behavior-dependent views for the change            //如果进行anchor调整之后，当前view发生了变化，那么就开始向后进行循环调整（处在后面的view都有可能对当前view产生依赖嘛）            for (int j = i + 1; j < childCount; j++) {                final View checkChild = mDependencySortedChildren.get(j);                final LayoutParams checkLp = (LayoutParams) checkChild.getLayoutParams();                final Behavior b = checkLp.getBehavior();                if (b != null && b.layoutDependsOn(this, checkChild, child)) {                //如果后面的view对当前view有依赖，那么要随着当前view的变化而变化                    if (!fromNestedScroll && checkLp.getChangedAfterNestedScroll()) {                        // If this is not from a nested scroll and we have already been changed                        // from a nested scroll, skip the dispatch and reset the flag                        checkLp.resetChangedAfterNestedScroll();                        continue;                    }                    final boolean handled = b.onDependentViewChanged(this, checkChild, child);//回调后面的view的onDependentViewChanged方法（自己依赖的view发生变化啦！）                    if (fromNestedScroll) {                        // If this is from a nested scroll, set the flag so that we may skip                        // any resulting onPreDraw dispatch (if needed)                        checkLp.setChangedAfterNestedScroll(handled);                    }                }            }        }    }

前面有段注释如是说：
* Usually run as part of the pre-draw step when at least one child view has a reported
* dependency on another view. This allows CoordinatorLayout to account for layout
* changes and animations that occur outside of the normal layout pass.
*
* It can also be ran as part of the nested scrolling dispatch to ensure that any offsetting
* is completed within the correct coordinate window.‘

这个函数除了用在这个绘制前监听之外，如果看看nestedScroll相关代码，里头也大量用到了这个函数。
总结一下上面这个函数，是为了处理anchor这个属性而存在的。从前到后以依赖的顺序取出子view，然后对每个view检查对前面的view是否存在anchor依赖，如果是就调整来配合anchor的view（offsetChildToAnchor函数）

在根据Anchor调整完毕之后，View位置大小就基本确定下来了，这个时候就接着检查这个view的lp所记录的Rect和当前的位置是否发生变化，如果是，那么就要遍历自己之后的元素看有没有元素依赖自己，有的话要回调他们相应的behavior.onDependentViewChanged 方法。

以上方法会在每次绘制前调用，保证了每个View变化的时候，依赖他的view能跟着一起变化

可以看到这个依赖的实现相当地粗暴简单，没有用到什么图论之类的知识，直接暴力循环了。。。

现在回到最最开始的onMeasure方法，我们上面搞了半天分析了两个函数
prepareChildren();
ensurePreDrawListener();

接下来继续向下分析onMeasure的相关部分

...        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(this, child, childWidthMeasureSpec, keylineWidthUsed,                    childHeightMeasureSpec, 0)) {                onMeasureChild(child, childWidthMeasureSpec, keylineWidthUsed,                        childHeightMeasureSpec, 0);            }       }

可以看到以依赖的先后顺序取出子view，并开始调用子view的lp的behavior的相应onMeasureChild，如果这里返回true，那么正常的onMeasureChild流程就不会进行调用了（被Behavior截取了嘛）

以上