写在前面
今天和老爸去医院了，老爸最近腰疼，幸好没什么事，各位也要多多爱惜自己的身体，等身体出了问题就来不及了。好了，闲话到此为止，话说《开发艺术探索》里面不少东西我早就看了，但是因为自己当时水平有限，而且有很多也看不大懂，所以看了忘是挺正常的事。不过感觉随着工作经验的增长，以前大学里上过《操作系统》、《计算机网络》、《数据结构》等一些课都被串到了一起，感觉很好，而且愈发能感觉到自己的不足了。这周的文主要算是一篇读书笔记吧，记一下读《开发艺术探索》第四章和View相关的笔记，至于ViewGroup我觉得还需要过段时间，在沉淀一下再来和各位一起探索一下。而且说真的，这篇文我也是硬着头皮写下来的，因为看源码看着看着发现我疑问越来越多，很多都是现阶段暂时无法解决的，不过问题总是一个一个去解决的，先过一遍View的measure流程再说其他的。
ViewRoot & DecorView
ViewRoot对应于ViewRootImpl类，在ViewRootImpl类中有如下一段注释:
/**
* The top of a view hierarchy, implementing the needed
* protocol between View and the WindowManager.
*/
View层最顶部，实现了View和WindowManager间所需的协议。这个类很重要，但是我现在对其理解也不是很深（一是因为读源码无力，一是没有系统的阅读过源码），所以就拿书上的话来说：它是连接WindowManager和DecorView的纽带，View的三大流程均是通过ViewRoot来完成的。在ActivityThread中（同样很有意思的一点是ActivityThread是一个类，并非线程什么的，当然了如果哪一天我读通了这一块回来和各位分享的），当Activity对象被创建完毕后，会将DecorView添加到Window中，同时会创建ViewRootImpl对象，并将ViewRootImpl对象和DecorView建立关联。
接下来直接放结论，尽快进入正题：
View的绘制流程是从ViewRoot的performTraversals开始的，它经过measure、layout和draw三个过程才能最终将一个View绘制出来。
MeasureSpec
在之前Android自定义View你需要知道的一些东西中我已经简要的介绍过MeasureSpec了，当然在这不敢再麻烦各位去看了，继续简介一下，熟悉的可以跳过这段。
首先咱直接看他的注释，看看注释是怎么解释这玩意的：
/**
* A MeasureSpec encapsulates the layout requirements passed from parent to child.
* Each MeasureSpec represents a requirement for either the width or the height.
* A MeasureSpec is comprised of a size and a mode. There are three possible
* modes:
*
* - UNSPECIFIED
* -
* The parent has not imposed any constraint on the child. It can be whatever size
* it wants.
*
*
* - EXACTLY
* -
* The parent has determined an exact size for the child. The child is going to be
* given those bounds regardless of how big it wants to be.
*
*
* - AT_MOST
* -
* The child can be as large as it wants up to the specified size.
*
*
*
* MeasureSpecs are implemented as ints to reduce object allocation. This class
* is provided to pack and unpack the tuple into the int.
*/
最上面那段话的大概意思是一个MeasureSpec封装了一个从父（控件）传给子（控件）的布局要求。每个MeasureSpec代表的不是宽就是高的要求。一个MeasureSpec包含了一个尺寸和一个（测量）模式，这些模式如下：
UNSPECIFIED
父（容器）对子（控件）没有任何限制，子控件可以想要多大就有多大。EXACTLY
父容器已经决定了子控件的精确尺寸，子控件将会变成被给出的约束大小，不管他自己想要变成啥样。AT_MOST
子控件可以和和他想要的规格尺寸一样大。
最后一段话解释了一下为什么这么实现，暂时不需要咱关心这些。看完了注释基本上已经对MeasureSpec有了一个基本的认识了。但是看完这段注释，应该会产生一个疑惑，在注释中说MeasureSpec是父传递给子的，那么最顶层的DecorView的MeasureSpec是如何来的呢？《开发艺术探索》上说是在ViewRootImpl的measureHierarchy方法中创建的，主要代码如下：
childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth,lp.width);
childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight,lp.width);
performMeasure(childWidthMeasureSpec,childHeightmeasureSpec);
其中desiredWindowWidth和desiredWindowHeight就是屏幕的尺寸，追踪下getRootMeasureSpec()源码看看：
private static int getRootMeasureSpec(int windowSize, int rootDimension) {
int measureSpec;
switch (rootDimension) {
case ViewGroup.LayoutParams.MATCH_PARENT:
// Window can't resize. Force root view to be windowSize.
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY);
break;
case ViewGroup.LayoutParams.WRAP_CONTENT:
// Window can resize. Set max size for root view.
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
break;
default:
// Window wants to be an exact size. Force root view to be that size.
measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
break;
}
return measureSpec;
}
可以看到该方法中对于match_parent、wrap_content和其余情况的处理：
LayoutParams.MATCH_PARENT：采用精确模式测量，大小是窗口大小
LayoutParams.WRAP_CONTENT：大小不定，最大是窗口大小
其他：结合我们平时写xml和代码的经验，此处其他应该就是我们制定了大小（比如100dp），大小为指定大小。
View的MeasureSpec的获取
上面的MeasureSpec注释里说了，是从父传递到子的，那么View很明显是一个子布局，让我们上ViewGroup里找找child是如何获取MeasureSpec的：
/**
* Ask all of the children of this view to measure themselves, taking into
* account both the MeasureSpec requirements for this view and its padding.
* We skip children that are in the GONE state The heavy lifting is done in
* getChildMeasureSpec.
*
* @param widthMeasureSpec The width requirements for this view
* @param heightMeasureSpec The height requirements for this view
*/
protected void measureChildren(int widthMeasureSpec, int heightMeasureSpec) {
final int size = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < size; ++i) {
final View child = children[i];
if ((child.mViewFlags & VISIBILITY_MASK) != GONE) {
measureChild(child, widthMeasureSpec, heightMeasureSpec);
}
}
}
老规矩，先让我这个渣渣来翻译一下注释……
遍历View去测量他们自身，既要考虑MeasureSpec的要求又要考虑padding。跳过GONE状态的（不测量这个状态的View），更繁重的事在getChildMeasureSpec完成。
很明显，咱得看一下getChildMeasureSpec方法了:
/**
* Does the hard part of measureChildren: figuring out the MeasureSpec to
* pass to a particular child. This method figures out the right MeasureSpec
* for one dimension (height or width) of one child view.
*
* The goal is to combine information from our MeasureSpec with the
* LayoutParams of the child to get the best possible results. For example,
* if the this view knows its size (because its MeasureSpec has a mode of
* EXACTLY), and the child has indicated in its LayoutParams that it wants
* to be the same size as the parent, the parent should ask the child to
* layout given an exact size.
*
* @param spec The requirements for this view
* @param padding The padding of this view for the current dimension and
* margins, if applicable
* @param childDimension How big the child wants to be in the current
* dimension
* @return a MeasureSpec integer for the child
*/
public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
int specMode = MeasureSpec.getMode(spec);
int specSize = MeasureSpec.getSize(spec);
int size = Math.max(0, specSize - padding);
int resultSize = 0;
int resultMode = 0;
switch (specMode) {
// Parent has imposed an exact size on us
case MeasureSpec.EXACTLY:
if (childDimension >= 0) {
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size. So be it.
resultSize = size;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent has imposed a maximum size on us
case MeasureSpec.AT_MOST:
if (childDimension >= 0) {
// Child wants a specific size... so be it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size, but our size is not fixed.
// Constrain child to not be bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent asked to see how big we want to be
case MeasureSpec.UNSPECIFIED:
if (childDimension >= 0) {
// Child wants a specific size... let him have it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size... find out how big it should
// be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size.... find out how
// big it should be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
}
break;
}
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
咱继续翻译一下……
困难的事咱来做：算出MeasureSpec传递给
一个child。这个方法为一个子view的一个尺寸（高或宽）算出正确的MeasureSpec。
他的目的是组合MeasureSpec和LayoutParams的信息让child获取最好的可能结果。例如：如果这个view知道他的尺寸（因为测量模式是EXACTLY），这个child已经指出了他的LayoutParams，他想和他的父容器有一样的尺寸（match_parent），这时父容器应该要求child布局成被给的精确尺寸。
从上面的注释我们可以了解到，子View的MeasureSpec并不是由其自身的LayoutParams决定的，而是由其父容器和其自身的LayoutParams一同决定的。接下来看一下代码，看看究竟是怎么操作的：
首先从ViewGroup的宽/高的MeasureSpec中获取到对应的specMode，然后根据不同的mdoe去执行不同的操作
EXACTLY：如果子View指定了精确值的大小，那么测量模式是EXACTLY，尺寸是传入的childDimension，这两个值将会被打包成一个MeasureSpec并返回。如果childDimension等于MATCH_PARENT，那么就将上面获取到的自身尺寸和EXACTLY模式打包成一个MeasureSpec打包并返回。如果childDimension等于WRAP_CONTENT，那么将自身尺寸赋给孩子的尺寸，让子View的尺寸不要大于父容器就行了，将这个尺寸和AT_MOST模式打包并返回。
之后的AT_MOST和UNSPECIFIED测量模式和EXACTLY的套路差不多，就不一一看过去了，《Android开发艺术探索》上总结了一个表格：
|columns:childLayoutParams/rows:parentSpecMode|EXACTILY|AT_MOST|UNSPECIFIED
| ------------ |:-----------------: | ------: |
|dp/px|EXACTLY/childSize|EXACTLY/childSize|EXACTLY/childSize|
|match_parent|EXACTLY/parentSize|AT_MOST/parentSize|UNSPECIFIED/0|
|wrap_content|AT_MOST/parentSize|AT_MOST/parentSize|UNSPECIFIED/0|
最后要强调一句和《开发艺术探索》上一样的话，以上的表格并非是经验总结，而是将代码具现为一个表格罢了。
View的measure流程
终于填完了几个比较重要的坑，可以来讲讲View的measure流程了。View的测量是由measure()方法实现的 ，在measure()方法中会去调用onMeasure()方法，看一下View的onMeasure()方法的实现：
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}
关于这个方法有一些要注意的地方，在以前的Android自定义View你需要知道的一些东西都有说过，而且这个方法的注释里都有写你需要注意的东西，感兴趣的可以去看看，这里就不赘述了。以上方法调用了setMeasuredDimension方法设置View宽高，因此我们看一下他是如何获取宽高的就可以了，不多说，看源码：
public static int getDefaultSize(int size, int measureSpec) {
int result = size;
int specMode = MeasureSpec.getMode(measureSpec);
int specSize = MeasureSpec.getSize(measureSpec);
switch (specMode) {
case MeasureSpec.UNSPECIFIED:
result = size;
break;
case MeasureSpec.AT_MOST:
case MeasureSpec.EXACTLY:
result = specSize;
break;
}
return result;
}
看得出来，这里只是进行了一些简单的判断和赋值操作，如果测量模式是AT_MOST和EXACTLY：那么就返回View测量后的大小，如果是UNSPECIFIED模式那么就返回传入的size值。接下来看看传入的这个size值是怎么获取的：
protected int getSuggestedMinimumWidth() {
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}
从以上代码我们可以看出，如果view有背景则从最小宽度和background的宽度中返回较大的那个，如果没有背景则返回最小宽度，这个最小宽度我们可以通过xml或者setMinimumWidth来设置，默认为0。
接下来通过一个问题来回忆一下今天所了解的东西：在View中使用wrap_content为什么效果和match_parent效果一样？
首先这个问题需要去ViewGroup里看看，因为View的MeasureSpec是从ViewGroup中传递而来的，前面我们画的那张表格就是处理代码的具现，我们可以直接查表~
查表可知在match_parent和wrap_content这两种情况下传递给View的size都是parentSize（忽略UNSPECIFIED的情况），那么再看看View有没有对这两种情况做特殊的处理就行了。而在上面的getDefaultSize方法里可以看到AT_MOST和EXACTLY两种模式返回值都是相同的，因此在自定义继承于View的控件时需要我们去重写onMeasure()方法来处理wrap_content的情况。
读到这你可能会发现View和ViewGroup这俩货根本分不开，事实也是如此，但是在这我就不继续记我的笔记了，因为有些事我也没想明白，所以留待以后填坑吧（立了个flag）。
后记
还有一个ViewGroup的measure流程这里并没有继续了，想留着以后再来填这个坑吧。记得原来读《Android开发艺术探索》都是：“哦，原来是这样的” 状态，现在读则是会对一些代码的流程产生疑惑，而这些疑惑以我现在水平还是有些难以解决的。不过学习就是不断完善和不断有新的问题的过程，如同我们初中高中所学的物理一样，很多时候我们学到的只是相对正确的知识，但是在以后不断学习的过程中，我们可以不断的纠正自己以前的错误和带有局限的理解。