[[425705]]

本文轉(zhuǎn)載自微信公眾號(hào)「Android開發(fā)編程」，作者Android開發(fā)編程。轉(zhuǎn)載本文請(qǐng)聯(lián)系A(chǔ)ndroid開發(fā)編程公眾號(hào)。

前言

為什么 View.post() 的操作是可以對(duì) UI 進(jìn)行操作的呢，即使是在子線程中調(diào)用 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,直接調(diào)用其內(nèi)部Handler的post 
        return attachInfo.mHandler.post(action); 
    } 
    // 2、否則加入當(dāng)前View的等待隊(duì)列 
    getRunQueue().post(action); 
    return true; 
} 

• AttachInfo 是 View 的靜態(tài)內(nèi)部類，每個(gè) View 都會(huì)持有一個(gè) AttachInfo，它默認(rèn)為 null;
• 如果mAttachInfo為空，就執(zhí)行：把a(bǔ)ction加入當(dāng)前view的等待隊(duì)列;

2、getRunQueue().post()

看下 getRunQueue().post()：

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

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

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

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

3、HandlerAction

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; 
    } 
    // 比較是否是同一個(gè)任務(wù) 
    // 用于匹配某個(gè) Runnable 和對(duì)應(yīng)的HandlerAction 
    public boolean matches(Runnable otherAction) { 
        return otherAction == null && action == null 
                || action != null && action.equals(otherAction); 
    } 
} 

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

梳理總結(jié)：

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

4、AttachInfo

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

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

AttachInfo 中持有當(dāng)前線程的 Handler;

4.1、mAttachInfo 賦值：

void dispatchAttachedToWindow(AttachInfo info, int visibility) { 
    // 給當(dāng)前View賦值A(chǔ)ttachInfo，此時(shí)所有的View共用同一個(gè)AttachInfo（同一個(gè)ViewRootImpl內(nèi)） 
    mAttachInfo = info; 
    if (mOverlay != null) { 
        // 任何一個(gè)View都有一個(gè)ViewOverlay 
        // ViewGroup的是ViewGroupOverlay 
        // 它區(qū)別于直接在類似RelativeLaout/FrameLayout添加View，通過ViewOverlay添加的元素沒有任何事件 
        // 此時(shí)主要分發(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() 
    // 實(shí)際類型是 HandlerActionQueue，內(nèi)部保存了當(dāng)前View.post的任務(wù) 
    if (mRunQueue != null) { 
        // 執(zhí)行使用View.post的任務(wù) 
        // 注意這里是post到渲染線程的Handler中 
        mRunQueue.executeActions(info.mHandler); 
        // 保存延遲任務(wù)的隊(duì)列被置為null，因?yàn)榇藭r(shí)所有的View共用AttachInfo 
        mRunQueue = null; 
    } 
    performCollectViewAttributes(mAttachInfo, visibility); 
    // 回調(diào)View的onAttachedToWindow方法 
    // 在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還沒有開始繪制，不能正確獲取測(cè)量大小或View實(shí)際大小 
            listener.onViewAttachedToWindow(this); 
        } 
    } 
} 

5、executeActions

mRunQueue 就是保存了 View.post() 任務(wù)的 HandlerActionQueue;此時(shí)調(diào)用它的 executeActions 方法如下：

public void executeActions(Handler handler) { 
    synchronized (this) { 
        // 任務(wù)隊(duì)列 
        final HandlerAction[] actions = mActions; 
        // 遍歷所有任務(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; 
    } 
} 

• 遍歷所有已保存的任務(wù)，發(fā)送到 Handler 中排隊(duì)執(zhí)行;
• 將保存任務(wù)的 mActions 置為 null，因?yàn)楹罄m(xù) View.post() 直接添加到 AttachInfo 內(nèi)部的 Handler;

6、performTraversals

• dispatchAttachedToWindow() 的調(diào)用時(shí)機(jī)是在 View 繪制流程的開始階段;
• 在 ViewRootImpl 的 performTraversals 方法，在該方法將會(huì)依次完成 View 繪制流程的三大階段：測(cè)量、布局和繪制;

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

7、dispatchAttachedToWindow

• 每個(gè) Activity 都有一個(gè)關(guān)聯(lián)的 Window 對(duì)象，用來描述應(yīng)用程序窗口，每個(gè)窗口內(nèi)部又包含一個(gè) DecorView 對(duì)象，DecorView 對(duì)象用來描述窗口的視圖 — xml 布局;
• 通過 setContentView() 設(shè)置的 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的數(shù)量 
    final int count = mChildrenCount; 
    final View[] children = mChildren; 
    // 遍歷所有子View 
    for (int i = 0; i < count; i++) { 
        final View child = children[i]; 
        // 遍歷調(diào)用所有子View的dispatchAttachedToWindow 
        // 為每個(gè)子View關(guān)聯(lián)AttachInfo 
        child.dispatchAttachedToWindow(info, 
                combineVisibility(visibility, child.getVisibility())); 
    } 
} 

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

總結(jié)

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

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