Android-面试官：View-post()-为什么能够获取到-View-的宽高-？

super.onResume()
// 在 onResume() 回调中获取宽高
Log.e(“measure”,“measure in onResume: width=$window.decorView.width,height=${window.decorView.height}”)
}
}

大多数人都能直截了当的给出答案：

E/measure: measure in onCreate: width=0, height=0
E/measure: measure in onResume: width=0, height=0
E/measure: measure in View.post: width=1080, height=2340

在 onCreate() 和 onResume() 中是无法获取到宽高的，而 View.post() 回调中可以。从日志打印顺序可以看出来，View.post() 回调中的打印语句是最后执行的。

抛开代码来思考一下这个问题，什么时候可以获取到 View 的宽高？ 毫无疑问，最起码肯定得在 View 被测量 这个时间点之后。从上面的结果来看，onCreate() 和 onResume() 发生在这个时间点之前，View.post() 的回调发生在这个时间点之后。我们只要搞清楚这个时间点，问题就迎刃而解了。

View 在什么时间点被测量？

大家都知道 View 的绘制流程发生在 onResume 流程（并不是指 Activity.onResume() 回调）中，但我还是决定从头开始说起，大家权当复习一下。

当冷启动 (应用进程不存在) 一个 app 时，首先要和 zygote 建立 socket 连接，将创建进程需要的参数发送给 zygote， zygote 服务端接收到参数之后调用 ZygoteConnection.processOneCommand() 处理参数，并 fork 出应用进程。最后通过 findStaticMain() 找到 ActivityThread 类的 main() 方法并执行，应用进程就启动了。

ActivityThread 虽然不是一个线程类，但它是运行在主线程的，你就把它认为是主线程也没有关系。在 main() 方法中， 创建了 ActivityThread 对象，调用其 attach() 方法，并开启了主线程消息循环，基于事件的消息队列机制就开始工作了。

在 ActivityThread.attach() 方法中，Binder 调用了 AMS.attachApplication() 方法，其中主要做了两件事：

1. 将当前进程与 AMS 进行绑定。然后再 Binder 调用回应用进程的 ApplicationThread.bindApplication() 方法，进行客户端的准备工作，创建 Context，创建 Application 等等
2. mStackSupervisor.attachApplicationLocked(app)，最终调用到 realStartActivityLocked() 启动 Activity

Activity 的启动流程就不赘述了，之前写过一篇裹脚布式的文章，庖丁解牛 Activity 启动流程 ，感兴趣的可以看看。这里直接跳到 ActivityThread.performLaunchActivity() 方法。

ActivityThread.java

p

资料获取→专栏
rivate Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
…
// 获取 ComponentName
ComponentName component = r.intent.getComponent();
…
// 创建 ContextImpl 对象
ContextImpl appContext = createBaseContextForActivity®;
…
// 反射创建 Activity 对象
activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
…
// 创建 Application 对象
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
…
// attach 方法中会创建 PhoneWindow 对象
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);

// 执行 onCreate()
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
…
return activity;
}

mInstrumentation.callActivityOnCreate() 方法最终会回调 Activity.onCreate() 方法。到这里，setContentView() 方法就被执行了。setContentView() 逻辑很复杂，但干的事情很直白。创建 DecorView ，然后根据我们传入的布局文件 id 解析 xml，将得到的 view 塞进 DecorView 中。注意，到现在，我们得到的只是一个 空壳子 View 树，它并没有被添加到屏幕上，其实也不能添加到屏幕上。所以，在 onCreate() 回调中获取视图宽高显然是不可取的。

看完 onCreate() , 我们跳过 onStart()，里面没干啥太重要的事情，直接来到 onResume() 。

注：Activity 的生命周期是由 ClientLifecycleManager 类来调度的，具体原理可以看这篇文章 从源码看 Activity 生命周期 。

ActivityThread.java

public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
…
// 1. 回调 onResume
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
···
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
// 2. 添加 decorView 到 WindowManager
wm.addView(decor, l);
…
}

两件事，回调 onResume 和 添加 DecorView 到 WindowManager 。所以，在 onResume() 回调中获取 view 的宽高其实和 onCreat e() 中没啥区别，都获取不到。

wm.addView(decor, l) 最终调用到 WindowManagerGlobal.addView() 。

public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
…
// 1. 重点，初始化 ViewRootImpl
root = new ViewRootImpl(view.getContext(), display);
// 2. 重点，发起绘制并显示到屏幕上
root.setView(view, wparams, panelParentView);

这里两行代码都是重中之重。先来看看注释 1 处 ViewRootImpl 的构造函数。

public ViewRootImpl(Context context, Display display) {
…
// 1. IWindowSession 代理对象，与 WMS 进行 Binder 通信
mWindowSession = WindowManagerGlobal.getWindowSession();
…
// 2.
mWidth = -1;
mHeight = -1;
…
// 3. 初始化 AttachInfo
// 记住 mAttachInfo 是在这里被初始化的
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,
context);
…
// 4. 初始化 Choreographer，通过 Threadlocal 存储
mChoreographer = Choreographer.getInstance();
}

1. 初始化 mWindowSession，它可以 WMS 进行 Binder 通信
2. 这里能看到宽高还未赋值
3. 初始化 AttachInfo，这里着重记一下，后面会再提到
4. 初始化 Choreographer，上篇文章 面试官：如何监测应用的 FPS ？ 详细介绍过

再看注释 2 处的 ViewRootImpl.setView() 方法。

ViewRootImpl.java

// 参数 view 就是 DecorView
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
mView = view;

// 1. 发起首次绘制
requestLayout();

// 2. Binder 调用 Session.addToDisplay()，将 window 添加到屏幕
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(), mWinFrame,
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel);

// 3. 将 decorView 的 parent 赋值为 ViewRootImpl
view.assignParent(this);
}
}
}

requestLayout() 方法发起了首次绘制。

ViewRootImpl.java

public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
// 检查线程
checkThread();
mLayoutRequested = true;
// 重点
scheduleTraversals();
}
}

ViewRootImpl.scheduleTraversals() 方法在 上篇文章 中详细介绍过，这里大致总结一下：

1. ViewRootImpl.scheduleTraversals() 方法中会建立同步屏障，优先处理异步消息。通过 Choreographer.postCallback() 方法提交了任务 mTraversalRunnable，这个任务就是负责 View 的测量，布局，绘制。
2. Choreographer.postCallback() 方法通过 DisplayEventReceiver.nativeScheduleVsync() 方法向系统底层注册了下一次 vsync 信号的监听。当下一次 vsync 来临时，系统会回调其 dispatchVsync() 方法，最终回调 FrameDisplayEventReceiver.onVsync() 方法。
3. FrameDisplayEventReceiver.onVsync() 方法中取出之前提交的 mTraversalRunnable 并执行。这样就完成了一次绘制流程。

mTraversalRunnable 中执行的是 doTraversal() 方法。

ViewRootImpl.java

void doTraversal() {
if (mTraversalScheduled) {
// 1. mTraversalScheduled 置为 false
mTraversalScheduled = false;
// 2. 移除同步屏障
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

// 3. 开始布局，测量，绘制流程
performTraversals();
…
}

ViewRootImpl.java

private void performTraversals() {
…
// 1. 绑定 Window，重点记忆一下
host.dispatchAttachedToWindow(mAttachInfo, 0);
mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true);

getRunQueue().executeActions(mAttachInfo.mHandler);

// 2. 请求 WMS 计算窗口大小
relayoutResult = relayoutWindow(params, viewVisibility, insetsPending);

// 3. 测量
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

// 4. 布局
performLayout(lp, mWidth, mHeight);

// 5. 绘制
performDraw();
}

performTraversals() 方法的逻辑甚是复杂，这里精简出几个重要的方法调用。到这里，View 的整体绘制流程已经完成，毫无疑问，在这个时候肯定是可以获取到宽高的。

View 被测量的时机已经找到了。现在就来验证一下 View.post() 是不是在这个时机执行回调的。

探秘 View.post()

View.java

public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
// 1. attachInfo 不为空，通过 mHandler 发送
return attachInfo.mHandler.post(action);
}
// 2. attachInfo 为空，放入队列中
getRunQueue().post(action);
return true;
}

这里的关键是 attachInfo 是否为空。在上一节中介绍过，再来回顾一下：

• attachInfo 是在 ViewRootImpl 的构造函数中初始化的，
• ViewRootImpl 是在 WindowManagerGlobal.addView() 创建的
• WindowManagerGlobal.addView() 是在 ActivityThread 的 handleResumeActivity() 中调用的，但是是在 Activity.onResume() 回调之后

所以，如果 attachInfo 不为空的话，至少已经处在进行视图绘制的这次消息处理当中。把 post() 方法要执行的 Runnable 利用 Handler 发送出去，当包含这个 Runnable 的 Message 被执行时，是一定可以获取到 View 的宽高的。

在 onCreate() 和 onResume() 这两个回调中，attachInfo 肯定是空的，这时候就要依赖 getRunQueue().post(action) 。原理也很简单，把 post() 方法要执行的 Runnable 存储在一个队列中，在合适的时机（View 已被测量）拿出来执行。先来看看 getRunQueue() 拿到的是一个什么队列。

View.java

private HandlerActionQueue getRunQueue() {
if (mRunQueue == null) {
mRunQueue = new HandlerActionQueue();
}
return mRunQueue;
}

public class HandlerActionQueue {
private HandlerAction[] mActions;
private int mCount;

public void post(Runnable action) {
postDelayed(action, 0);
}

// 发送任务
public void postDelayed(Runnable action, long delayMillis) {
final HandlerAction handlerAction = new HandlerAction(action, delayMillis);

synchronized (this) {
if (mActions == null) {
mActions = new HandlerAction[4];
}
mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
mCount++;
}
}

// 执行任务
public void executeActions(Handler handler) {
synchronized (this) {
final HandlerAction[] actions = mActions;
for (int i = 0, count = mCount; i < count; i++) {
final HandlerAction handlerAction = actions[i];
handler.postDelayed(handlerAction.action, handlerAction.delay);
}

mActions = null;
mCount = 0;
}
}

…

private static class HandlerAction {
final Runnable action;
final long delay;

public HandlerAction(Runnable action, long delay) {
this.action = action;
this.delay = delay;
}

public boolean matches(Runnable otherAction) {
return otherAction == null && action == null
|| action != null && action.equals(otherAction);
}
}
}

队列 HandlerActionQueue 是一个初始容量是 4 的 HandlerAction 数组。HandlerAction 有两个成员变量，要执行的 Runnable 和延迟执行的时间。

队列的执行逻辑在 executeActions(handler) 方法中，通过传入的 handler 进行任务分发。现在我们只要找到 executeActions() 的调用时机就可以了。在 View.java 中就可以找到，在 dispatchAttachedToWindow() 方法中分发了任务。

void dispatchAttachedToWindow(AttachInfo info, int visibility) {
…
if (mRunQueue != null) {
// 分发任务
mRunQueue.executeActions(info.mHandler);
mRunQueue = null;
}
// 回调 onAttachedToWindow()
onAttachedToWindow();
}

关于 dispatchAttachedToWindow()，你不妨在本文中 Ctrl + F 全局搜索一下。上一节已经出现过，我也提示你重点记一下了，就在 performTraversals() 方法中。

ViewRootImpl.java

private void performTraversals() {
…
// 1. 看这里
host.dispatchAttachedToWindow(mAttachInfo, 0);
mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true);

getRunQueue().executeActions(mAttachInfo.mHandler);

// 2. 请求 WMS 计算窗口大小
relayoutResult = relayoutWindow(params, viewVisibility, insetsPending);

// 3. 测量
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

// 4. 布局
performLayout(lp, mWidth, mHeight);

// 5. 绘制
Info, 0);
mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true);

getRunQueue().executeActions(mAttachInfo.mHandler);

// 2. 请求 WMS 计算窗口大小
relayoutResult = relayoutWindow(params, viewVisibility, insetsPending);

// 3. 测量
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

// 4. 布局
performLayout(lp, mWidth, mHeight);

// 5. 绘制