开发的过程中，我们有时候需要在Activity启动以后第一时间获取某个View的宽高，并作相应处理，当我们在onCreate中通过View.getWidth（或getMeasuredWidth）和View.getHeight（或getMeasuredHeight）方法获取的时候，你会发现它们都返回0。我们猜测是因为，这个时候View还没有布局完成。解决的办法有很多种，比如在View的OnGlobalLayoutListener中获取，在onLayout中获取等等，具体请参考StackOverflow：
https://stackoverflow.com/questions/18861585/get-content-view-size-in-oncreate
有另外一个方法，有些人应该也知道，在onCreate中通过View.post，在其中的Runnable中就能获取到正确的宽高。那么，这里的原理是什么，很多人认为这里就是一个时间差，等View的measure和layout完了就有宽和高了，有些人甚至使用postDelay延迟几秒来确保万无一失。那么这里面到底会不会有不稳定的因素呢？这篇文章告诉你答案。
本篇文章分析的是Android 6.0系统的源码。阅读之前，请先了解Android中Handler，Looper和MessageQueue等概念，推荐文章：http://blog.csdn.net/lmj623565791/article/details/38377229/
详细分析：
请看View.post源码，
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Assume that post will succeed later
ViewRootImpl.getRunQueue().post(action);
return true;
}
在onCreate的方法中执行的时候，attachInfo==null（为什么？请自行验证），所以post方法执行到了
ViewRootImpl.getRunQueue().post(action)。
这个方法是将action先保存到ViewRootImpl中的一个静态队列中，保存起来什么时候用呢？
在ViewRootImpl.perfromTravesals方法中可以看到这个队列调用的代码，
// Execute enqueued actions on every traversal in case a detached view enqueued an action
getRunQueue().executeActions(mAttachInfo.mHandler);
...
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
...
performLayout(lp, mWidth, mHeight);
...
performDraw();
大家都知道performTraversals是布局遍历的方法，所以我们知道了，post的Runnable是在布局遍历的时候执行的。然而，它是在performMeasure、performLayout之前执行的。也就是说，这个Runnable是在View的测量和布局之前执行。View测量和布局完成之前是获取不到宽高的，那我们的Runnable是怎么获取到宽高的呢。
事实上，getRunQueue().executeActions(mAttachInfo.mHandler) 也不是直接执行这些Runnable，而是往主线程消息队列添加对应的消息进去，那么我们的这个消息执行的时机是怎么保证在View布局完成之后呢？研究过performTraversals源码的话，应该知道，performTraversals这个方法也是被附到一个消息上添加到消息队列等待执行的。下面看分析。
首先从View布局的终极方法performTraversals开始分析，这个方法到底是怎么执行的，在哪执行的。一路追过去，
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
if (mProfile) {
Debug.startMethodTracing("ViewAncestor");
}
performTraversals();
if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}
perfromTraversals由doTraversal调用，
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
而doTraversal方法在TraversalRunnable调用，那么这个Runnable的对象在哪执行的呢？
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
可以看到，mTraversalRunnable出现在这个方法scheduleTraversals里：
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
这里面mTraversalRunnable也是被post了，这个post方法叫做postCallback，猜测是不是也是加到消息队列去了？
继续看mChoreographer.postCallback方法，这个方法最终会到下面这个方法中：
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
if (DEBUG_FRAMES) {
Log.d(TAG, "PostCallback: type=" + callbackType
+ ", action=" + action + ", token=" + token
+ ", delayMillis=" + delayMillis);
}
synchronized (mLock) {
final long now = SystemClock.uptimeMillis();
final long dueTime = now + delayMillis;
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
if (dueTime <= now) {
scheduleFrameLocked(now);
} else {
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}
注意到熟悉的一句代码：mHandler.sendMessageAtTime，这个方法就是将消息加入到消息队列，而这个Handler对应的消息队列是什么？
我们从 mHandler这个对象着手，看看它是怎么来的。
private Choreographer(Looper looper) {
mLooper = looper;
mHandler = new FrameHandler(looper);
mDisplayEventReceiver = USE_VSYNC ? new FrameDisplayEventReceiver(looper) : null;
mLastFrameTimeNanos = Long.MIN_VALUE;
mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
for (int i = 0; i <= CALLBACK_LAST; i++) {
mCallbackQueues[i] = new CallbackQueue();
}
}
在这个构造函数中，可以看到mHandler构造的时候传入一个Looper对象，那就要看下这个Looper是从哪里来的。
// Thread local storage for the choreographer.
private static final ThreadLocal<Choreographer> sThreadInstance =
new ThreadLocal<Choreographer>() {
@Override
protected Choreographer initialValue() {
Looper looper = Looper.myLooper();
if (looper == null) {
throw new IllegalStateException("The current thread must have a looper!");
}
return new Choreographer(looper);
}
};
这里又看到熟悉的代码了Looper looper = Looper.myLooper(); 获取了当前线程（主线程）的Looper对象。
所以，performTraversals方法实际上也是被加入到消息队列中去执行的，而我们最初post的Runnable，是在performTraversals方法中将其附加到一个消息上并加入到消息队列里。所以，我们post的Runnable的消息，肯定是在performTraversals的消息之后执行的，也就是我们post的Runnable肯定是在performTraversals之后执行，而performTraversals之后，View的宽和高便计算出来了。
需要注意的是， 在onCreate（以及onStart, onResume）方法中必须保证是在主线程调用View.post方法，因为ViewRootImpl.getRunQueue()在不同线程获取到的是不同的对象（为什么？请研究getRunQueue()的类型），所以在onCreate方法内新建线程并在里面post的时候，这个post是成功不了的。在Android 7.0中修复了这个问题，也就说7.0系统中，在onCreate方法中新建线程并在里面post，这个Runnable是可以被执行到的。感兴趣的看源码。
一句话总结：
在onCreate中调用View.post的时候，post的Runnable被保存起来，在下一次遍历布局的时候重新加到消息队列里（Android 7.0是在attach window的时候重新加到消息队列里），而且布局遍历本身也是加到消息队列执行的，所以我们post的Runnable所在的消息肯定是在布局遍历之后，所以在Runnable里必定可以获取到正确的宽高。
