标签： Android 源码解析 View
关于View的绘制流程，或者说 View 的工作流程（说绘制流程容易让人误解成 View 的 draw 流程）自己也在网上看过不少好文。但每当被问到具体的问题的时候，总感觉有很多知识还是模棱两可。因此本篇博客主要是用来梳理和总结相关知识。如果你也对View的绘制流程似懂非懂，不妨顺着我的思路看下去，希望你会有所收获。当然，任何不足、不当之处也请告诉我～
1.View 绘制流程的开始
当我们打开一个 Activity，呈现在我们面前的就已经是绘制好了的 View 了。在我们梳理 View 的绘制流程之前，不妨先思考一个问题：View是从什么时候／哪里开始被绘制的？
预备知识：
1.1 关于DecorView
DecorView 继承 FrameLayout，一般情况下包含一个 LinearLayout。而这个 LinearLayout 又包含一个 id 为 android.R.id.content 的 ViewGroup 和 一个titlebar (跟主题相关，也可能没有)。DecorView 也被称作顶级 View，也因此它是最先被绘制的。
1.2 关于ViewRootImpl
*注：这里涉及到的和 Window 及 WindowManager 相关知识不作过多解释。
ViewRootImpl 顾名思义，它是所有 View 的根，即整个 View 树的根节点。同时它也是连接WindowManager 和 DecorView 的纽带。但需要注意的是 ViewRootImpl 本身并不是一个 View 。有了这两点知识，我们可以回答最开始的问题了：View 的绘制流程是从 ViewRootImpl#performTravels 方法开始的。这个方法在 ActivityThread 被执行。performTravels 方法主要包含 measure,layout,draw 这三个过程。一般情况下这里的变量 mView 就是 DecorView。
private void performTraversals() {
//......
int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height); //......
mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
//......
mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
//......
mView.draw(canvas);
......
}
OK，一切的绘制都是从DecorView开始的啊。那么现在要绘制DecorView了，首先被执行的是它的measure方法，即确定DecorView的大小，那么 DecorView 的大小是如何确定的呢？
2.View 的 measure 过程
预备知识
2.1 关于MeasureSpec
MeasureSpec即测量规格，它是一个32位的int值，高2位代表SpecMode，低30位代表SpecSize。并提供了打包和拆包低方法。
测量模式有三种：
UNSPECIFIED
父视图不对子视图有任何约束，它可以达到所期望的任意尺寸。
EXACTLY
父视图为子视图指定一个确切的尺寸，而且无论子视图期望多大，它都必须在该指定大小的边界内，对应的属性为 match_parent 或具体值。
AT_MOST
父视图为子视图指定一个最大尺寸。子视图必须确保它自己所有子视图可以适应在该尺寸范围内，对应的属性为 wrap_content ，这种模式下，父控件无法确定子 View 的尺寸，只能由子控件自己根据需求去计算自己的尺寸。
理解了 MeasureSpec，我们就知道了要确定 DecorView 的大小，最先要做的事情就是要确定 DecorView 的 MeasureSpec。那么 DecorView 的 MeasureSpec 是如何确定的呢？让我们再回到 performTraversals 这个方法，根据源码可以看出，DecorView 的测量时所需要的两个 MeasureSpec 变量是根据 getRootMeasureSpec 方法得到的。同时，我们可以发现：DecorView 的 MeasureSpec 是由 windowSize 和 Window.LayoutParams 共同决定的。 具体规则如下：
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;
}
当 window 的 layout_width / layout_height 为 match_parent 时：
DecorView 的 size 即为 windowSize，其 mode 为 EXACTLY。
当 window 的 layout_width / layout_height 为 wrap_parent 时：
DecorView 的 size 是不确定的，但其 size 不能超过 windowSize 的大小，同时其 mode 为 AT_MOST。
当 window 的 layout_width / layout_height 为 default (即确定值)时 ：
DecorView 的 size 即为 Window.LayoutParams 中所指定宽高，同时其 mode 为 EXACTLY。
至此，DecorView 的两个 MeasureSpec 都已经拿到，一切都交由 DecorView 的 measure 方法去处理了。DecorView 是一个 FrameLayout，其 measure 方法继承的是 View 的 measure 方法，在 View 的 measure 方法中又会去调用 View 的 onMeasure 方法。而作为一个父 View 其大小在某些情况也与其子 View 有关，对于不同的 ViewGroup 来说，其 onMeasure 方法的实现也不相同。但在 ViewGroup 中提供了一些通用的测量子 View 的方法：measureChild , measureChildren , measureChildWithMargins。我们选取一个典型来看一下 measureChildWithMargins 这个方法：
protected void measureChildWithMargins(View child,
int parentWidthMeasureSpec, int widthUsed,
int parentHeightMeasureSpec, int heightUsed) {
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin
+ widthUsed, lp.width);
final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin
+ heightUsed, lp.height);
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
上述方法会对子元素进行 measure，在调用子元素的 measure 方法之前会先通过 getChildMeasureSpec 方法来得到子元素的 MeasureSpec 。根据方法参数来看，很显然，子元素的 MeasureSpec 的创建与父容器的 MeasureSpec 和子元素本身的 LayoutParams 有关，此外与父 View 的 padding 和子 View 的 margin 也有关。具体情况我们可以看一下 ViewGroup 的 getChildMeasureSpec 方法。
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 同时结合 View 本身的 LayoutParams 来确定子元素的 MeasureSpec。这里简单的阐述下该方法的逻辑：
当 View 的 layout_width / layout_height 是固定宽高的时候：
不管父容器的 MeasureSpec 是什么，View 的 mode 都是EXACTLY，size 遵循 LayoutParams 中的大小。
当 View 的 layout_width / layout_height 是 match_parent时：
如果父容器的 mode 是 EXACTLY，那么 View 的 mode 为 EXACTLY，size 是父 View 的剩余空间。
如果父容器的 mode 是 AT_MOST，那么 View 的 mode 也为 AT_MOST，size 为父 View 的剩余空间。
当 View 的 layout_width / layout_height 是 wrap_parent时：
无论父容器的 mode 是 EXACTLY 还是 AT_MOST ，View 的 mode 总为 AT_MOST，size 不能超过父 View 的剩余空间。
现在我们终于获得了子 View 的 MeasureSpec，这个时候 View 就需要开始测量自己本身了。
对于不同的 View 来说，一般都会重写 onMeasure 方法以便根据自己本身的内容和 MeasureSpec 来测量自己本身的宽高，最后调用 setMeasuredDimension 方法完成设置。为了简明起见，这里我们不妨看一下 View#onMeasure 方法的默认实现：
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(
getDefaultSize(getSuggestedMinimumWidth(),
widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(),
heightMeasureSpec)
);
}
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;
}
getDefaultSize 这个方法很好理解，在 AT_MOST 和 EXACTLY 模式下，getDefaultSize 返回的大小就是 measureSpec 中的 specSize。在 UNSPECIFIED 这中情况下，View 的大小为 getSuggestedMinimunWidth/Height的返回指。我们选取 getSuggestedMinimumWidth 看一下它的源码：
protected int getSuggestedMinimumWidth() {
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}
可见如果设置了 minWidth 属性，则为 mMinWidth。如果没有设置则跟 View 的 background 有关。我们再来看一下 Drawable#getMinimumWidth 方法：
public int getMinimumWidth() {
final int intrinsicWidth = getIntrinsicWidth();
return intrinsicWidth > 0 ? intrinsicWidth : 0;
}
可见，getMinimumWidth 返回的就是 Drawable 的原始宽度。当然这是在 Drawable 有原始宽度的情况下，否则就返回0。
小结
现在我们大致明白了整个 View 绘制流程中的 measure 过程。首先顶级 View —— DecorView 会根据 window.size 和 window.layoutParams 来测量自身，同时作为一个父 View 它还会确定子 View 的 measureSpec 参数，并将测量的流程传递给自己的子 View。接着，对于普通的 View 来讲，会根据 onMeasure 方法中具体实现的逻辑，并结合其父 View 提供的 measureSpec 和 自身的 LayoutParams 这两个参数完成自身的测量。最后会调用 setMeasuredDimension 方法来设置自身测量后的宽高。
3.View 的 layout 流程
根据之前的分析可知，View 的 layout 也是从 ViewRootImpl 中的 performTraversals 开始的。最先被调用的依然是 DecorView 的 layout 方法，那么 DecorView 是如何确定自己的位置的？在 ViewRootImpl#performTraversals 方法中，直接调用了 DecorView 的 layout 方法：
mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
这个里的 getMeasuredWidth / getMeasuredHeight 获取的正是在 measure 过程中测量后的宽高。我们再来看看 DecorView#layout 方法，由于 DecorView 继承自 ViewGroup ，DecorView#layout 方法也即是 ViewGroup#layout 方法：
@Override
public final void layout(int l, int t, int r, int b) {
if (!mSuppressLayout && (mTransition == null || !mTransition.isChangingLayout())) {
if (mTransition != null) {
mTransition.layoutChange(this);
}
super.layout(l, t, r, b);
} else {
// record the fact that we noop'd it; request layout when transition finishes
mLayoutCalledWhileSuppressed = true;
}
}
可见ViewGroup#layout 方法又调用 View#layout 方法，而 View#layout 方法的具体实现如下：
public void layout(int l, int t, int r, int b) {
if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) {
onMeasure(mOldWidthMeasureSpec, mOldHeightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
int oldL = mLeft;
int oldT = mTop;
int oldB = mBottom;
int oldR = mRight;
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
onLayout(changed, l, t, r, b);
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnLayoutChangeListeners != null) {
ArrayList<OnLayoutChangeListener> listenersCopy =
(ArrayList<OnLayoutChangeListener>)li.mOnLayoutChangeListeners.clone();
int numListeners = listenersCopy.size();
for (int i = 0; i < numListeners; ++i) {
listenersCopy.get(i).onLayoutChange(this, l, t, r, b, oldL, oldT, oldR, oldB);
}
}
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
}
整个 layout 方法会通过 setFrame 方法来设定 View 的四个顶点的位置，也即是 View 在父容器中的位置。在这里，对于 DecorView 来讲，其左上角的坐标为(0,0)，而其右下角的坐标则有其在 measure 过程中所确定的宽高来决定。
回到 View#setFrame 方法中，有这样几条语句：
mLeft = left;
mTop = top;
mRight = right;
mBottom = bottom;
上面说到，在 layout 方法中我们确定了 View 的四个定点。根据这四个顶点我们很容易计算出 View 的宽高:
public final int getWidth() {
return mRight - mLeft;
}
public final int getHeight() {
return mBottom - mTop;
}
看到这，可能就会有疑问：View 的宽高不是在 measure 过程中就已经确定了的吗？这里获得的宽高又是什么呢？或者说 getWidth / getHeight 和 getMeasuredWidth / getMeasuredHeight 有什么区别？
在一般情况下，View 的实际宽高和测量宽高是相等的，只不过这两者的形成时机不同。View 的测量宽高实在 View 的 measure 过程中确定的，而 View 的实际宽高是在 View 的 layout 过程中确定的。
在确定好自己的位置之后，同时作为一个父 View 的 DecorView 就会调用 onLayout 方法去布置自己的子 View 了。不同的 ViewGroup 其 onLayout 方法的实现也不同。这里我们来看看 DecorView ，即 FrameLayout 的具体实现。在 FrameLayout#onLayout 中，调用了 layoutChildren 方法：
@Override
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
layoutChildren(left, top, right, bottom, false /* no force left gravity */);
}
再来看看 FrameLayout#layoutChildren 这个方法：
void layoutChildren(int left, int top, int right, int bottom,
boolean forceLeftGravity) {
final int count = getChildCount();
final int parentLeft = getPaddingLeftWithForeground();
final int parentRight = right - left - getPaddingRightWithForeground();
final int parentTop = getPaddingTopWithForeground();
final int parentBottom = bottom - top - getPaddingBottomWithForeground();
for (int i = 0; i < count; i++) {
final View child = getChildAt(i);
if (child.getVisibility() != GONE) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
final int width = child.getMeasuredWidth();
final int height = child.getMeasuredHeight();
int childLeft;
int childTop;
int gravity = lp.gravity;
if (gravity == -1) {
gravity = DEFAULT_CHILD_GRAVITY;
}
final int layoutDirection = getLayoutDirection();
final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection);
final int verticalGravity = gravity & Gravity.VERTICAL_GRAVITY_MASK;
switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) {
case Gravity.CENTER_HORIZONTAL:
childLeft = parentLeft + (parentRight - parentLeft - width) / 2 +
lp.leftMargin - lp.rightMargin;
break;
case Gravity.RIGHT:
if (!forceLeftGravity) {
childLeft = parentRight - width - lp.rightMargin;
break;
}
case Gravity.LEFT:
default:
childLeft = parentLeft + lp.leftMargin;
}
switch (verticalGravity) {
case Gravity.TOP:
childTop = parentTop + lp.topMargin;
break;
case Gravity.CENTER_VERTICAL:
childTop = parentTop + (parentBottom - parentTop - height) / 2 +
lp.topMargin - lp.bottomMargin;
break;
case Gravity.BOTTOM:
childTop = parentBottom - height - lp.bottomMargin;
break;
default:
childTop = parentTop + lp.topMargin;
}
child.layout(childLeft, childTop, childLeft + width, childTop + height);
}
}
}
这里简单分析下 layoutChildren 的代码逻辑：
首先5～9行确定了父容器的边界，接着遍历所有的子元素，根据子元素的 Gravity 属性的不同来计算子元素左上角的位置即 childLeft 和 childTop 的值。最后，由于在之前的 measure 方法中我们已经确定了子元素的宽高，所以每个子元素所在的矩形区域也就相应的确定了。这里只需要调用子元素的 layout 方法，来确定子元素的位置，并将 layout 流程传递下去即可。
小结
到这里，View 的 layout 过程就完成了。layout 过程的作用是 ViewGroup 用来确定子元素的位置的。整个过程也是从 DecorView 开始的，DecorView 会根据自己在 measure 过程中计算出的 MeasuredWidth 和 MeasuredHeight 来确定自己的位置。同时 DecorView 作为一个 ViewGroup 也会负责去确定自己的子元素的位置，并将 layout 的流程传递下去。
3.View 的 Draw 流程
最后只剩下 View 的绘制过程了，整个过程比较简单。我们依然从 DecorView 开始分析。由于 ViewGroup 并没有重写 view#draw 方法，因此我们直接来看 view#draw 的原理
public void draw(Canvas canvas) {
/ * Draw traversal performs several drawing steps which must be executed
* in the appropriate order:
*
* 1. Draw the background if need
* 2. If necessary, save the canvas' layers to prepare for fading
* 3. Draw view's content
* 4. Draw children (dispatchDraw)
* 5. If necessary, draw the fading edges and restore layers
* 6. Draw decorations (scrollbars for instance)
*/
// Step 1, draw the background, if needed
if (!dirtyOpaque) {
drawBackground(canvas);
}
// skip step 2 & 5 if possible (common case)
final int viewFlags = mViewFlags;
if (!verticalEdges && !horizontalEdges) {
// Step 3, draw the content
if (!dirtyOpaque) onDraw(canvas);
// Step 4, draw the children
dispatchDraw(canvas);
// Step 6, draw decorations (scrollbars)
onDrawScrollBars(canvas);
if (mOverlay != null && !mOverlay.isEmpty()) {
mOverlay.getOverlayView().dispatchDraw(canvas);
}
// we're done...
return;
}
// Step 2, save the canvas' layers
...
// Step 3, draw the content
if (!dirtyOpaque)
onDraw(canvas);
// Step 4, draw the children
dispatchDraw(canvas);
// Step 5, draw the fade effect and restore layers
// Step 6, draw decorations (scrollbars)
onDrawScrollBars(canvas);
}
注释写的如此详细，看来有必要为之配图了：
这里我们再来看看 dispatchDraw 这个方法它是如何将 View 的绘制过程传递下去的。显然对于普通的 View 来讲，它只需要绘制好自身就可以了，因此 View#dispatchDraw 方法的实现为空。而作为 ViewGroup 在绘制自身的同时还需要将绘制流程传递给子元素。期中涉及到的相关方法如下：
dispatchDraw(Canvas canvas){
...
if ((flags & FLAG_RUN_ANIMATION) != 0 && canAnimate()) {
final boolean buildCache = !isHardwareAccelerated();
for (int i = 0; i < childrenCount; i++) {
final View child = children[i];
if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE) {
final LayoutParams params = child.getLayoutParams();
attachLayoutAnimationParameters(child, params, i, childrenCount);
bindLayoutAnimation(child);
if (cache) {
child.setDrawingCacheEnabled(true);
if (buildCache) {
child.buildDrawingCache(true);
}
}
}
}
final LayoutAnimationController controller = mLayoutAnimationController;
if (controller.willOverlap()) {
mGroupFlags |= FLAG_OPTIMIZE_INVALIDATE;
}
controller.start();
}
//draw children
for (int i = 0; i < childrenCount; i++) {
int childIndex = customOrder ? getChildDrawingOrder(childrenCount, i) : i;
final View child = (preorderedList == null)
? children[childIndex] : preorderedList.get(childIndex);
if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) {
more |= drawChild(canvas, child, drawingTime);
}
}
...
}
protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
return child.draw(canvas, this, drawingTime);
}
通过上面的源码我们也可以知道，在我们自定义 View 的时候，一般只需要去重写 View#onDraw 方法来绘制 View 的具体内容就可以了。而 View#draw 这个方法还帮我们做了很多其它的事情。
4.总结
Measure 过程
自上而下遍历，DecorView 根据 window.size 和 window.LayoutParams 这两个参数先确定自身的 MeasureSpec。同时作一个父 View 它会根据自身的 MeasureSpec 和子 View 的 LayoutParams 获取 ChildView 的 MeasureSpec，回调 ChildView.measure 方法，最终调用 setMeasuredDimension 得到 ChildView 的尺寸：mMeasuredWidth 和 mMeasuredHeight
Layout 过程
自上而下遍历，根据 Measure 过程中得到的每个 View 的 mMeasuredWidth 和 mMeasuredHeight 与计算得到的每个 ChildView 的 ChildLeft,ChildTop 进行布局：child.layout(left,top,left + width,top + height);
Draw 过程
自上而下遍历，父 View 除了绘制自身外，还需要将整个绘制过程传递给自己的子元素。
最后，整个 View 的绘制流程我们总结为如下一张流程图，需要说明的是，用户主动调用 request，只会出发 measure 和 layout 过程，而不会执行 draw 过程。
