灵魂画师，Android绘制流程——Android高级UI

最新推荐文章于 2024-10-10 10:13:12 发布

原创最新推荐文章于 2024-10-10 10:13:12 发布 · 495 阅读

10 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#android #ui

程序员专栏收录该内容

185 篇文章

订阅专栏

本文深入解析了Android Activity的界面结构形成和绘制流程。从消息处理开始，详细分析了Activity生命周期方法的调用过程，如onCreate、onStart等。还介绍了布局文件如何解析成控件树，以及绘制流程中onMeasure方法的参数含义和操作，包括MeasureSpec的测量模式、makeMeasureSpec和getMode方法。

// ActivityThread$H 类
private class H extends Handler {
public static final int LAUNCH_ACTIVITY = 100;
// 省略大量代码

public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case LAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, “activityStart”);
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;

r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null, “LAUNCH_ACTIVITY”);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
// 省略大量代码
}
}

// 省略大量代码
}

我们从上面的代码可以知道消息类型为 LAUNCH_ACTIVITY，则会进入 handleLaunchActivity 方法，我们顺着往里走，来到下面这段代码

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
unscheduleGcIdler();
mSomeActivitiesChanged = true;

if (r.profilerInfo != null) {
mProfiler.setProfiler(r.profilerInfo);
mProfiler.startProfiling();
}

// Make sure we are running with the most recent config.
handleConfigurationChanged(null, null);

if (localLOGV) Slog.v(
TAG, "Handling launch of " + r);

// Initialize before creating the activity
WindowManagerGlobal.initialize();

// 获得一个Activity对象，会进行调用 Activity 的 onCreate 和 onStart 的生命周期
Activity a = performLaunchActivity(r, customIntent);

// Activity 不为空进入
if (a != null) {
r.createdConfig = new Configuration(mConfiguration);
reportSizeConfigurations®;
Bundle oldState = r.state;

// 该方法最终回调用到 Activity 的 onResume
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);

if (!r.activity.mFinished && r.startsNotResumed) {

performPauseActivityIfNeeded(r, reason);

if (r.isPreHoneycomb()) {
r.state = oldState;
}
}
} else {
// If there was an error, for any reason, tell the activity manager to stop us.
try {
ActivityManager.getService()
.finishActivity(r.token, Activity.RESULT_CANCELED, null,
Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
}

我们先看这行代码 performLaunchActivity(r, customIntent); 最终会调用 onCreate 和 onStart 方法。眼见为实，耳听为虚，我们继续进入深入。来到下面这段代码

// ActivityThread 类
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
// 省略不相关代码

// 创建 Activity 的 Context
ContextImpl appContext = createBaseContextForActivity®;
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
// ClassLoader 加载 Activity类，并创建 Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);

// 省略不相关代码

} catch (Exception e) {
// 省略不相关代码
}

try {
// 创建 Application
Application app = r.packageInfo.makeApplication(false, mInstrumentation);

// 省略不相关代码

if (activity != null) {
// 省略不相关代码

// 调用了 Activity 的 attach
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback);

// 这个 intent 就是我们 getIntent 获取到的
if (customIntent != null) {
activity.mIntent = customIntent;
}

// 省略不相关代码

// 调用 Activity 的 onCreate
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}

// 省略不相关代码

if (!r.activity.mFinished) {
// zincPower 调用 Activity 的 onStart
activity.performStart();
r.stopped = false;
}

if (!r.activity.mFinished) {
// zincPower 调用 Activity 的 onRestoreInstanceState 方法，数据恢复
if (r.isPersistable()) {
if (r.state != null || r.persistentState != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
r.persistentState);
}
} else if (r.state != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
}
}
// 省略不相关代码
}

// 省略不相关代码

}

// 省略不相关代码

return activity;
}

// Instrumentation 类
public void callActivityOnCreate(Activity activity, Bundle icicle,
PersistableBundle persistentState) {
prePerformCreate(activity);
activity.performCreate(icicle, persistentState);
postPerformCreate(activity);
}

// Activity 类
final void performCreate(Bundle icicle) {
restoreHasCurrentPermissionRequest(icicle);
// 调用了 onCreate
onCreate(icicle);
mActivityTransitionState.readState(icicle);
performCreateCommon();
}

// Activity 类
final void performStart() {
// 省略不相关代码

// 进行调用 Activity 的 onStart
mInstrumentation.callActivityOnStart(this);

// 省略不相关代码
}

// Instrumentation 类
public void callActivityOnStart(Activity activity) {
// 调用了 Activity 的 onStart
activity.onStart();
}

进入 performLaunchActivity 方法后，我们会发现很多我们熟悉的东西，小盆友已经给关键点打上注释，因为不是文章的重点就不再细说，否则篇幅过长。

我们直接定位到 mInstrumentation.callActivityOnCreate 这行代码。进入该方法，方法内会调用 activity 的 performCreate 方法，而 performCreate 方法里会调用到我们经常重写的 Activity 生命周期的 onCreate 方法。😄至此，找到了 onCreate 的调用地方，这里需要立个 FLAG1，因为目标二需要的开启便是这里，我下一小节分享，勿急。

回过头来继续 performLaunchActivity 方法的执行，会调用到 activity 的 performStart 方法，而该方法又会调用到 mInstrumentation.callActivityOnStart 方法，最后在该方法内便调用了我们经常重写的 Activity 生命周期的 onStart 方法。😊至此，找到了 onStart 的调用地方。

找到了两个生命周期的调用地方，我们需要折回到 handleLaunchActivity 方法中，继续往下运行，便会来到 handleResumeActivity 方法，具体代码如下：

// ActivityThread 类
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
// 省略部分代码

r = performResumeActivity(token, clearHide, reason);

// 省略部分代码

if (r.window == null && !a.mFinished && willBeVisible) {
// 将 Activity 中的 Window 赋值给 ActivityClientRecord 的 Window
r.window = r.activity.getWindow();
// 获取 DecorView，这个 DecorView 在 Activity 的 setContentView 时就初始化了
View decor = r.window.getDecorView();
// 此时为不可见
decor.setVisibility(View.INVISIBLE);

// WindowManagerImpl 为 ViewManager 的实现类
ViewManager wm = a.getWindowManager();

WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (r.mPreserveWindow) {
a.mWindowAdded = true;
r.mPreserveWindow = false;

ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
// 往 WindowManager 添加 DecorView，并且带上 WindowManager.LayoutParams
// 这里面便触发真正的绘制流程
wm.addView(decor, l);
} else {
a.onWindowAttributesChanged(l);
}
}

}

// 省略不相关代码
}

performResumeActivity方法最终会调用到 Activity 的 onResume 方法，因为不是我们该小节的目标，就不深入了，童鞋们可以自行深入，代码也比较简单。至此我们就找齐了我们一直重写的三个 Acitivity 的生命周期函数 onCreate、onStart 和 onResume 。按照这一套路，童鞋们可以看看 ApplicationThread 的其他方法，会发现 Activity 的生命周期均在其中可以找到影子，也就证实了我们最开始所说的 我们将应用 “遥控器” 交给了AMS。而值得一提的是，这一操作是处于一个跨进程的场景。

继续往下运行来到 wm.addView(decor, l); 这行代码，wm 的具体实现类为 WindowManagerImpl，继续跟踪深入，来到下面这一连串的调用

// WindowManagerImpl 类
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
// tag:进入这一行
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}

// WindowManagerGlobal 类
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
// 省略不相关代码

ViewRootImpl root;
View panelParentView = null;

synchronized (mLock) {

// 省略不相关代码

// 初始化 ViewRootImpl
root = new ViewRootImpl(view.getContext(), display);

view.setLayoutParams(wparams);

mViews.add(view);
mRoots.add(root);
mParams.add(wparams);

try {
// 将 view 和 param 交于 root
// ViewRootImpl 开始绘制 view
// tag:进入这一行
root.setView(view, wparams, panelParentView);
} catch (RuntimeException e) {
if (index >= 0) {
removeViewLocked(index, true);
}
throw e;
}
}
}

// ViewRootImpl 类
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
// 省略不相关代码

// 进入绘制流程
// tag:进入这一行
requestLayout();

// 省略不相关代码
}
}
}

// ViewRootImpl 类
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
// tag:进入这一行
scheduleTraversals();
}
}

// ViewRootImpl 类
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// 提交给编舞者，会在下一帧绘制时调用 mTraversalRunnable，运行其run
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}

中间跳转的方法比较多，小盆友都打上了 // tag:进入这一行 注释，童鞋们可以自行跟踪，会发现最后会调用到编舞者，即 Choreographer 类的 postCallback方法。Choreographer 是一个会接收到垂直同步信号的类，所以当下一帧到达时，他会调用我们刚才提交的任务，即此处的 mTraversalRunnable，并执行其 run 方法。

值得一提的是通过 Choreographer 的 postCallback 方法提交的任务并不是每一帧都会调用，而是只在下一帧到来时调用，调用完之后就会将该任务移除。简而言之，就是提交一次就会在下一帧调用一次。

我们继续来看 mTraversalRunnable 的具体内容，看看每一帧都做了写什么操作。

// ViewRootImpl 类
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();

// ViewRootImpl 类
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();

if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}

// ViewRootImpl 类
private void performTraversals() {

// 省略不相关代码

if (!mStopped || mReportNextDraw) {

// 省略不相关代码

// FLAG2
int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);

// 省略不相关代码

// 进行测量
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

// 省略不相关代码

// 进行摆放
performLayout(lp, mWidth, mHeight);

// 省略不相关代码

// 布局完回调
if (triggerGlobalLayoutListener) {
mAttachInfo.mRecomputeGlobalAttributes = false;
mAttachInfo.mTreeObserver.dispatchOnGlobalLayout();
}

// 省略不相关代码

// 进行绘制
performDraw();

}

调用了 mTraversalRunnable 的 run 方法之后，会发现也是一连串的方法调用，后来到 performTraversals，这里面就有我们一直提到三个绘制流程方法的起源地。这三个起源地就是我们在上面看到的三个方法 performMeasure、performLayout 、performDraw 。

而这三个方法会进行如下图的一个调用链（😄还是手绘，勿喷），从代码我们也知道，会按照 performMeasure、performLayout 、performDraw 的顺序依次调用。

performMeasure 会触发我们的测量流程，如图中所示，进入第一层的 ViewGroup，会调用 measure 和 onMeasure，在 onMeasure 中调用下一层级，然后下一层级的 View或ViewGroup 会重复这样的动作，进行所有 View 的测量。（这一过程可以理解为书的深度遍历）

performLayout 和 performMeasure 的流程大同小异，只是方法名不同，就不再赘述。

performDraw 稍微些许不同，当前控件为ViewGroup时，只有需要绘制背景或是我们通过 setWillNotDraw(false) 设置我们的ViewGroup需要进行绘制时，会进入 onDraw 方法，然后通过 dispatchDraw 进行绘制子View，如此循环。而如果为View，自然也就不需要绘制子View，只需绘制自身的内容即可。外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传至此，绘制流程的源头我们便了解清楚了， onMeasure 、 onLayout、onDraw 三个方法我们会在后面进行详述并融入在实战中。

四、Activity 的界面结构在哪里开始形成

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传上图是 Activity 的结构。我们先进行大致的描述，然后在进入源码体会这一过程。

我们可以清晰的知道一个 Activity 会对应着有一个 Window，而 Window 的唯一实现类为 PhoneWindow，PhoneWindow 的初始化是在 Activity 的 attach 方法中，我们前面也有提到 attach 方法，感兴趣的童鞋可以自行深入。

在往下一层是一个 DecorView，被 PhoneWindow 持有着，DecorView 的初始化在 setContentView 中，这个我们待会会进行详细分析。DecorView 是我们的顶级View，我们设置的布局只是其子View。

DecorView 是一个 FrameLayout。但在 setContentView 中，会给他加入一个线性的布局(LinearLayout)。该线性布局的子View 则一般由 TitleBar 和 ContentView 进行组成。TitleBar 我们可以通过 requestWindowFeature(Window.FEATURE_NO_TITLE); 进行去除，而 ContentView 则是来装载我们设置的布局文件的 ViewGroup 了。

现在我们已经有一个大概的印象，接下来进行详细分析。在上一节中（FLAG1处），我们最先会进入的生命周期为onCreate，在该方法中我们都会写上这样一句代码setContentView(R.layout.xxxx) 进行设置布局。经过上一节我们也知道，真正的绘制流程是在 onResume 之后（忘记的童鞋请倒回去看一下），那么 setContentView 起到一个什么作用呢？我进入源码一探究竟吧。

进入 Activity 的 setContentView 方法，可以看到下面这段代码。getWindow 返回的是一个 Window 类型的对象，而通过Window的官方注释可以知道其唯一的实现类为PhoneWindow，所以我们进入 PhoneWindow 类查看其 setContentView 方法，这里值得我们注意有两行代码。我们一一进入，我们先进入 installDecor 方法。

// Activity 类
public void setContentView(@LayoutRes int layoutResID) {
// getWindow 返回的是 PhoneWindow
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
}

// Activity 类
public Window getWindow() {
return mWindow;
}

// PhoneWindow 类
@Override
public void setContentView(int layoutResID) {
// 此时 mContentParent 为空，mContentParent 是装载我们布局的容器
if (mContentParent == null) {
// 进行初始化顶级View——DecorView 和我们设置的布局的装载容器——ViewGroup(mContentParent)
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}

if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
// 加载我们设置的布局文件到 mContentParent
mLayoutInflater.inflate(layoutResID, mContentParent);
}
mContentParent.requestApplyInsets();
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
cb.onContentChanged();
}
mContentParentExplicitlySet = true;
}

installDecor 方法的作用为初始化了我们的顶级View（即DecorView）和初始化装载我们布局的容器（即 mContentParent 属性）。具体代码如下

private void installDecor() {
mForceDecorInstall = false;
if (mDecor == null) {
// 会进行实例化一个mDecor
mDecor = generateDecor(-1);
mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
mDecor.setIsRootNamespace(true);
if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
}
} else {
mDecor.setWindow(this);
}
if (mContentParent == null) {
// 初始化 mContentParent
mContentParent = generateLayout(mDecor);

// 省略不相关代码
}

在 generateDecor 中会进行 DecorView 的创建，具体代码如下，较为简单

protected DecorView generateDecor(int featureId) {
Context context;
if (mUseDecorContext) {
Context applicationContext = getContext().getApplicationContext();
if (applicationContext == null) {
context = getContext();
} else {
context = new DecorContext(applicationContext, getContext().getResources());
if (mTheme != -1) {
context.setTheme(mTheme);
}
}
} else {
context = getContext();
}
return new DecorView(context, featureId, this, getAttributes());
}

紧接着是generateLayout 方法，核心代码如下，如果我们在 onCreate 方法前通过requestFeature 进行设置一些特征，此时的 getLocalFeatures 就会获取到，并根据其值选择合适的布局赋值给 layoutResource 属性。最后将该布局资源解析，赋值给 DecorView，紧接着将 DecorView 中 id 为 content 的控件赋值给 contentParent，而这个控件将来就是装载我们设置的布局资源。

protected ViewGroup generateLayout(DecorView decor) {

// 省略不相关代码

int layoutResource;
int features = getLocalFeatures();
// System.out.println(“Features: 0x” + Integer.toHexString(features));
if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
layoutResource = R.layout.screen_swipe_dismiss;
setCloseOnSwipeEnabled(true);
} else if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON))) != 0) {
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogTitleIconsDecorLayout, res, true);
layoutResource = res.resourceId;
} else {
layoutResource = R.layout.screen_title_icons;
}
// XXX Remove this once action bar supports these features.
removeFeature(FEATURE_ACTION_BAR);
// System.out.println(“Title Icons!”);
} else if ((features & ((1 << FEATURE_PROGRESS) | (1 << FEATURE_INDETERMINATE_PROGRESS))) != 0
&& (features & (1 << FEATURE_ACTION_BAR)) == 0) {
// Special case for a window with only a progress bar (and title).
// XXX Need to have a no-title version of embedded windows.
layoutResource = R.layout.screen_progress;
// System.out.println(“Progress!”);
} else if ((features & (1 << FEATURE_CUSTOM_TITLE)) != 0) {
// Special case for a window with a custom title.
// If the window is floating, we need a dialog layout
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogCustomTitleDecorLayout, res, true);
layoutResource = res.resourceId;
} else {
layoutResource = R.layout.screen_custom_title;
}
// XXX Remove this once action bar supports these features.
removeFeature(FEATURE_ACTION_BAR);
} else if ((features & (1 << FEATURE_NO_TITLE)) == 0) {
// If no other features and not embedded, only need a title.
// If the window is floating, we need a dialog layout
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogTitleDecorLayout, res, true);
layoutResource = res.resourceId;
} else if ((features & (1 << FEATURE_ACTION_BAR)) != 0) {
layoutResource = a.getResourceId(
R.styleable.Window_windowActionBarFullscreenDecorLayout,
R.layout.screen_action_bar);
} else {
layoutResource = R.layout.screen_title;
}
// System.out.println(“Title!”);
} else if ((features & (1 << FEATURE_ACTION_MODE_OVERLAY)) != 0) {
layoutResource = R.layout.screen_simple_overlay_action_mode;
} else {
// Embedded, so no decoration is needed.
layoutResource = R.layout.screen_simple;
// System.out.println(“Simple!”);
}

mDecor.startChanging();
// 进行加载 DecorView 的布局
mDecor.onResourcesLoaded(mLayoutInflater, layoutResource);

// 这里就获取了装载我们设置的内容容器 id 为 R.id.content
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);

// 省略不相关代码

return contentParent;
}

我们折回到 setContentView 方法，来到 mLayoutInflater.inflate(...); 这行代码，layoutResID 为我们设置的布局文件，而 mContentParent 就是我们刚刚获取的id 为 content 的控件，这里便是把他从 xml 文件解析成一棵控件的对象树，并且放入在 mContentParent 容器内。

至此我们知道，Activity 的 setContentView 是让我们布局文件从xml “翻译” 成对应的控件对象，形成一棵以 DecorView 为根结点的控件树，方便我们后面绘制流程进行遍历。

五、绘制流程如何运转起来的

终于来到核心节，我们来继续分析第三节最后说到的三个方法onMeasure、onLayout、onDraw，这便是绘制流程运转起来的最后一道门阀，是我们自定义控件中可操作的部分。我们接下来一个个分析

1、onMeasure

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)

要解释清楚这个方法，我们需要先说明两个参数的含义和构成。两个参数都是 MeasureSpec 的类型

MeasureSpec是什么

MeasureSpec 是一个 32位的二进制数。高2位为测量模式，即SpecMode；低30位为测量数值，即SpecSize。我们先看下源码，从源码中找到这两个值的含义。

以下是 MeasureSpec 类的代码（删除了一些不相关的代码）

public static class MeasureSpec {
private static final int MODE_SHIFT = 30;
// 最终结果为：11 …(30位)
private static final int MODE_MASK = 0x3 << MODE_SHIFT;

// 父View 不对子View 施加任何约束。子View可以是它想要的任何尺寸。
// 二进制：00 …(30位)
public static final int UNSPECIFIED = 0 << MODE_SHIFT;

// 父View 已确定子View 的确切大小。子View 的大小便是父View测量所得的值
// 二进制：01 …(30位)
public static final int EXACTLY = 1 << MODE_SHIFT;

// 父View 指定一个子View 可用的最大尺寸值，子View大小不能超过该值。
// 二进制：10 …(30位)
public static final int AT_MOST = 2 << MODE_SHIFT;

public static int makeMeasureSpec(@IntRange(from = 0, to = (1 << MeasureSpec.MODE_SHIFT) - 1) int size,
@MeasureSpecMode int mode) {
// API 17 之后，sUseBrokenMakeMeasureSpec 就为 false
if (sUseBrokenMakeMeasureSpec) {
return size + mode;
} else {
return (size & ~MODE_MASK) | (mode & MODE_MASK);
}
}

@MeasureSpecMode
public static int getMode(int measureSpec) {
return (measureSpec & MODE_MASK);
}

public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}

}

（1）测量模式

类中有三个常量： UNSPECIFIED 、EXACTLY 、AT_MOST，他们对应着三种测量模式，具体含义我们在注释中已经写了，小盆友整理出以下表格方便我们查阅。

名称	含义	数值（二进制）	具体表现
UNSPECIFIED	父View不对子View 施加任何约束，子View可以是它想要的任何尺寸	00 …(30个0)	系统内部使用
EXACTLY	父View已确定子View 的确切大小，子View的大小为父View测量所得的值	01 …(30个0)	具体数值、match_parent
AT_MOST	父View 指定一个子View可用的最大尺寸值，View大小不能超过该值。	10 …(30个0)	wrap_content