View.post获取控件宽高原理探索

首先写这篇文章之前贴上二篇分析较好的博客，非常感谢博主的奉献精神
http://blog.csdn.net/scnuxisan225/article/details/49815269
http://mp.weixin.qq.com/s/laR3_Xvr0Slb4oR8D1eQyQ

大家都遇到过在android开发时,在Activity中的onCreate方法中通过控件的getMeasureHeight/getHeight或者getMeasureWidth/getWidth方法获取到的宽高大小都是0，我相信大家遇到这种问题时首先会想到打开度娘然后一搜，常见的二种解决方案就出来了。

1.通过监听Draw/Layout事件：ViewTreeObserver

 1 view.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
 2         @Override
 3         public void onGlobalLayout() {
 4             mScrollView.post(new Runnable() {
 5                 public void run() {
 6                     view.getHeight(); //height is ready
 7                 }
 8             });
 9         }
10 });

当我们注册这个监听时，控件经过 onMeasure->onLayout->onDraw一系列方法渲染完成后会去回调这个注册的监听，我们自然能拿到控件的宽高。

2.第二种方法我比较喜欢，只要用View.post()一个runnable就可以了

1 ...
2       view.post(new Runnable() {
3             @Override
4             public void run() {
5                 view.getHeight(); //height is ready
6             }
7         });
8 ...

我们一般这么用总能拿到控件的宽高大小，方法是非常好用，但是本着十万个为什么态度，我决定把这个方法的原理整理一遍。

我们先回忆下，android中每个界面是个Activity,每个Activity最顶层是一个DecorView,它包裹我们自定义的布局.
好接下来我们看下View的post方法干了什么

    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;
    }

这里面判断mAttachInfo是不是为空，如果不为null时，直接取出mAttachInfo中存放的Handler对象去post 我们的Runnable任务,如果为null的话我们看看getRunQueue()方法会做什么

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

它会去创建一次HandlerActionQueue对象然后把这个对象返回，好我们点进这个对象看一下

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++;
        }
    }
....

我们之前代码可以看到如果mAttachInfo为null的话会去调用HandlerActionQueue对象中的post方法传递我们Runnable任务，接着会调用postDelayed方法，这个方法会把我们的Runnable任务和需要延迟的时间都封装到HandlerAction对象中然后加入到下面的HandlerAction[]数组中,点进去也会发现HandlerAction 就是一个简单的封装类。

 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);
        }
    }

现在我们回过头思考一下就会有疑惑了，情景回到post方法中,我们根据mAttachInfo这个值判断是直接post发送任务还是把任务放入队列，那么这个值是什么时候被赋值的呢？

答案就在ViewRootImpl类中，在ViewRootImpl构造中有这么端代码创建了AttachInfo对象。

 mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this);

然后在performTraversals()方法中会去调用这么段代码 ，这段代码执行在大家很熟悉的 performMeasure、performLayout、performDraw方法之前。

host.dispatchAttachedToWindow(mAttachInfo, 0);

host就是DecorView，它是一个ViewGroup，所以我们先看看ViewGroup中的dispatchAttachedToWindow方法

    @Override
    void dispatchAttachedToWindow(AttachInfo info, int visibility) {
        mGroupFlags |= FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW;
        super.dispatchAttachedToWindow(info, visibility);
        mGroupFlags &= ~FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW;

        final int count = mChildrenCount;
        final View[] children = mChildren;
        for (int i = 0; i < count; i++) {
            final View child = children[i];
            child.dispatchAttachedToWindow(info,
                    combineVisibility(visibility, child.getVisibility()));
        }
        final int transientCount = mTransientIndices == null ? 0 : mTransientIndices.size();
        for (int i = 0; i < transientCount; ++i) {
            View view = mTransientViews.get(i);
            view.dispatchAttachedToWindow(info,
                    combineVisibility(visibility, view.getVisibility()));
        }
    }

可以看到主要这个方法中会调用自己和所有child父类也就是View中的dispatchAttachedToWindow方法，那我们看看View中的dispatchAttachedToWindow方法究竟干了些什么事情吧？

  /**
     * @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);
        }
        mWindowAttachCount++;
        // We will need to evaluate the drawable state at least once.
        mPrivateFlags |= PFLAG_DRAWABLE_STATE_DIRTY;
        if (mFloatingTreeObserver != null) {
            info.mTreeObserver.merge(mFloatingTreeObserver);
            mFloatingTreeObserver = null;
        }

        registerPendingFrameMetricsObservers();

        if ((mPrivateFlags&PFLAG_SCROLL_CONTAINER) != 0) {
            mAttachInfo.mScrollContainers.add(this);
            mPrivateFlags |= PFLAG_SCROLL_CONTAINER_ADDED;
        }
        // Transfer all pending runnables.
        if (mRunQueue != null) {
            mRunQueue.executeActions(info.mHandler);
            mRunQueue = null;
        }
        performCollectViewAttributes(mAttachInfo, visibility);
        onAttachedToWindow();

        ListenerInfo li = mListenerInfo;
        final CopyOnWriteArrayList listeners =
                li != null ? li.mOnAttachStateChangeListeners : null;
        if (listeners != null && listeners.size() > 0) {
            // NOTE: because of the use of CopyOnWriteArrayList, we *must* use an iterator to
            // perform the dispatching. The iterator is a safe guard against listeners that
            // could mutate the list by calling the various add/remove methods. This prevents
            // the array from being modified while we iterate it.
            for (OnAttachStateChangeListener listener : listeners) {
                listener.onViewAttachedToWindow(this);
            }
        }

        int vis = info.mWindowVisibility;
        if (vis != GONE) {
            onWindowVisibilityChanged(vis);
            if (isShown()) {
                // Calling onVisibilityChanged directly here since the subtree will also
                // receive dispatchAttachedToWindow and this same call
                onVisibilityAggregated(vis == VISIBLE);
            }
        }

        // Send onVisibilityChanged directly instead of dispatchVisibilityChanged.
        // As all views in the subtree will already receive dispatchAttachedToWindow
        // traversing the subtree again here is not desired.
        onVisibilityChanged(this, visibility);

        if ((mPrivateFlags&PFLAG_DRAWABLE_STATE_DIRTY) != 0) {
            // If nobody has evaluated the drawable state yet, then do it now.
            refreshDrawableState();
        }
        needGlobalAttributesUpdate(false);
    }

这段代码比较长但是我们一眼就可以看到mAttachInfo 正是在这里被赋值的，而被赋值调用的地方正是在上面ViewRootImpl中的performTraversals()方法中！
然后我们接着看这个方法

 mRunQueue.executeActions(info.mHandler);

调用了这句代码，执行了我们前面提到的HandlerAction类中的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;
        }
    }

ok,一切思路都那么清晰了，这个方法会用我们传递进来的mAttachInfo中的Handler去遍历我们View.post储存的所有Runnable任务。

至此貌似所有的流程都分析完毕了，但是如果有细心的同学会发现前面的分析有漏洞，哪里呢？就是在执行ViewRootImpl中的performTraversals()方法的时候，

host.dispatchAttachedToWindow(mAttachInfo, 0);

调用这个方法明明执行在测量,布局,绘制三个方法之前，也就是说调用这个方法后就会拿到我们传递mAttachInfo中Handler去执行View.post中的Runnable,然后才会去调用测量,布局,绘制三个方法,那理论上还是拿不到宽高值啊，这个时候还没执行测量啊，可是为什么结果可以拿到呢？？？

没关系，我一开始也是这么认为的并且陷入了很长一段时间的困惑当中，这是由于不了解android消息机制导致的，Android的运行其实是一个消息驱动模式,也就是说在Android主线程中默认是创建了一个Handler的，并且这个主线程中创建了一个Looper去循环遍历执行队列中的Message,这个执行是同步的，也就是说执行完一个Message后才会去继续执行下一个，调用performTraversals()这个方法是通过主线程的Looper遍历执行的，这个方法还没执行结束，然后我们在这个方法中通过mAttachInfo中Handler去执行View.post中的Runnable,mAttachInfo中Handler也是创建在主线程，所以它会在上一个消息执行结束后才会被执行,也就是说会在测量,布局,绘制执行后才执行，这样自然而然能拿到控件的宽和高啦。

我不禁敬佩，Android团队的这个机制设计的太巧妙了。