Android应用层View绘制流程与源码分析，墙都不扶就服你

可以看见，getChildMeasureSpec的逻辑是通过其父View提供的MeasureSpec参数得到specMode和specSize，然后根据计算出来的specMode以及子View的childDimension（layout_width或layout_height）来计算自身的measureSpec，如果其本身包含子视图，则计算出来的measureSpec将作为调用其子视图measure函数的参数，同时也作为自身调用setMeasuredDimension的参数，如果其不包含子视图则默认情况下最终会调用onMeasure的默认实现，并最终调用到setMeasuredDimension。

所以可以看见onMeasure的参数其实就是这么计算出来的。同时从上面的分析可以看出来，最终决定View的measure大小是View的setMeasuredDimension方法，所以我们可以通过setMeasuredDimension设定死值来设置View的mMeasuredWidth和mMeasuredHeight的大小，但是一个好的自定义View应该会根据子视图的measureSpec来设置mMeasuredWidth和mMeasuredHeight的大小，这样的灵活性更大，所以这也就是上面分析onMeasure时说View的onMeasure最好不要重写死值的原因。

可以看见当通过setMeasuredDimension方法最终设置完成View的measure之后View的mMeasuredWidth和mMeasuredHeight成员才会有具体的数值，所以如果我们自定义的View或者使用现成的View想通过getMeasuredWidth()和getMeasuredHeight()方法来获取View测量的宽高，必须保证这两个方法在onMeasure流程之后被调用才能返回有效值。

还记得前面《Android应用setContentView与LayoutInflater加载解析机制源码分析》文章3-3小节探讨的inflate方法加载一些布局显示时指定的大小失效问题吗？当时只给出了结论，现在给出了详细原因分析，我想不需要再做过多解释了吧。

至此整个View绘制流程的第一步就分析完成了，可以看见，相对来说还是比较复杂的，接下来进行小结。

2-2 measure原理总结

通过上面分析可以看出measure过程主要就是从顶层父View向子View递归调用view.measure方法（measure中又回调onMeasure方法）的过程。具体measure核心主要有如下几点：

• MeasureSpec（View的内部类）测量规格为int型，值由高2位规格模式specMode和低30位具体尺寸specSize组成。其中specMode只有三种值：

MeasureSpec.EXACTLY //确定模式，父View希望子View的大小是确定的，由specSize决定；

MeasureSpec.AT_MOST //最多模式，父View希望子View的大小最多是specSize指定的值；

MeasureSpec.UNSPECIFIED //未指定模式，父View完全依据子View的设计值来决定；

• View的measure方法是final的，不允许重载，View子类只能重载onMeasure来完成自己的测量逻辑。

• 最顶层DecorView测量时的MeasureSpec是由ViewRootImpl中getRootMeasureSpec方法确定的（LayoutParams宽高参数均为MATCH_PARENT，specMode是EXACTLY，specSize为物理屏幕大小）。

• ViewGroup类提供了measureChild，measureChild和measureChildWithMargins方法，简化了父子View的尺寸计算。

• 只要是ViewGroup的子类就必须要求LayoutParams继承子MarginLayoutParams，否则无法使用layout_margin参数。

• View的布局大小由父View和子View共同决定。

• 使用View的getMeasuredWidth()和getMeasuredHeight()方法来获取View测量的宽高，必须保证这两个方法在onMeasure流程之后被调用才能返回有效值。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】

3 View绘制流程第二步：递归layout源码分析

---

在上面的背景介绍就说过，当ViewRootImpl的performTraversals中measure执行完成以后会接着执行mView.layout，具体如下：

private void performTraversals() {

…

mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());

…

}

可以看见layout方法接收四个参数，这四个参数分别代表相对Parent的左、上、右、下坐标。而且还可以看见左上都为0，右下分别为上面刚刚测量的width和height。

至此又回归到View的layout(int l, int t, int r, int b)方法中去实现具体逻辑了，所以接下来我们开始分析View的layout过程。

整个View树的layout递归流程图如下：

3-1 layout源码分析

layout既然也是递归结构，那我们先看下ViewGroup的layout方法，如下：

@Override

public final void layout(int l, int t, int r, int b) {

…

super.layout(l, t, r, b);

…

}

看着没有？ViewGroup的layout方法实质还是调运了View父类的layout方法，所以我们看下View的layout源码，如下：

public void layout(int l, int t, int r, int b) {

…

//实质都是调用setFrame方法把参数分别赋值给mLeft、mTop、mRight和mBottom这几个变量

//判断View的位置是否发生过变化，以确定有没有必要对当前的View进行重新layout

boolean changed = isLayoutModeOptical(mParent) ?

setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);

//需要重新layout

if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {

//回调onLayout

onLayout(changed, l, t, r, b);

…

}

…

}

看见没有，类似measure过程，lauout调运了onLayout方法。

对比上面View的layout和ViewGroup的layout方法可以发现，View的layout方法是可以在子类重写的，而ViewGroup的layout是不能在子类重写的，言外之意就是说ViewGroup中只能通过重写onLayout方法。那我们接下来看下ViewGroup的onLayout方法，如下：

@Override

protected abstract void onLayout(boolean changed,

int l, int t, int r, int b);

看见没有？ViewGroup的onLayout()方法竟然是一个抽象方法，这就是说所有ViewGroup的子类都必须重写这个方法。所以在自定义ViewGroup控件中，onLayout配合onMeasure方法一起使用可以实现自定义View的复杂布局。自定义View首先调用onMeasure进行测量，然后调用onLayout方法动态获取子View和子View的测量大小，然后进行layout布局。重载onLayout的目的就是安排其children在父View的具体位置，重载onLayout通常做法就是写一个for循环调用每一个子视图的layout(l, t, r, b)函数，传入不同的参数l, t, r, b来确定每个子视图在父视图中的显示位置。

再看下View的onLayout方法源码，如下：

protected void onLayout(boolean changed, int left, int top, int right, int bottom) {

}

我勒个去！是一个空方法，没啥可看的。

既然这样那我们只能分析一个现有的继承ViewGroup的控件了，就拿LinearLayout来说吧，如下是LinearLayout中onLayout的一些代码：

public class LinearLayou