前言
通过前面两个章节的学习，知道了Activity的生命周期函数的调用，和布局文件的加载。但是并没有看到View的绘制，那View的绘制是在什么时候的呢？
这边文章需要小伙伴们WindowManagerService(WMS) 相关知识所了解。
Window我们应该很熟悉，它是一个抽象类，具体的实现类为PhoneWindow，它对View进行管理。 WindowManager是一个接口类，继承自接口ViewManager，从名称就知道它是用来管理Window的，它的实现类为WindowManagerImpl。如果我们想要对Window进行添加和删除就可以使用WindowManager，具体的工作都是由WMS来处理的，WindowManager和WMS通过Binder来进行跨进程通信
在ActivityThread中会有一个handleResumeActivity()方法，而这个方法，也是Activity的onResume()方法的入口。但这个方法不单是调用了Activity的onResume()方法，它还设计到View的测量，布局，和绘制。
##ActivityThread
@Override
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
...
//调用Activity的onResume()方法
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
...
//获取到Activity对象
final Activity a = r.activity;
...
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow(); //获取PhoneWindow
View decor = r.window.getDecorView(); //获取DecorView
decor.setVisibility(View.INVISIBLE);
//WindowManagerImpl是ViewManager实现类
ViewManager wm = a.getWindowManager(); //1
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
...
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l); //2
} else {
...
}
}
...
} else if (!willBeVisible) {
if (localLOGV) Slog.v(TAG, "Launch " + r + " mStartedActivity set");
r.hideForNow = true;
}
...
}
注释1
获取到ViewManager对象，ViewManager是一个接口，WindowManager是他的一个子类，而WindowManagerImpl是WindowManager的实现类，所以这里其实真正获取到的是WindowManagerImpl，一路跟踪getWindowManager方法可以看到。WindowManagerImpl对象的作用是接替的WindowManager类的工作管理窗口。
注释2
##WindowManagerImpl
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
//mGlobal 是WindowManagerGlobal对象
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}
最终调用了WindowManagerGlobal的addView方法，可以看出WindowManagerImpl虽然是WindowManager的实现类，但是却没有实现什么功能，而是将功能实现委托给了WindowManagerGlobal，这里用到的是桥接模式。
为了帮助小伙伴们的理解，这里再给大家补充一张Window和WindowManager的关系图。
接下来，再来看看WindowManagerGlobal的addView()方法到底做了哪些事情。
##WindowManagerGlobal
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
...
ViewRootImpl root;
View panelParentView = null;
...
root = new ViewRootImpl(view.getContext(), display); //1
view.setLayoutParams(wparams); //2
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// do this last because it fires off messages to start doing things
try {
root.setView(view, wparams, panelParentView); //3
} catch (RuntimeException e) {
// BadTokenException or InvalidDisplayException, clean up.
if (index >= 0) {
removeViewLocked(index, true);
}
throw e;
}
}
}
注释1
创建ViewRootImpl对象，ViewRootImpl身负了很多职责：
- View树的根并管理View树
- 触发View的测量、布局和绘制
- 输入事件的中转站
- 管理Surface
- ViewRootImpl对象是链接WMS和DecorView的纽带
注释2
view指的是DecorView，这里是设置DecorView的LayoutParams，而这个LayoutParams是WindowManager.LayoutParams也就是当前窗口的布局参数，如当前窗口的宽高。
注释3，ViewRootImpl对象与DecorView 对象关联。
##ViewRootImpl
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
mView = view;
...
// Schedule the first layout -before- adding to the window
// manager, to make sure we do the relayout before receiving
// any other events from the system.
requestLayout(); //1
...
try {
...
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(), mWinFrame,
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel); //2
} catch (RemoteException e) {
...
throw new RuntimeException("Adding window failed", e);
} finally {
if (restore) {
attrs.restore();
}
}
...
}
}
}
setView方法中有很多逻辑，这里只截取了一小部分，主要就是调用了requestLayout()，和mWindowSession的addToDisplay方法。mWindowSession的addToDisplay()方法将在下个章节给大家介绍。本章主要分析requestLayout()
View的测量，布局，绘制
##ViewRootImpl
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread(); //1
mLayoutRequested = true;
scheduleTraversals(); //2
}
}
注释1，检测当前线程是否是主线程，不是抛出异常
注释2，遍历View树
##ViewRootImpl
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); //1
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
注释1调用 postCallback方法的调用，内部代码实现的逻辑是使用Handler对象来发送消息。而在postCallback方法的参数中mTraversalRunnable对象是一个Runnable对象。由此可见，这里具体的业务代码是存在mTraversalRunnable对象的run方法中。
##ViewRootImpl.TraversalRunnable
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
##ViewRootImpl
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
if (mProfile) {
Debug.startMethodTracing("ViewAncestor");
}
performTraversals(); //1
if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}
注释1：真证开始执行View树的遍历
##ViewRootImpl
private void performTraversals() {
// cache mView since it is used so much below...
final View host = mView; //mView是DecorView对象
...
if (mFirst || windowShouldResize || insetsChanged ||
viewVisibilityChanged || params != null || mForceNextWindowRelayout) {
...
if (!mStopped || mReportNextDraw) {
...
if (focusChangedDueToTouchMode || mWidth != host.getMeasuredWidth()
|| mHeight != host.getMeasuredHeight() || contentInsetsChanged ||
updatedConfiguration) {
//获取根布局的测量规格
int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);
...
// Ask host how big it wants to be
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec); //1
...
}
}
} else {
...
}
final boolean didLayout = layoutRequested && (!mStopped || mReportNextDraw);
boolean triggerGlobalLayoutListener = didLayout
|| mAttachInfo.mRecomputeGlobalAttributes;
if (didLayout) {
performLayout(lp, mWidth, mHeight); //2
...
}
...
if (!cancelDraw && !newSurface) {
...
performDraw(); //3
} else {
...
}
...
}
performTraversals方法很长，主要关注的是三个方法，performMeasure方法对View的测量，performLayout方法View的布局，performDraw方法View的绘制。
注释1 View的测量
在performMeasure方法中，会传入两个参数，是指传入宽高的测量规格。这两个参数其实都是通过调用getRootMeasureSpec方法来获取的。
##ViewRootImpl
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;
}
在getRootMeasureSpec方法中，传入了两个参数，第一个是当前窗口的大小（宽或高），第二步是根布局的尺寸规则（如：match_parent或wrap_content分别用-1和-2表示）。根据尺寸规则获取根测量规格。
打开MeasureSpec类
##View.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 {}
/**
* UNSPECIFIED 模式：
* 父View不对子View有任何限制，子View需要多大就多大
*/
public static final int UNSPECIFIED = 0 << MODE_SHIFT;
/**
* EXACTYLY 模式：
* 父View已经测量出子Viwe所需要的精确大小，这时候View的最终大小
* 就是SpecSize所指定的值。对应于match_parent和精确数值这两种模式
*/
public static final int EXACTLY = 1 << MODE_SHIFT;
/**
* AT_MOST 模式：
* 子View的最终大小是父View指定的SpecSize值，并且子View的大小不能大于这个值，
* 即对应wrap_content这种模式
*/
public static final int AT_MOST = 2 << MODE_SHIFT;
//将size和mode打包成一个32位的int型数值
//高2位表示SpecMode，测量模式，低30位表示SpecSize，某种测量模式下的规格大小
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);
}
}
//将32位的MeasureSpec解包，返回SpecMode,测量模式
@MeasureSpecMode
public static int getMode(int measureSpec) {
//noinspection ResourceType
return (measureSpec & MODE_MASK);
}
//将32位的MeasureSpec解包，返回SpecSize，某种测量模式下的规格大小
public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}
...
/**测量模式
EXACTLY ：父容器已经测量出所需要的精确大小，这也是childview的最终大小
------match_parent，精确值是父View宽高
ATMOST : child view最终的大小不能超过父容器的给的
------wrap_content 精确值不超过父View宽高
UNSPECIFIED: 不确定，源码内部使用
-------一般在ScrollView，ListView
**/
}
这里会出现一个MeasureSpec对象是Android view测量系统的重要的一个元素，内部维持着是一个32位的int值，高两位代表测量模式SpecMode（MeasureSpec.EXACTLY、MeasureSpec.AT_MOST、MeasureSpec.UNSPECIFIED ），低30位代表测量的大小SpecSize，MeasureSpec用一个int值同时存放了两个信息，一是在onMeasure中根据这个MeasureSpec来确定view的测量宽高，二可以节省内存的开销。
三个主要的方法
makeMeasureSpec()--负责打包mode和size
getMode()--负责解析得到mode部分
getSize()--负责解析得到size部分
那么makeMeasureSpec方法中第一个参数传递的是一个窗口的size，第二个参数是几种测量模式：EXACTLY ,ATMOST ,UNSPECIFIED这三个模式的本质是0,1,2的左位移30位，
那么其实我们先能理解为我们实际上在传递值得过程当中将显示模式+size打包一起交给measure方法
而里面的数据结构其实实际上是一个32位的数值，
我们可以明显看到几个模式的值在后面进行了左位移操作了30位
用MODE_SHIFT 操作之后，实际表明一个32位的值30前两位作为MODE
而MODE_MASK 表示是后30位
所以现在能得出一个结论他们的数据构可以看成是
而这个时候我们看到有三个方法负责打包解析
makeMeasureSpec--负责打包mode和size
getMode--负责解析得到mode部分
getSize--负责解析得到size部分
那么打包时运用了(size & ~MODE_MASK) | (mode & MODE_MASK)的算法进行混合,那么这里我们可以认为 是size 转化成32位后放入后30位 组合 mode（mode放入前两位）
getMode解析用了measureSpec & MODE_MASK(解析只要前2位)
getSize解析用了measureSpec & ~MODE_MASK（不要前两位）
那么此处就可以得到，在测量时他真正的给我传递的是规格，而所谓的规格只不过是显示模式+实际宽高的一个数据包，或者你理解为这个值当中包含模式和具体数值就行了
所以我们得出一个结论，View的测量流程中，通过makeMeasureSpec来保存宽高信息，在其他流程通过getMode或getSize得到模式和宽高。那么问题来了，上面提到MeasureSpec是子容器和父容器的模式所共同影响的，那么，对于DecorView来说，它已经是顶层view了，没有父容器，那么它的MeasureSpec怎么来的呢？ 是否还记得我们的setContent所加载的系统布局？
我们的初始就已经给了一个布局去装载，所以，在这里，他的父布局是系统布局。
那么到目前为止，就已经获得了一份DecorView的MeasureSpec，它代表着根View的规格、尺寸，在接下来的measure流程中，就是根据已获得的根View的MeasureSpec来逐层测量各个子View。来到performMeasure方法，看看它做了什么工作。
##ViewRootImpl
private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) {
if (mView == null) {
return;
}
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "measure");
try {
mView.measure(childWidthMeasureSpec, childHeightMeasureSpec); //1
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
注释1这里很明显他直接调用搞得是view的measure这里的mView就是DecorView，也就是说，从顶级View开始了测量流程。
##View
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
...
if (forceLayout || needsLayout) {
...
int cacheIndex = forceLayout ? -1 : mMeasureCache.indexOfKey(key);
if (cacheIndex < 0 || sIgnoreMeasureCache) {
// measure ourselves, this should set the measured dimension flag back
onMeasure(widthMeasureSpec, heightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
} else {
...
}
...
}
...
}
可以看到，它在内部调用了onMeasure方法。那么注意，到此为止，我们的布局容器的核心就在这里了，不管是LinearLayout或者是FreamLayout还是其他布局容器（ViewGroup），他们都是通过测量组件，实现View的大小测量，每一个布局容器（ViewGroup）的onMeasure实现都不一样，这里因为顶层DecorView是一个FreamLayout。以FrameLayout为例。
举例
##FrameLayout
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
//获取当前布局内的子View数量
int count = getChildCount();
/**
* 判断当前布局的宽高是否是MATCH_PARENT模式或者指定一个精确的大小，如果是则置
* measureMatchParent为false.
*
* 也就是当前FrameLayout,为WRAP_CONTENT时为true
*/
final boolean measureMatchParentChildren =
MeasureSpec.getMode(widthMeasureSpec) != MeasureSpec.EXACTLY ||
MeasureSpec.getMode(heightMeasureSpec) != MeasureSpec.EXACTLY;
mMatchParentChildren.clear();
int maxHeight = 0;
int maxWidth = 0;
int childState = 0;
//遍历所有类型不为GONE的子View
for (int i = 0; i < count; i++) {
final View child = getChildAt(i);
if (mMeasureAllChildren || child.getVisibility() != GONE) {
//对每一个子View进行测量,传入子View和父容器的宽高规格
measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0); //1
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
/**
* 寻找子View中宽高的最大者，因为如果FrameLayout是wrap_content属性
* 那么它的大小取决于子View中的最大者
*/
maxWidth = Math.max(maxWidth,
child.getMeasuredWidth() + lp.leftMargin + lp.rightMargin);
maxHeight = Math.max(maxHeight,
child.getMeasuredHeight() + lp.topMargin + lp.bottomMargin);
childState = combineMeasuredStates(childState, child.getMeasuredState());
/**
* 如果FrameLayout是WRAP_CONTENT模式，那么往mMatchParentChildren中添加
* 宽或者高为match_parent的子View，因为该子View的最终测量大小会受到FrameLayout的最终测量大小影响
*/
if (measureMatchParentChildren) {
if (lp.width == LayoutParams.MATCH_PARENT ||
lp.height == LayoutParams.MATCH_PARENT) {
mMatchParentChildren.add(child);
}
}
}
}
...
//保存测量结果
setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),
resolveSizeAndState(maxHeight, heightMeasureSpec,
childState << MEASURED_HEIGHT_STATE_SHIFT));
/**
* 子View中设置为WRAP_CONTENT的个数
*
* 只有FrameLayout的模式为wrap_content的时候才会执行下列语句 if (count > 1)
* 如果存在count>1，mMatchParentChildren中添加的子View设置为MATCH_PARENT或者
* 精确数据
*/
count = mMatchParentChildren.size();
if (count > 1) {
for (int i = 0; i < count; i++) {
final View child = mMatchParentChildren.get(i);
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
//对FrameLayout的宽度规格设置，因为这会影响子View的测量
final int childWidthMeasureSpec;
/**
* 如果子View的宽度是match_parent属性，那么对当前View的宽度规格修改为:
* 总宽度（父布局宽） - padding - margin，这样做的意思是：
* 对于子Viw来说，如果要match_parent，那么它可以覆盖的范围是父布局的宽度
* 减去padding和margin后剩下的空间。childWidthMeasureSpec是FrameLayout的中子View的规格
*
* 如果子View的宽度是一个确定的值，比如100dp，那么FrameLayout中childWidthMeasureSpec的宽度规格修改为：
* View的宽度，即100dp，SpecMode为EXACTLY模式
*/
if (lp.width == LayoutParams.MATCH_PARENT) {
final int width = Math.max(0, getMeasuredWidth()
- getPaddingLeftWithForeground() - getPaddingRightWithForeground()
- lp.leftMargin - lp.rightMargin);
childWidthMeasureSpec = MeasureSpec.makeMeasureSpec(
width, MeasureSpec.EXACTLY);
} else {
childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec,
getPaddingLeftWithForeground() + getPaddingRightWithForeground() +
lp.leftMargin + lp.rightMargin,
lp.width);
}
//同理对高度进行相同的处理
final int childHeightMeasureSpec;
if (lp.height == LayoutParams.MATCH_PARENT) {
final int height = Math.max(0, getMeasuredHeight()
- getPaddingTopWithForeground() - getPaddingBottomWithForeground()
- lp.topMargin - lp.bottomMargin);
childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(
height, MeasureSpec.EXACTLY);
} else {
childHeightMeasureSpec = getChildMeasureSpec(heightMeasureSpec,
getPaddingTopWithForeground() + getPaddingBottomWithForeground() +
lp.topMargin + lp.bottomMargin,
lp.height);
}
//对于这部分的子View需要重新进行measure过程
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
}
}
onMeasure方法总结：首先，FrameLayout根据它的测量规则来对每一个子View进行测量，即调用measureChildWithMargin方法，这个方法下面会详细说明；对于每一个测量完成的子View，会寻找其中最大的宽高，那么FrameLayout的测量宽高会受到这个子View的最大宽高的影响(wrap_content模式)，接着调用setMeasureDimension方法，把FrameLayout的测量宽高保存。最后则是特殊情况的处理，即当FrameLayout为wrap_content属性时，如果其子View是match_parent属性的话，则要重新设置FrameLayout的测量规格，然后重新对该部分View测量。
注释1
measureChildWithMargin方法，它接收的主要参数是子View以及父容器的MeasureSpec（测量规格），所以它的作用就是对子View进行测量，那么我们直接看这个方法
##FrameLayout
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);
}
里面调用了getChildMeasureSpec方法，把父容器的MeasureSpec以及自身的layoutParams属性传递进去来获取当前子View的MeasureSpe，在这里我们可以看到直接又调用了子View的measure方法。
总结：那么现在我们能得到整体的测量流程：在performTraversals开始获得DecorView种的系统布局的尺寸，然后在performMeasure方法中开始测量流程，对于不同的layout布局有着不同的实现方式，但大体上是在onMeasure方法中，对每一个子View进行遍历，根据父容器（ViewGroup）的MeasureSpec及子View的layoutParams来确定自身的测量宽高。然后根据所有子View的测量宽高信息再确定父容器（ViewGroup）的宽高。
作者:Alan
原创博客，请注明转载处....
