View的绘制流程

在进行实际的分析之前，我们先来看下面这张图：

我们来对上图做出简单解释：DecorView是一个应用窗口的根容器，它本质上是一个FrameLayout。DecorView有唯一一个子View，它是一个垂直LinearLayout，包含两个子元素，一个是TitleView（ActionBar的容器），另一个是ContentView（窗口内容的容器）。关于ContentView，它是一个FrameLayout（android.R.id.content)，我们平常用的setContentView就是设置它的子View。上图还表达了每个Activity都与一个Window（具体来说是PhoneWindow）相关联，用户界面则由Window所承载。

View绘制的起点

当建立好了decorView与ViewRoot的关联后，ViewRoot类的requestLayout()方法会被调用，以完成应用程序用户界面的初次布局。实际被调用的是ViewRootImpl类的requestLayout()方法，这个方法的源码如下：

1 2 3 4 5 6 7 8 9

@Override public void requestLayout() {   if (!mHandlingLayoutInLayoutRequest) {     // 检查发起布局请求的线程是否为主线程      checkThread();     mLayoutRequested = true;     scheduleTraversals();   } }

上面的方法中调用了scheduleTraversals()方法来调度一次完成的绘制流程，该方法会向主线程发送一个“遍历”消息，最终会导致ViewRootImpl的performTraversals()方法被调用。下面，我们以performTraversals()为起点，来分析View的整个绘制流程。

 

三个阶段

View的整个绘制流程可以分为以下三个阶段：

• measure: 判断是否需要重新计算View的大小，需要的话则计算；
• layout: 判断是否需要重新计算View的位置，需要的话则计算；
• draw: 判断是否需要重新绘制View，需要的话则重绘制。
  这三个子阶段可以用下图来描述：

measure阶段

此阶段的目的是计算出控件树中的各个控件要显示其内容的话，需要多大尺寸。起点是ViewRootImpl的measureHierarchy()方法，这个方法的源码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

private boolean measureHierarchy(final View host, final WindowManager.LayoutParams lp, final Resources res,     final int desiredWindowWidth, final int desiredWindowHeight) {   // 传入的desiredWindowXxx为窗口尺寸   int childWidthMeasureSpec;   int childHeightMeasureSpec;   boolean windowSizeMayChange = false;   . . .   boolean goodMeasure = false;     if (!goodMeasure) {     childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth, lp.width);     childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight, lp.height);     performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);       if (mWidth != host.getMeasuredWidth() || mHeight != host.getMeasuredHeight()) {       windowSizeMayChange = true;     }   }   return windowSizeMayChange; }

上面的代码中调用getRootMeasureSpec()方法来获取根MeasureSpec，这个根MeasureSpec代表了对decorView的宽高的约束信息。继续分析之前，我们先来简单地介绍下MeasureSpec的概念。
MeasureSpec是一个32位整数，由SpecMode和SpecSize两部分组成，其中，高2位为SpecMode，低30位为SpecSize。SpecMode为测量模式，SpecSize为相应测量模式下的测量尺寸。View（包括普通View和ViewGroup）的SpecMode由本View的LayoutParams结合父View的MeasureSpec生成。
SpecMode的取值可为以下三种：

• EXACTLY: 对子View提出了一个确切的建议尺寸（SpecSize）；
• AT_MOST: 子View的大小不得超过SpecSize；
• UNSPECIFIED: 对子View的尺寸不作限制，通常用于系统内部。

layout阶段

layout阶段的基本思想也是由根View开始，递归地完成整个控件树的布局（layout）工作。

View.layout()

我们把对decorView的layout()方法的调用作为布局整个控件树的起点，实际上调用的是View类的layout()方法

draw阶段

对于本阶段的分析，我们以decorView.draw()作为分析的起点，也就是View.draw()方法，它的源码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public void draw(Canvas canvas) {   . . .   // 绘制背景，只有dirtyOpaque为false时才进行绘制，下同   int saveCount;   if (!dirtyOpaque) {     drawBackground(canvas);   }     . . .     // 绘制自身内容   if (!dirtyOpaque) onDraw(canvas);     // 绘制子View   dispatchDraw(canvas);      . . .   // 绘制滚动条等   onDrawForeground(canvas);   }

简单起见，在上面的代码中我们省略了实现滑动时渐变边框效果相关的逻辑。实际上，View类的onDraw()方法为空，因为每个View绘制自身的方式都不尽相同，对于decorView来说，由于它是容器View，所以它本身并没有什么要绘制的。dispatchDraw()方法用于绘制子View，显然普通View（非ViewGroup）并不能包含子View，所以View类中这个方法的实现为空。

ViewGroup类的dispatchDraw()方法中会依次调用drawChild()方法来绘制子View，drawChild()方法的源码如下：

1 2 3

protected boolean drawChild(Canvas canvas, View child, long drawingTime) {   return child.draw(canvas, this, drawingTime); }

这个方法调用了View.draw(Canvas, ViewGroup，long)方法来对子View进行绘制。在draw(Canvas, ViewGroup, long)方法中，首先对canvas进行了一系列变换，以变换到将要被绘制的View的坐标系下。完成对canvas的变换后，便会调用View.draw(Canvas)方法进行实际的绘制工作，此时传入的canvas为经过变换的，在将被绘制View的坐标系下的canvas。

进入到View.draw(Canvas)方法后，会向之前介绍的一样，执行以下几步：

• 绘制背景;
• 通过onDraw()绘制自身内容;
• 通过dispatchDraw()绘制子View;
• 绘制滚动条

至此，整个View的绘制流程我们就分析完了。若文中有叙述不清晰或是不准确的地方，希望大家能够指出，谢谢大家：）

 

measure()、layout()、draw(),可以看这篇：http://www.cnblogs.com/jycboy/p/6066654.html