轉(zhuǎn)載自 Carson帶你學(xué)Android：為什么view.post()能保證獲取到view的寬高？

• 背景
  業(yè)務(wù)需求代碼開始時(shí)機(jī)一般是在：Activity的生命周期onCreate()
  視圖View 繪制時(shí)機(jī)：Activity的生命周期onResume()之后

注：ActivityThread 的 handleResumeActivity()執(zhí)行順序：先回調(diào) Activity 生命周期 onResume() - 再開始 View 的繪制任務(wù)

• 矛盾
  業(yè)務(wù)需求代碼需獲取寬高的時(shí)機(jī) 跟 View的繪制時(shí)機(jī) 存在時(shí)序問題
  一般來說逛揩，業(yè)務(wù)需求代碼開始時(shí)就需要獲取View的相關(guān)信息（如寬季稳、高），但：View 繪制時(shí)機(jī)在Activity.onResume()之后辐啄，即在Activity.onCreate()之后 = 業(yè)務(wù)需求代碼開始后采章。

• 解決方案
  將需執(zhí)行的任務(wù)傳入到View.post() 。這個(gè)操作大家一定很熟悉壶辜。那么 其內(nèi)部原理是什么呢悯舟？

• 結(jié)論
  以Handler為基礎(chǔ)，View.post() 將傳入任務(wù)的執(zhí)行時(shí)機(jī)調(diào)整到View 繪制完成之后砸民。

源碼解析

我們直接從view.post()入手：

public boolean post(Runnable action) {
    
    // 僅貼出關(guān)鍵代碼
    // ...
    
    // 判斷AttachInfo是否為null
    final AttachInfo attachInfo = mAttachInfo;

    // 過程1：若不為null,直接調(diào)用其內(nèi)部Handler的post
    if (attachInfo != null) {
        
        return attachInfo.mHandler.post(action);
    }

    // 過程2：若為null抵怎，則加入當(dāng)前View的等待隊(duì)列
    getRunQueue().post(action); 
    // getRunQueue() 返回的是 HandlerActionQueue
    // action代表傳入的要執(zhí)行的任務(wù)
    // 即調(diào)用了HandlerActionQueue.post() ->> 分析1
    return true;
}

此處分成兩個(gè)過程講解：

當(dāng)AttachInfo不為null時(shí)，直接調(diào)用其內(nèi)部Handler的post岭参；
當(dāng)AttachInfo為null時(shí)反惕，則將任務(wù)加入當(dāng)前View的等待隊(duì)列中。
此處為了方便理解演侯，我會(huì)先講解過程2

過程2：當(dāng)AttachInfo為null時(shí)姿染，則將任務(wù)加入當(dāng)前View的等待隊(duì)列中。

public boolean post(Runnable action) {
    
    // 僅貼出關(guān)鍵代碼
    // ...
    
    // 判斷AttachInfo是否為null
    final AttachInfo attachInfo = mAttachInfo;

    // 過程1：若不為null,直接調(diào)用其內(nèi)部Handler的post
    if (attachInfo != null) {
        
        return attachInfo.mHandler.post(action);
    }

    // 過程2：若為null秒际，則加入當(dāng)前View的等待隊(duì)列
    getRunQueue().post(action); 
    // getRunQueue() 返回的是 HandlerActionQueue
    // action代表傳入的要執(zhí)行的任務(wù)
    // 即調(diào)用了HandlerActionQueue.post() ->> 分析1
    return true;
}

/**
  * 分析1：HandlerActionQueue.post()
  */
public void post(Runnable action) {
    // ...
    postDelayed(action, 0); 
    // ->> 分析2 
}

/**
  * 分析2
  */
public void postDelayed(Runnable action, long delayMillis) {
    // 1. 將傳入的任務(wù)runnable封裝成HandlerAction  ->>分析3
    final HandlerAction handlerAction = new HandlerAction(action, delayMillis);

    synchronized (this) {
        // 2. 將要執(zhí)行的HandlerAction 保存在 mActions 數(shù)組中
        if (mActions == null) {
            mActions = new HandlerAction[4];
        }

        mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
        mCount++;
    }
}

/**
  * 分析3：HandlerAction 表示一個(gè)待執(zhí)行的任務(wù)
  * 內(nèi)部持有要執(zhí)行的 Runnable 和延遲時(shí)間
  */
private static class HandlerAction {
    // post的任務(wù)
    final Runnable action;
    // 延遲時(shí)間
    final long delay;

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

結(jié)論：
將傳入的任務(wù)封裝成HandlerAction對(duì)象
創(chuàng)建一個(gè)默認(rèn)長度為4的 HandlerAction數(shù)組盔粹，用于保存通過post()添加的任務(wù)

注：此時(shí)只是保存了通過post()添加的任務(wù)隘梨，并沒執(zhí)行。

過程1：當(dāng)AttachInfo不為null時(shí)舷嗡，直接調(diào)用其內(nèi)部Handler的post()

public boolean post(Runnable action) {
    
    // ...
    
    // 判斷AttachInfo是否為null
    final AttachInfo attachInfo = mAttachInfo;

    // 過程1：若不為null,直接調(diào)用其內(nèi)部Handler的post ->>分析1
    if (attachInfo != null) {
        return attachInfo.mHandler.post(action);
    }

    // 過程2：若為null轴猎，則加入當(dāng)前View的等待隊(duì)列
    getRunQueue().post(action); 
    return true;
}

/**
  * 分析1：AttachInfo的賦值過程 -> dispatchAttachedToWindow()
  * 注：AttachInfo持有當(dāng)前渲染線程Handler
  */
  void dispatchAttachedToWindow(AttachInfo info, int visibility) {

    // ...

    // 給當(dāng)前View賦值A(chǔ)ttachInfo，此時(shí)同一個(gè)ViewRootImpl內(nèi)的所有View共用同一個(gè)AttachInfo
    mAttachInfo = info;

    //  mRunQueue进萄，即 前面說的 HandlerActionQueue
    // 其內(nèi)部保存了當(dāng)前View.post的任務(wù)
    if (mRunQueue != null) {
        mRunQueue.executeActions(info.mHandler);
        // 執(zhí)行使用View.post的任務(wù)捻脖，post到渲染線程的Handler中
        // ->> 分析2
    }

    // 在Activity的onResume()中調(diào)用，但是在View繪制流程之前
    onAttachedToWindow();
    
    ListenerInfo li = mListenerInfo;
    final CopyOnWriteArrayList<OnAttachStateChangeListener> listeners =
            li != null ? li.mOnAttachStateChangeListeners : null;
    if (listeners != null && listeners.size() > 0) {
        for (OnAttachStateChangeListener listener : listeners) {
            // 通知所有監(jiān)聽View已經(jīng)onAttachToWindow的客戶端中鼠，即view.addOnAttachStateChangeListener();
            // 但此時(shí)View還沒有開始繪制可婶，不能正確獲取測量大小或View實(shí)際大小
            listener.onViewAttachedToWindow(this);
        }
    }

    // ... 
}

/**
  * 分析2：HandlerActionQueue.executeActions()
  */
  public void executeActions(Handler handler) {
    synchronized (this) {
        
        final HandlerAction[] actions = mActions;
        // 任務(wù)隊(duì)列
        // mActions即為前面過程1 保存了通過post()添加的任務(wù) 的數(shù)組

        // 遍歷所有任務(wù)
        for (int i = 0, count = mCount; i < count; i++) {
            final HandlerAction handlerAction = actions[i];
            // 發(fā)送到Handler中，等待執(zhí)行
            handler.postDelayed(handlerAction.action, handlerAction.delay);
        }

        // 此時(shí)不再需要后續(xù)的post援雇，將被添加到AttachInfo中
        mActions = null;
        mCount = 0;
    }
}
// ->> 回到分析原處

結(jié)論
在AttachInfo被賦值時(shí)（即不為null）矛渴，就會(huì)遍歷 前面過程1保存了通過post()添加的任務(wù) 的數(shù)組，將每個(gè)任務(wù)發(fā)送到handler中等待執(zhí)行惫搏。

下面具温，我們繼續(xù)看，AttachInfo的賦值過程 -> dispatchAttachedToWindow()是什么時(shí)候被調(diào)用的筐赔。

  答：dispatchAttachedToWindow()調(diào)用時(shí)機(jī)是在 View 繪制流程
      的開始階段铣猩，即 ViewRootImpl.performTraversals()

/**
  * 基礎(chǔ)：
  * 1. AttachInfo的創(chuàng)建是在ViewRootImpl的構(gòu)造方法中
  * 2. 同一個(gè) View Hierachy 樹結(jié)構(gòu)中所有View共用一個(gè)AttachInfo
  */
  mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,context);

/**
  * dispatchAttachedToWindow()調(diào)用時(shí)機(jī) = View繪制流程開始
  * 即ViewRootImpl.performTraversals()
  */
    private void performTraversals() {

        // ...

        // mView是DecorView
        // host的類型是 DecorView（繼承自 FrameLayout）
        // 每個(gè)Activity都有一個(gè)關(guān)聯(lián)的 Window(當(dāng)前窗口)，每個(gè)窗口內(nèi)部又包含一個(gè) DecorView 對(duì)象(描述窗口的xml視圖布局）
        final View host = mView;

        // 調(diào)用DecorVIew的dispatchAttachedToWindow()
        // ->> 分析1
        host.dispatchAttachedToWindow(mAttachInfo, 0);
       
       getRunQueue().executeActions(mAttachInfo.mHandler);

       // 開始View繪制流程的測量茴丰、布局达皿、繪制階段
       performMeasure();
       performLayout();
       performDraw();
       ...

    }

/**
  * 分析1：DecorVIew.dispatchAttachedToWindow()
  * 注：DecorView并無重寫該方法，而是在其父類ViewGroup里 
  */
  void dispatchAttachedToWindow(AttachInfo info, int visibility) {
    super.dispatchAttachedToWindow(info, visibility);

    // 子View的數(shù)量
    final int count = mChildrenCount;
    final View[] children = mChildren;

    // 遍歷所有子View贿肩，調(diào)用所有子View的dispatchAttachedToWindow() & 為每個(gè)子View關(guān)聯(lián)AttachInfo
    // 子View 的 dispatchAttachedToWindow()在前面過程1已經(jīng)分析過：
    // 即 遍歷 前面過程1保存了通過post()添加的任務(wù) 的數(shù)組峦椰，將每個(gè)任務(wù)發(fā)送到handler中等待執(zhí)行。
    for (int i = 0; i < count; i++) {
        final View child = children[i];
        child.dispatchAttachedToWindow(info,combineVisibility(visibility, child.getVisibility()));
    }
   
    // ...
}

結(jié)論
通過View.post()添加的任務(wù)是在View繪制任務(wù)里 - 開始繪制階段時(shí)添加到消息隊(duì)列的尾部的汰规；
所以们何，View.post() 添加的任務(wù)的執(zhí)行是在View繪制任務(wù)后才執(zhí)行，即在View繪制流程結(jié)束之后執(zhí)行
即View.post() 添加的任務(wù)能夠保證在所有 View繪制流程結(jié)束之后才被執(zhí)行控轿，所以 執(zhí)行View.post() 添加的任務(wù)時(shí)可以正確獲取到 View 的寬高冤竹。

額外延伸

a. 問題描述
若只是創(chuàng)建一個(gè) View & 調(diào)用它的post()，那么post的任務(wù)會(huì)不會(huì)被執(zhí)行茬射？

final View view = new View(this);

    view.post(new Runnable() {
        @Override
        public void run() {
            // ...
        }
    });

b. 答案
不會(huì)鹦蠕。主要原因是：

每個(gè)View中post() 需執(zhí)行的任務(wù)，必須得添加到窗口視圖-執(zhí)行繪制流程 - 任務(wù)才會(huì)被post到消息隊(duì)列里去等待執(zhí)行在抛，即依賴于dispatchAttachedToWindow ()钟病；

若View未添加到窗口視圖，那么就不會(huì)走繪制流程，post() 添加的任務(wù)最終不會(huì)被post到消息隊(duì)列里肠阱，即得不到執(zhí)行票唆。（但會(huì)保存到HandlerAction數(shù)組里）

上述例子，因?yàn)樗鼪]有被添加到窗口視圖屹徘，所以不會(huì)走繪制流程走趋，所以該任務(wù)最終不會(huì)被post到消息隊(duì)列里 & 執(zhí)行

c. 解決方案
此時(shí)只需要添加將View添加到窗口，那么post()的任務(wù)即可被執(zhí)行

// 因?yàn)榇藭r(shí)會(huì)重新發(fā)起繪制流程噪伊，post的任務(wù)會(huì)被放到消息隊(duì)列里簿煌，所以會(huì)被執(zhí)行
contentView.addView(view);
至此，關(guān)于view.post()原理講解完畢

總結(jié)

    View.post()的原理：以Handler為基礎(chǔ)鉴吹，
    View.post() 將傳入任務(wù)添加到 View繪制任務(wù)所在的消息隊(duì)列
    尾部姨伟，從而保證View.post() 任務(wù)的執(zhí)行時(shí)機(jī)是在View
    繪制任務(wù)完成之后的。 其中豆励，幾個(gè)關(guān)鍵點(diǎn)：

1-View.post()實(shí)際操作：將view.post()傳入的任務(wù)保存到一個(gè)數(shù)組里
2-View.post()添加的任務(wù) 添加到 View繪制任務(wù)所在的消息隊(duì)列尾部的時(shí)機(jī)：View 繪制流程的開始階段夺荒，即 ViewRootImpl.performTraversals()
3-View.post()添加的任務(wù)執(zhí)行時(shí)機(jī)：在View繪制任務(wù)之后