[[425705]]

本文轉載自微信公眾號「Android開發(fā)編程」，作者Android開發(fā)編程。轉載本文請聯(lián)系Android開發(fā)編程公眾號。

前言

為什么 View.post() 的操作是可以對 UI 進行操作的呢，即使是在子線程中調用 View.post()?

今天我們就來分析分析

一、View.post源碼深入分析

1、View.post()

View 的 post 方法如下：

public boolean post(Runnable action) { 
    // 1、首先判斷AttachInfo是否為null 
    final AttachInfo attachInfo = mAttachInfo; 
    if (attachInfo != null) { 
        // 1.1如果不為null,直接調用其內部Handler的post 
        return attachInfo.mHandler.post(action); 
    } 
    // 2、否則加入當前View的等待隊列 
    getRunQueue().post(action); 
    return true; 
} 

• AttachInfo 是 View 的靜態(tài)內部類，每個 View 都會持有一個 AttachInfo，它默認為 null;
• 如果mAttachInfo為空，就執(zhí)行：把action加入當前view的等待隊列;

2、getRunQueue().post()

看下 getRunQueue().post()：

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

• getRunQueue() 返回的是 HandlerActionQueue;
• 調用了 HandlerActionQueue 的 post 方法：

public void post(Runnable action) { 
    // 調用到postDelayed方法，這有點類似于Handler發(fā)送消息 
    postDelayed(action, 0); 
} 

// 實際調用postDelayed 
public void postDelayed(Runnable action, long delayMillis) { 
    // HandlerAction表示要執(zhí)行的任務 
    final HandlerAction handlerAction = new HandlerAction(action, delayMillis); 
    synchronized (this) { 
        if (mActions == null) { 
            // 創(chuàng)建一個保存HandlerAction的數組 
            mActions = new HandlerAction[4]; 
        } 
        // 表示要執(zhí)行的任務HandlerAction 保存在 mActions 數組中 
        mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction); 
        // mActions數組下標位置累加1 
        mCount++; 
    } 
} 

3、HandlerAction

HandlerAction 表示一個待執(zhí)行的任務，內部持有要執(zhí)行的 Runnable 和延遲時間;=

private static class HandlerAction { 
    // post的任務 
    final Runnable action; 
    // 延遲時間 
    final long delay; 
    public HandlerAction(Runnable action, long delay) { 
        this.action = action; 
        this.delay = delay; 
    } 
    // 比較是否是同一個任務 
    // 用于匹配某個 Runnable 和對應的HandlerAction 
    public boolean matches(Runnable otherAction) { 
        return otherAction == null && action == null 
                || action != null && action.equals(otherAction); 
    } 
} 

postDelayed() 創(chuàng)建一個默認長度為 4 的 HandlerAction 數組，用于保存 post() 添加的任務;

梳理總結：

• 我們調用 View.post(Runnable) 傳進去的 Runnable 操作，在傳到 HandlerActionQueue 里會先經過 HandlerAction 包裝一下，然后再緩存起來;
• 在 執(zhí)行 View.post(Runnable) 時，因為這時候 View 還沒有 attachedToWindow，所以這些 Runnable 操作其實并沒有被執(zhí)行，而是先通過 HandlerActionQueue 緩存起來;

4、AttachInfo

看下 AttachInfo 的創(chuàng)建過程，先看下它的構造方法：

AttachInfo(IWindowSession session, IWindow window, Display display, 
               ViewRootImpl viewRootImpl, Handler handler, Callbacks effectPlayer, 
               Context context) { 
        mSession = session; 
        mWindow = window; 
        mWindowToken = window.asBinder(); 
        mDisplay = display; 
        // 持有當前ViewRootImpl 
        mViewRootImpl = viewRootImpl; 
        // 當前渲染線程Handler 
        mHandler = handler; 
        mRootCallbacks = effectPlayer; 
        mTreeObserver = new ViewTreeObserver(context); 
    } 

AttachInfo 中持有當前線程的 Handler;

4.1、mAttachInfo 賦值：

void dispatchAttachedToWindow(AttachInfo info, int visibility) { 
    // 給當前View賦值AttachInfo，此時所有的View共用同一個AttachInfo（同一個ViewRootImpl內） 
    mAttachInfo = info; 
    if (mOverlay != null) { 
        // 任何一個View都有一個ViewOverlay 
        // ViewGroup的是ViewGroupOverlay 
        // 它區(qū)別于直接在類似RelativeLaout/FrameLayout添加View，通過ViewOverlay添加的元素沒有任何事件 
        // 此時主要分發(fā)給這些View浮層 
        mOverlay.getOverlayView().dispatchAttachedToWindow(info, visibility); 
    } 
    mWindowAttachCount++; 
    if ((mPrivateFlags & PFLAG_SCROLL_CONTAINER) != 0) { 
        mAttachInfo.mScrollContainers.add(this); 
        mPrivateFlags |= PFLAG_SCROLL_CONTAINER_ADDED; 
    } 
    //  mRunQueue，就是在前面的 getRunQueue().post() 
    // 實際類型是 HandlerActionQueue，內部保存了當前View.post的任務 
    if (mRunQueue != null) { 
        // 執(zhí)行使用View.post的任務 
        // 注意這里是post到渲染線程的Handler中 
        mRunQueue.executeActions(info.mHandler); 
        // 保存延遲任務的隊列被置為null，因為此時所有的View共用AttachInfo 
        mRunQueue = null; 
    } 
    performCollectViewAttributes(mAttachInfo, visibility); 
    // 回調View的onAttachedToWindow方法 
    // 在Activity的onResume方法中調用，但是在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已經onAttachToWindow的客戶端，即view.addOnAttachStateChangeListener(); 
            // 但此時View還沒有開始繪制，不能正確獲取測量大小或View實際大小 
            listener.onViewAttachedToWindow(this); 
        } 
    } 
} 

5、executeActions

mRunQueue 就是保存了 View.post() 任務的 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]; 
            //發(fā)送到Handler中，等待執(zhí)行 
            handler.postDelayed(handlerAction.action, handlerAction.delay); 
        } 
        //此時不在需要，后續(xù)的post，將被添加到AttachInfo中 
        mActions = null; 
        mCount = 0; 
    } 
} 

• 遍歷所有已保存的任務，發(fā)送到 Handler 中排隊執(zhí)行;
• 將保存任務的 mActions 置為 null，因為后續(xù) View.post() 直接添加到 AttachInfo 內部的 Handler;

6、performTraversals

• dispatchAttachedToWindow() 的調用時機是在 View 繪制流程的開始階段;
• 在 ViewRootImpl 的 performTraversals 方法，在該方法將會依次完成 View 繪制流程的三大階段：測量、布局和繪制;

// View 繪制流程開始在 ViewRootImpl 
private void performTraversals() { 
    // mView是DecorView 
    final View host = mView; 
    if (mFirst) { 
        ..... 
        // host為DecorView 
        // 調用DecorVIew 的 dispatchAttachedToWindow，并且把 mAttachInfo 給子view 
        host.dispatchAttachedToWindow(mAttachInfo, 0); 
        mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true); 
        dispatchApplyInsets(host); 
        ..... 
    }  
   mFirst=false 
   getRunQueue().executeActions(mAttachInfo.mHandler); 
   // View 繪制流程的測量階段 
   performMeasure(); 
   // View 繪制流程的布局階段 
   performLayout(); 
   // View 繪制流程的繪制階段 
   performDraw(); 
} 

7、dispatchAttachedToWindow

• 每個 Activity 都有一個關聯(lián)的 Window 對象，用來描述應用程序窗口，每個窗口內部又包含一個 DecorView 對象，DecorView 對象用來描述窗口的視圖 — xml 布局;
• 通過 setContentView() 設置的 View 布局最終添加到 DecorView 的 content 容器中;
• DecorView 的 dispatchAttachedToWindow 方法的執(zhí)行過程，DecorView 并沒有重寫該方法，而是在其父類 ViewGroup 中：

void dispatchAttachedToWindow(AttachInfo info, int visibility) { 
    mGroupFlags |= FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW; 
    super.dispatchAttachedToWindow(info, visibility); 
    mGroupFlags &= ~FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW; 
    // 子View的數量 
    final int count = mChildrenCount; 
    final View[] children = mChildren; 
    // 遍歷所有子View 
    for (int i = 0; i < count; i++) { 
        final View child = children[i]; 
        // 遍歷調用所有子View的dispatchAttachedToWindow 
        // 為每個子View關聯(lián)AttachInfo 
        child.dispatchAttachedToWindow(info, 
                combineVisibility(visibility, child.getVisibility())); 
    } 
} 

• for 循環(huán)遍歷當前 ViewGroup 的所有 childView，為其關聯(lián) AttachInfo;
• 子 View 的 dispatchAttachedToWindow，首先為當前 View 關聯(lián) AttachInfo，然后將之前 View.post() 保存的任務添加到 AttachInfo 內部的 Handler;
• performTraversals() 會先執(zhí)行 dispatchAttachedToWindow()，這時候所有子 View 通過 View.post(Runnable) 緩存起來的 Runnable 操作就都會通過 mAttachInfo.mHandler 的 post() 方法將這些 Runnable 封裝到 Message 里發(fā)送到 MessageQueue 里;
• mHandler 我們上面也分析過了，綁定的是主線程的 Looper，所以這些 Runnable 其實都是發(fā)送到主線程的 MessageQueue 里排隊，等待執(zhí)行。然后 performTraversals() 繼續(xù)往下工作，相繼執(zhí)行 performMeasure()，performLayout() 等操作;
• 等全部執(zhí)行完后，表示這個 Message 已經處理完畢，所以 Looper 才會去取下一個 Message，這時候，才有可能輪到這些 Runnable 執(zhí)行;
• 所以，這些 Runnable 操作也就肯定會在 performMeasure() 操作之后才執(zhí)行，寬高也就可以獲取到了;

總結

View.post(Runnable) 內部會自動分兩種情況處理，當 View 還沒 attachedToWindow 時，會先將這些 Runnable 操作緩存下來;否則就直接通過 mAttachInfo.mHandler 將這些 Runnable 操作 post 到主線程的 MessageQueue 中等待執(zhí)行;

View.post() 任務能夠保證在所有 View 繪制流程結束之后被調用，故如果需要依賴 View 繪制任務，此時可以優(yōu)先考慮使用該機制;