簡述：

寫這篇文章的緣由是最近專案中查記憶體洩漏時，發現最終原因是由於非同步執行緒呼叫View的的post方法導致的。
為何我會使用非同步執行緒呼叫View的post方法，是因為專案中需要用到很多複雜的自定義佈局，需要提前解析進入記憶體，防止在主執行緒解析導致卡頓，具體的實現方法是在Application啟動的時候，使用非同步執行緒解析這些佈局，等需要使用的時候直接從記憶體中拿來用。
造成記憶體洩漏的原因，需要先分析View的post方法執行流程，也就是文章前半部分的內容

文章內容：

1. View#post方法作用以及實現原始碼
2. View#post與Handler#post的區別
3. 分析View#post方法導致的記憶體洩漏

post方法分析

看看View的post方法註釋：

Causes the Runnable to be added to the message queue. The runnable will be run on the user interface thread

意思是將runnable加入到訊息佇列中，該runnable將會在使用者介面執行緒中執行，也就是UI執行緒。這解釋，和Handler的作用差不多，然而事實並非如此。

再看看post方法的原始碼：

public boolean post(Runnable action) {
    final
 
 AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        // 如果當前View加入到了window中，直接呼叫UI執行緒的Handler傳送訊息
        return attachInfo.mHandler.post(action);
    }
    // Assume that post will succeed later
    // View未加入到window，放入ViewRootImpl的RunQueue中
    ViewRootImpl.getRunQueue().post(action);
    return
 
 true;
}

分兩種情況，當View已經attach到window，直接呼叫UI執行緒的Handler傳送runnable。如果View還未attach到window，將runnable放入ViewRootImpl的RunQueue中。

那麼post到RunQueue裡的runnable什麼時候執行呢，又是為何當View還沒attach到window的時候，需要post到RunQueue中。

View#post與Handler#post的區別

其實，當View已經attach到了window，兩者是沒有區別的，都是呼叫UI執行緒的Handler傳送runnable到MessageQueue，最後都是由handler進行訊息的分發處理。

但是如果View尚未attach到window的話，runnable被放到了ViewRootImpl#RunQueue中，最終也會被處理，但不是通過MessageQueue。

ViewRootImpl#RunQueue原始碼註釋如下：

/**
 * The run queue is used to enqueue pending work from Views when no Handler is
 * attached.  The work is executed during the next call to performTraversals on
 * the thread.
 * @hide
 */

大概意思是當檢視樹尚未attach到window的時候，整個檢視樹是沒有Handler的（其實自己可以new，這裡指的handler是AttachInfo裡的），這時候用RunQueue來實現延遲執行runnable任務，並且runnable最終不會被加入到MessageQueue裡，也不會被Looper執行，而是等到ViewRootImpl的下一個performTraversals時候，把RunQueue裡的所有runnable都拿出來並執行，接著清空RunQueue。

由此可見RunQueue的作用類似於MessageQueue，只不過，這裡面的所有
runnable最後的執行時機，是在下一個performTraversals到來的時候，MessageQueue裡的訊息處理的則是下一次loop到來的時候。RunQueue原始碼：

static final class RunQueue {
    // 存放所有runnable，HandlerAction是對runnable的包裝物件
    private final ArrayList<HandlerAction> mActions = new ArrayList<HandlerAction>();

    // view沒有attach到window的時候，View#post最終呼叫到這
    void post(Runnable action) {
        postDelayed(action, 0);
    }

    // view沒有attach到window的時候，View#postDelay最終呼叫到這
    void postDelayed(Runnable action, long delayMillis) {
        HandlerAction handlerAction = new HandlerAction();
        handlerAction.action = action;
        handlerAction.delay = delayMillis;

        synchronized (mActions) {
            mActions.add(handlerAction);
        }
    }

    // 移除一個runnable任務，
    // view沒有attach到window的時候，View#removeCallbacks最終呼叫到這
    void removeCallbacks(Runnable action) {
        final HandlerAction handlerAction = new HandlerAction();
        handlerAction.action = action;

        synchronized (mActions) {
            final ArrayList<HandlerAction> actions = mActions;

            while (actions.remove(handlerAction)) {
                // Keep going
            }
        }
    }

    // 取出所有的runnable並執行，接著清空RunQueue集合
    void executeActions(Handler handler) {
        synchronized (mActions) {
            final ArrayList<HandlerAction> actions = mActions;
            final int count = actions.size();

            for (int i = 0; i < count; i++) {
                final HandlerAction handlerAction = actions.get(i);
                handler.postDelayed(handlerAction.action, handlerAction.delay);
            }

            actions.clear();
        }
    }

    // 對runnable的封裝類，記錄runnable以及delay時間
    private static class HandlerAction {
        Runnable action;
        long delay;

        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (o == null || getClass() != o.getClass()) return false;

            HandlerAction that = (HandlerAction) o;
            return !(action != null ? !action.equals(that.action) : that.action != null);

        }

        @Override
        public int hashCode() {
            int result = action != null ? action.hashCode() : 0;
            result = 31 * result + (int) (delay ^ (delay >>> 32));
            return result;
        }
    }
}

再看看RunQueue裡的訊息處理位置，ViewRootImpl#performTraversals：

private void performTraversals() {

    // ....

    // Execute enqueued actions on every traversal in case a detached view enqueued an action
    getRunQueue().executeActions(mAttachInfo.mHandler);

    // ....
}

也就是說，當View沒有被attach到window的時候，最後runnable的處理不是通過MessageQueue，而是ViewRootImpl自己在下一個performTraversals到來的時候執行。

為了驗證RunQueue裡的runnable是在下一個performTraversals到來的時候執行的，做一個測試（在Activity的onCreate方法中）：

// Activity的跟佈局
ViewGroup viewGroup = (ViewGroup) getWindow().getDecorView();
// 自己new的一個View，等待attach到window中
final View view = new View(getApplicationContext()) {
    @Override
    protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
        super.onLayout(changed, left, top, right, bottom);
        // view執行了layout
        Log.e(TAG, "view layout");
    }
};

// 在View未attach到window上之前，
// 使用Handler#post傳送一個runnable（最終到了MessageQueue中）
mHandler.post(new Runnable() {
    @Override
    public void run() {
        // 獲取View的寬高，檢視View是否已經layout
        Log.e(TAG, "MessageQueue runnable, view width = " + view.getWidth() + "  height = " + view.getHeight());
    }
});

// 在View未attach到window上之前，
// 使用View#post傳送一個runnable（最終到了ViewRootImpl#RunQueue中）
view.post(new Runnable() {
    @Override
    public void run() {
        // 獲取View的寬高，檢視View是否已經layout
        Log.e(TAG, "RunQueue runnable, view width = " + view.getWidth() + "  height = " + view.getHeight());
    }
});

// 將view新增到window中
viewGroup.addView(view);

Log：

打印出來的日誌說明：
1. 使用handler#post的runnable最先執行，此時View還未layout，無法獲取view的寬高。
2. 接著view的onLayout方法執行，表示view完成了位置的佈置，此時可以獲取寬高。
3. view#post的runnable最後執行，也就是說view已經layout完成才執行，此時能夠獲取View的寬高。

這裡提一下，下一次performTraversals到來的時候，View可能attach到了window上，也可能未attach到window上，也就是程式碼最後不執行addView動作，使用view#post的runnable仍然無法獲取View的寬高，修改如下：

// viewGroup.addView(view);

Log：

我們經常碰到一個問題，就是new一個View之後，通過addView新增到檢視樹或者是在Activity的onCreate方法裡呼叫setContentView方法。緊接著，我們想獲取View的寬高，但是因為view的measure和layout都還未執行，所以是獲取不到寬高的。
view#post的一個作用是，在下一個performTraversals到來的時候，也就是view完成layout之後的第一時間獲取寬高。

View#post方法導致的記憶體洩漏

分析洩漏之前需要檢視ViewRootImpl裡的RunQueue成員變數定義以及建立過程：

// 用ThreadLocal物件來儲存ViewRootImpl的RunQueue例項
static final ThreadLocal<RunQueue> sRunQueues = new ThreadLocal<RunQueue>();

static RunQueue getRunQueue() {
    RunQueue rq = sRunQueues.get();
    if (rq != null) {
        return rq;
    }
    // 如果當前執行緒沒有建立RunQueue例項，建立並儲存在sRunQueues中
    rq = new RunQueue();
    sRunQueues.set(rq);
    return rq;
}

首先這裡的ThreadLocal內部持有的例項是執行緒單利的，也就是不同的執行緒呼叫sRunQueues.get()得到的不是同一個物件。

ViewRootImpl使用ThreadLocal來儲存RunQueue例項，一般來說，ViewRootImpl#getRunQueue都是在UI執行緒使用，所以RunQueue例項只有一個。UI執行緒的物件引用關係：

UIThread是應用程式啟動的時候，新建的一個執行緒，生命週期與應用程式一致，也就是說UI執行緒對應的RunQueue例項是無法被回收的，但是無所謂，因為每次ViewRootImpl#performTraversals方法被呼叫時都會把RunQueue裡的所有Runnable物件執行並清除。

接著，如果是非同步執行緒呼叫了View#post方法：

new Thread(new Runnable() {
    @Override
    public void run() {
        new View(getApplicationContext()).post(new Runnable() {
            @Override
            public void run() {
            }
        });
    }
}).start();

這裡的的物件引用關係：

這裡定義的Thread只是一個臨時物件，並沒有被GC-Root持有，是可以被垃圾回收器回收的，那麼我們post出去的Runnable只是不會被執行而已，最後還是會被回收，並不會造成記憶體洩漏。

但是如果，這個Thread是一個靜態變數的話，那麼我們使用非同步執行緒post出去的Runnable也就洩漏了，如果這些runnable又引用了View物件或者是Activity物件，就會造成更大範圍的洩漏。

雖然，Thread被定義成靜態變數的情況很少出現。但是執行緒池被定義成靜態變數卻常常出現，例如我們應用程式中，經常會定義一些靜態執行緒池物件用來實現執行緒的複用，比如下面的這個執行緒池管理類GlobalThreadPool：

public class GlobalThreadPool {

    private static final int SIZE = 3;
    private static ScheduledExecutorService mPool;

    public static ScheduledExecutorService getGlobalThreadPoolInstance() {
        if (mPool == null) {
            synchronized (GlobalThreadPool.class) {
                if (mPool == null) {
                    mPool = Executors.newScheduledThreadPool(SIZE);
                }
            }
        }
        return mPool;
    }

    /**
     * run a thead ,== new thread
     */
    public static void startRunInThread(Runnable doSthRunnable) {
        getGlobalThreadPoolInstance().execute(doSthRunnable);
    }
}

接著再把非同步處理呼叫View#post的程式碼改改：

GlobalThreadPool.startRunInThread(new Runnable() {
    @Override
    public void run() {
        new View(MainActivity.this).post(new Runnable() {
            @Override
            public void run() {
            }
        });
    }
});

這樣的話，物件引用關係就變成了：

匯出的heap檔案hprof檢視物件引用關係：

最後，回到文章開頭簡述中說的，專案中使用非同步執行緒解析佈局檔案，當解析的佈局檔案的時候，如果佈局檔案中包含TextView，這時候，android系統4.4-5.2的機器，就會出現記憶體洩漏，具體為什麼往下看。

1. TextView的構造方法呼叫用了setText方法。
2. setText方法又呼叫了notifyViewAccessibilityStateChangedIfNeeded方法。
3. notifyViewAccessibilityStateChangedIfNeeded方法又建立了一個SendViewStateChangedAccessibilityEvent物件，緊接著又呼叫了SendViewStateChangedAccessibilityEvent物件的runOrPost方法。
4. runOrPost方法最終又呼叫了View的post方法。

上面這一大串流程，導致的結果就是非同步執行緒呼叫了View的post方法，如果這裡的執行緒是核心執行緒，也就是一直會存在於執行緒池中的執行緒，並且執行緒池又是靜態的，就導致使用非同步執行緒建立多個TextView相當於是往非同步執行緒的RunQueue中加入多個Runnable，而Runable又引用了View，導致View的洩漏。

洩漏的物件引用關係和上面主動呼叫View的post方法類似。

至於為什麼4.4-5.2的機器才會洩漏，是因為4.4-5.2的系統，View中notifyViewAccessibilityStateChangedIfNeeded方法並沒有判斷View是否attach到了window，直到google釋出的android_6.0系統才修復該問題，該問題可以說是google的問題，因為google官方在Support_v4包中就提供了非同步執行緒載入佈局檔案的框架，具體參閱：android.support.v4.view.AsyncLayoutInflater

傳送門：https://developer.android.com/reference/android/support/v4/view/AsyncLayoutInflater.html

總結：

1. 當View已經attach到window，不管什麼執行緒， 呼叫View#post 和 呼叫Handler#post效果一致
2. 當View尚未attach到window，主執行緒呼叫View#post傳送的runnable將在下一次performTraversals到來時執行，而非主執行緒呼叫View#post傳送的runnable將無法被執行。
3. 可以通過在主執行緒呼叫View#post傳送runnable來獲取下一次performTraversals時檢視樹中View的佈局資訊，如寬高。
4. 如果呼叫View#post方法的執行緒物件被GC-Root引用，則傳送的runnable將會造成記憶體洩漏。