接上篇： Android获取View的宽和高（一)
其实除了ViewTreeObserver这个观察者类，还可以通过View.Post()获取到View宽高margin值的信息，代码如下：
btn02.post(new Runnable() {
@Override
public void run() {
//可以正常获取到View宽高 margin
LogUtil.d(" btn02.post" + btn02.getWidth()+btn02.getTop());
}
});
看log日志输出的时候发现run方法是在ViewTreeObserver的OnGlobalLayoutListener，OnPreDrawListener，OnDrawListener之后执行的，那么它到底什么时候调用的呢，点开view的post方法,查看源码代码如下：
/**
* <p>Causes the Runnable to be added to the message queue.
* The runnable will be run on the user interface thread.</p>
*//把该runnable加入到 mq里，最终在ui线程执行
*
*/
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Postpone the runnable until we know on which thread it needs to run.
// Assume that the runnable will be successfully placed after attach.
getRunQueue().post(action);
return true;
}
/**
* Returns the queue of runnable for this view.
*/
private HandlerActionQueue getRunQueue() {
if (mRunQueue == null) {
mRunQueue = new HandlerActionQueue();
}
return mRunQueue;
}
代码里包含了一个attachInfo和 HandlerActionQueue，attachInfo是View在添加到window上的描述信息，HandlerActionQueue姑且看作一个Handler去发送通知的，继续查看AttachInfo的赋值过程，代码如下：
/**
* @param info the {@link android.view.View.AttachInfo} to associated with
* this view
*/
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
if (mOverlay != null) {
mOverlay.getOverlayView().dispatchAttachedToWindow(info, visibility);
}
registerPendingFrameMetricsObservers();
performCollectViewAttributes(mAttachInfo, visibility);
onAttachedToWindow();
ListenerInfo li = mListenerInfo;
final CopyOnWriteArrayList<View.OnAttachStateChangeListener> listeners =
li != null ? li.mOnAttachStateChangeListeners : null;
if (listeners != null && listeners.size() > 0) {
for (View.OnAttachStateChangeListener listener : listeners) {
listener.onViewAttachedToWindow(this);
}
}
needGlobalAttributesUpdate(false);
notifyEnterOrExitForAutoFillIfNeeded(true);
}
mAttachInfo在 dispatchAttachedToWindow中被赋值，它其实是在ViewRootImpl中构造的，（ViewRootImpl 可以理解是一个 Activity 的 ViewTree 的根节点的实例，它是用来管理 DecorView 和 ViewTree）。在ViewRootImpl构造方法为：
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,context);
而dispatchAttachedToWindow只会在两种情况下被调用：
- ViewRootImpl 第一次 performTraversal()时会将整个view tree里所有有view的 dispatchAttachedToWindow() DFS 调用一遍.
- ViewGroup的 addViewInner(View child, int index, LayoutParams params, boolean preventRequestLayout);
这时我们应该是第一种情况下的调用，我们在去查看ViewRootImpl中的 performTraversal()方法：
private void performTraversals () {
// cache mView since it is used so much below...
final View host = mView
host.dispatchAttachedToWindow(mAttachInfo, 0);
//viewTreeObserver也在这个方法中调用
mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true);
//对每次遍历操作进行排队
getRunQueue().executeActions(mAttachInfo.mHandler);
// Ask host how big it wants to be//测量过程
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
int width = host.getMeasuredWidth();
int height = host.getMeasuredHeight();
//onLayout执行
performLayout(lp, mWidth, mHeight);
//开始绘制
performDraw();
}
该方法是View整个绘制过程；其中 getRunQueue()方法如下：
static HandlerActionQueue getRunQueue() {
// sRunQueues是 ThreadLocal<HandlerActionQueue> 对象
HandlerActionQueue rq = sRunQueues.get();
if (rq != null) {
return rq;
}
rq = new HandlerActionQueue();
sRunQueues.set(rq);
return rq;
}
忽然找到了亲人，这不就是post里的HandlerActionQueue那个对象么，到目前他们之间到关系貌似也渐渐清晰起来了。
总结一下：
- 1.View在attachtoWindow之前，会维护一个HandlerActionQueue对象，储存当前的runnable 对象，当attach to window（ViewRootImpl 执行到 performTraversal 方法）的时候交给ViewRootImpl处理。
- 2.View的dispatchAttachedToWindow方法也会为当前view创建一个attachInfo对象，该对象持有 ViewRootImpl 的引用，当 View 有此对象后，后续的所有 Runnable 都将直接交给 ViewRootImpl 处理。
- 3.ViewRootImpl在执行performTraversal方法是通过getRunQueue() 方法在 ThreadLocal中维护一个HandlerActionQueue对象，ViewRootImpl使用该对象对runnable进行短期维护。
- 4.但需要注意的是，各个 View 调用的 post 方法，仍然是由各自的 HandlerActionQueue 对象来入队任务的，然后在 View#dispatchAttachedToWindow 的时候转移给 ViewRootImpl 去处理。
另外，View.post也有不靠谱的地方，API24和23的post方法是有区别的，23的代码如下：
// Android API23 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 来入队任务的
ViewRootImpl.getRunQueue().post(action);
return true;
}
再来看一下 HandlerActionQueue#executeActions方法:
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;
}
}
post方法不靠谱的原因根本上是executeActions() 方法的调用时机不同，导致 View 在没有 mAttachInfo 对象的时候，表现不一样了。具体可参考这篇日志。
除此以外，ViewRootImpl 使用 ThreadLocal 来存储队列信息，在某些情境下，还会导致内存泄漏。详细信息可以参考：
