第四章：View的工作原理
4.1初认ViewRoot和DecorView
ViewRoot对应于ViewRootlmpl类，它是连接WindowManager和DecorView的纽带,View的三大流程均是通过ViewRoot来完成的。在ActivityThread中，当Activity对象被创建完毕后，会将DecorView 添加到Window 中，同时会创建ViewRootlmpl 对象，并将ViewRootlmpl对象和DecorView建立关联，这个过程可参看如下源码:
root=new ViewRootImpl(view.getContext(),display);
root.setView(view,wparams,panelParentView);
View的绘制流程是从ViewRoot的performTraversals 方法开始的，它经过measure. layout和draw三个过程才能最终将一个 View绘制出来，其中measure用来测量View的宽 和高，layout用来确定View在父容器中的放置位置,而draw则负责将View绘制在屏幕上。 针对performTraversals的大致流程，可用流程图4-1来表示。
UI界面架构：
UI界面架构：
- Activity都包含一个Window对象，通常由PhoneWindow来实现
- PhoneWindow将一个DecorView设置为整个应用窗口的根View
- DecorView为整个Window界面的最顶层View
- DecorView只有一个子元素为LinearLayout，代表整个Window界面，包含通知栏，标题栏，内容显示栏三块区域
- LinearLayout里有两个FrameLayout子元素：
- 标题栏显示界面。只有一个TextView显示应用的名称
- 内容栏显示界面。就是setContentView()方法载入的布局界面
在Activity中我们通过setContentView所设置的布局文件其实就是被添加到内容栏中的，而内容栏的id是content，因此可以理解为Activity指定布局的方法是setContentView，因为我们的布局的确加到了id为的FrameLayout 中。如何得到content 呢?可以这样: ViewGroup content= findViewById(R.android.id. content)。如何得到我们设置的View呢?可以这样: content. getChildAt(0)。同时，通过源码我们可以知道，DecorView 其实是- -个FrameLayout, View 层的事件都先经过DecorView,然后才传递给我们的View.
4.2 理解MeasuerSpec
MeasureSpec的确参与了View的measure过程。确切来说，MeasureSpec在很大程度上决定了一个View的尺寸规格,之所以说是很大程度上是因为这个过程还受父容器的影响，因为父容器影响View的MeasureSpec的创建过程。在测量过程中，系统会将View的LayoutParams根据父容器所施加的规则转换成对应的MeasureSpec,然后再根据这个measureSpec来测量出View的宽高。上面提到过， 这里的宽/高是测量宽高，不一定于View的最终宽/高。
4.2.1MeasuerSpec
MeasureSpec代表一个32位int值，高2位代表SpecMode,低30位代表SpecSize, SpecMode是指测量模式，而SpecSize 是指在某种测量模式下的规格大小。下面先看一下 MeasureSpecc内部的一些常量的定义，通过下面的代码，应该不难理解MeasureSpec的工作 原理:
public static class MeasureSpec {
private static final int MODE_SHIFT = 30;
private static final int MODE_MASK = 0x3 << MODE_SHIFT;
/** @hide */
@IntDef({UNSPECIFIED, EXACTLY, AT_MOST})
@Retention(RetentionPolicy.SOURCE)
public @interface MeasureSpecMode {}
/**
* Measure specification mode: The parent has not imposed any constraint
* on the child. It can be whatever size it wants.
*/
public static final int UNSPECIFIED = 0 << MODE_SHIFT;
/**
* Measure specification mode: 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.
*/
public static final int EXACTLY = 1 << MODE_SHIFT;
/**
* Measure specification mode: The child can be as large as it wants up
* to the specified size.
*/
public static final int AT_MOST = 2 << MODE_SHIFT;
/**
* Creates a measure specification based on the supplied size and mode.
*
* The mode must always be one of the following:
* <ul>
* <li>{@link android.view.View.MeasureSpec#UNSPECIFIED}</li>
* <li>{@link android.view.View.MeasureSpec#EXACTLY}</li>
* <li>{@link android.view.View.MeasureSpec#AT_MOST}</li>
* </ul>
*
* <p><strong>Note:</strong> On API level 17 and lower, makeMeasureSpec's
* implementation was such that the order of arguments did not matter
* and overflow in either value could impact the resulting MeasureSpec.
* {@link android.widget.RelativeLayout} was affected by this bug.
* Apps targeting API levels greater than 17 will get the fixed, more strict
* behavior.</p>
*
* @param size the size of the measure specification
* @param mode the mode of the measure specification
* @return the measure specification based on size and mode
*/
public static int makeMeasureSpec(@IntRange(from = 0, to = (1 << MeasureSpec.MODE_SHIFT) - 1) int size,
@MeasureSpecMode int mode) {
if (sUseBrokenMakeMeasureSpec) {
return size + mode;
} else {
return (size & ~MODE_MASK) | (mode & MODE_MASK);
}
}
/**
* Extracts the mode from the supplied measure specification.
*
* @param measureSpec the measure specification to extract the mode from
* @return {@link android.view.View.MeasureSpec#UNSPECIFIED},
* {@link android.view.View.MeasureSpec#AT_MOST} or
* {@link android.view.View.MeasureSpec#EXACTLY}
*/
@MeasureSpecMode
public static int getMode(int measureSpec) {
//noinspection ResourceType
return (measureSpec & MODE_MASK);
}
/**
* Extracts the size from the supplied measure specification.
*
* @param measureSpec the measure specification to extract the size from
* @return the size in pixels defined in the supplied measure specification
*/
public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}
}
SpecMode有三类：
- UNSPECIFIED 父容器不对View有任何限制，要多大给多大，这种情况一般用于系统内部(自定义view)，表示一种测量状态。
- EXACTLY 父容器已经检测出View所需要的精确大小，这个时候View的最终大小就是SpecSize 所指定的值。它对应于LayoutParams中的match_ parent和具体的数值这两种模式。
- AT_MOST 父容器指定了一个可用大小即SpecSize， View 的大小不能大于这个值，具体是什么 直要看不同View的具体实现。它对应于LayoutParams中的wrap_content.
4.2.2 MeasuerSpec和LayoutParams的对应关系
上面提到，系统内部是通过MeasureSpec来进行View的测量,但是正常情况下我们使 用View指定MeasureSpec,尽管如此，但是我们可以给View设置LayoutParams.在View 测量的时候，系统会将LayoutParams在父容器的约束下转换成对应的MeasureSpec,然后 再根据这个MeasureSpec来确定View测量后的宽/高。需要注意的是，MeasureSpec不是唯 一由LayoutParams决定的, LayoutParams需要和父容器一起才 能决定View的MeasureSpec, 从而进一步决定View的宽高。另外，对于顶级View (即DecorView)和普通View来说， MeasureSpec的转换过程略有不同。对于DecorView,其MeasureSpec由窗口的尺寸和其自 身的LayoutParams来共同确定:对于普通View,其MeasureSpec由父容器的MeasureSpec 和自身的LayoutParams来共同决定，MeasureSpec 一旦确定后，onMeasure 中就可以确定 View的测量宽高。
