前言
最近因为个人原因，导致要离开杭州了,人生就是一次又一次的意外，你不知道突然会发生什么，你能做到的只有把握好每一次机会
原理猜测
在Android中，想要获取View的宽高，常见的基本都是接调用View.getWidth或者View.getMeasuredWidth方法来获取宽高，但是往往在oncreate或者onresume中，得到的值都是0，也就可以理解为此时View的绘制流程并没有执行完，熟悉Activity启动流程的朋友都知道，Activity的生命周期和页面的绘制流程并不是一个串行的状态，没有特定的先后关系，所以也不难理解获取的值是0了
再次回到主题，那为什么View.post()，就可以获取到准确的值呢，不妨猜测一下，首先整体上思考一下，想要实现知道准确的宽高，那就是post的Runnable那肯定是在View整个绘制流程结束之后才执行的，主线程又是基于Looper的消息机制的，如果把Runnable直接作为一个消息插入消息队列，那么很明显不能保证这种效果，熟悉View绘制流程的朋友知道，View的绘制是在ViewRootImp中的，但View的绘制其实也是一个Runnable消息，那么我们可不可以先把post的这个Runnable给缓存起来，等到绘制的Runnable执行完之后，再来通知去执行，这样就能够获取到准确的宽高了。
View##post
本文源码是API是android-28，不同版本可能有些差异，需要读者自行注意
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
getRunQueue().post(action);
return true;
}
可以看到方法很简答，主要就是一个attachInfo，如果不为空就直接使用attachInfo.mHandler去执行这个action，如果为空，把Runnable放入一个类似队列的东西里面
我们再回头想想开头说的话，好像还真是这么实现的，这里的mAttachInfo其实可以看做为是否已经绘制好了的一个标志，如果不为空，说明绘制完成，直接handler执行action，如果为空，说明没有绘制完，这时候就把Runnable缓存起来，那么关键点也就来了，这个mAttachInfo是什么时候被赋值的，全局搜索下赋值
View##dispatchAttachedToWindow
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
......
}
从这个方法名字，我们也应该能看出来，绑定到window的时候，此时会进行赋值mAttachInfo，也就意味着绘制完毕，当然，我们还不知道dispatchAttachedToWindow这个方法是什么时候调用的，先这么理解着
getRunQueue().post(action)
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++;
}
}
可以看到，实际上是维护了一个HandlerActionQueue类，内部维护了一个数组，长度居然是固定为4（问号脸），然后将这些Runnabel给缓存起来。那疑问就来了，既然是缓存起来，那什么时候执行的，可以看到有个executeActions方法
executeActions(Handler handler)
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;
}
}
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
......
// Transfer all pending runnables.
if (mRunQueue != null) {
mRunQueue.executeActions(info.mHandler);
mRunQueue = null;
}
....
}
通过传递进来的handler，然后将内部缓存的Runnable去执行，ctrl一下，看看哪里调用了，咦。又是dispatchAttachedToWindow这个方法。
先总结下，View.post(Runnable) 的这些 Runnable 操作，在 View 被 attachedToWindow 之前会先缓存下来，然后在 dispatchAttachedToWindow() 被调用时，就将这些缓存下来的 Runnable 通过 mAttachInfo 的 mHandler 来执行。在这之后再调用 View.post(Runnable) 的话，这些 Runnable 操作就不用再被缓存了，而是直接交由 mAttachInfo 的 mHandler 来执行
所以问题最终也就到这个方法这里了，这个方法是什么时候被调用的，ctrl一下。。居然没有地方调用，那肯定是隐藏类调用了，此时祭出我们的Source Insight，从源码里面找找。
ViewRootImpl##performTraversals
private void performTraversals() {
.....
final View host = mView;
.....
host.dispatchAttachedToWindow(mAttachInfo, 0)
....
}
final ViewRootHandler mHandler = new ViewRootHandler();
public ViewRootImpl(Context context, Display display) {
...
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this);
....
}
这个方法是不是很眼熟，View的绘制流程就从这个方法开始的，可以看到的是，mAttachInfo这个对象是在ViewRootImpl初始化的时候就赋值了，并且Handler是直接在主线程中创建的，这个就可以说明了为什么View.post是可以更新UI的，因为最终的Runnable是在主线程的Handler中去执行的，自然是可以更新UI的。
但是大家有可能还有个疑问，那既然View的绘制也是这个方法执行的，dispatchAttachedToWindow也是在这个方法执行的，那怎么能保证一定是在View的绘制流程完成之后才去执行dispatchAttachedToWindow的呢。
答案也很简单，因为android主线程是基于Looper的消息机制的，不断的从绑定Looper的MessageQueue中去获取message去执行，View的绘制操作其实也是一个Runnable对象，所以在执行performTraversals()方法的时候，调用dispatchAttachedToWindow方法，这个时候，所以子View通过View.post(Runnable)缓存的Runnabel是会通过mAttachInfo.mHandler 的 post() 方法将这些 Runnable 封装到 Message 里发送到 MessageQueue 里。mHandler 我们上面也分析过了，绑定的是主线程的 Looper，所以这些 Runnable 其实都是发送到主线程的 MessageQueue 里排队的，所以也就可以保证这些 Runnable 操作也就肯定会在 performMeasure() 操作之后才执行，宽高也就可以获取到了，我们也可以在源码中找到些许痕迹
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
void doTraversal() {
if (mTraversalScheduled) {
.....
performTraversals();
....
}
}
总结
- View.post(Runnable)内部两种判断，如果当前View没有绘制完成，通过类HandlerActionQueue内部将Runnabel缓存下来，否则就直接通过 mAttachInfo.mHandler 将这些 Runnable 操作 post 到主线程的 MessageQueue 中等待执行。
- mAttachInfo.mHandler是ViewRootImpl中的成员变量，绑定的是主线程的Looper，所以View.post的操作会转到主线程之中，自然可以作为更新UI的根据了
- Handler消息机制是不断的从队列中获取Message对象，所以 View.post(Runnable) 中的 Runnable 操作肯定会在 performMeaure() 之后才执行，所以此时可以获取到 View 的宽高
