List pendingResults, List pendingNewIntents,
boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {
updateProcessState(procState, false);
// 会将 AMS 发来的信息封装在 ActivityClientRecord 中,然后发送给 Handler
ActivityClientRecord r = new ActivityClientRecord();
r.token = token;
r.ident = ident;
r.intent = intent;
r.referrer = referrer;
r.voiceInteractor = voiceInteractor;
r.activityInfo = info;
r.compatInfo = compatInfo;
r.state = state;
r.persistentState = persistentState;
r.pendingResults = pendingResults;
r.pendingIntents = pendingNewIntents;
r.startsNotResumed = notResumed;
r.isForward = isForward;
r.profilerInfo = profilerInfo;
r.overrideConfig = overrideConfig;
updatePendingConfiguration(curConfig);
sendMessage(H.LAUNCH_ACTIVITY, r);
}
// 省略大量代码
}
从 ApplicationThread 的方法名,我们会惊奇的发现大多方法名以 scheduleXxxYyyy
的形式命名,而且和我们熟悉的生命周期都挺接近。上面代码留下了我们需要的方法 scheduleLaunchActivity
,它们包含了我们 Activity 的 onCreate
、onStart
和 onResume
。
scheduleLaunchActivity
方法会对 AMS 发来的信息封装在 ActivityClientRecord 类中,最后通过 sendMessage(H.LAUNCH_ACTIVITY, r);
这行代码将信息以 H.LAUNCH_ACTIVITY
的信息标记发送至我们主线程中的 Handler。我们进入主线程的 Handler 实现类 H。具体代码如下:
// 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 |
(2)makeMeasureSpec
makeMeasureSpec
方法,该方法用于合并测量模式和测量尺寸,将这两个值合为一个32位的数,高2位为测量模式,低30位为尺寸。
该方法很简短,主要得益于 (size & ~MODE_MASK) | (mode & MODE_MASK)
的位操作符,但也带来了一定的理解难度。我们拆解下
总结
最后对于程序员来说,要学习的知识内容、技术有太多太多,要想不被环境淘汰就只有不断提升自己,从来都是我们去适应环境,而不是环境来适应我们!
这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。
相信它会给大家带来很多收获:
当程序员容易,当一个优秀的程序员是需要不断学习的,从初级程序员到高级程序员,从初级架构师到资深架构师,或者走向管理,从技术经理到技术总监,每个阶段都需要掌握不同的能力。早早确定自己的职业方向,才能在工作和能力提升中甩开同龄人。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
.(30个0) | wrap_content |
(2)makeMeasureSpec
makeMeasureSpec
方法,该方法用于合并测量模式和测量尺寸,将这两个值合为一个32位的数,高2位为测量模式,低30位为尺寸。
该方法很简短,主要得益于 (size & ~MODE_MASK) | (mode & MODE_MASK)
的位操作符,但也带来了一定的理解难度。我们拆解下
总结
最后对于程序员来说,要学习的知识内容、技术有太多太多,要想不被环境淘汰就只有不断提升自己,从来都是我们去适应环境,而不是环境来适应我们!
这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。
相信它会给大家带来很多收获:
[外链图片转存中…(img-KzKiHXh2-1715340190725)]
[外链图片转存中…(img-cd249UVp-1715340190725)]
当程序员容易,当一个优秀的程序员是需要不断学习的,从初级程序员到高级程序员,从初级架构师到资深架构师,或者走向管理,从技术经理到技术总监,每个阶段都需要掌握不同的能力。早早确定自己的职业方向,才能在工作和能力提升中甩开同龄人。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!