這個(gè)問(wèn)題，可以換成“為什么在onCreate里面修改一些子View不生效，錯(cuò)位，亂”等問(wèn)題。
本質(zhì)原因肯定是在沒(méi)有把整個(gè)ViewGroup渲染完成之前，操作了部分子View，導(dǎo)致了位置偏移等。

解決辦法也很簡(jiǎn)單，通過(guò)調(diào)用View.post(), 注意是View的post。
這樣就延遲了我們執(zhí)行的動(dòng)作，到了渲染完成之后，才進(jìn)行操作，避免的錯(cuò)亂的產(chǎn)生。

流程分析

渲染完成，換成代碼上是什么意思？
就是三大流程走完成。
在沒(méi)完成之前，調(diào)用任何的translation等操作，就可能導(dǎo)致測(cè)量顯示錯(cuò)誤，錯(cuò)位。

Activity：

1. handleResumeActivity（該方法內(nèi)使用Context.getWindowManager創(chuàng)建WindowManager對(duì)象）
   WindowManager：
2. addView（該方法內(nèi)WindowManager委托代理給一個(gè)WindowManagerGLobal對(duì)象）
   WindowManagerGLobal：
3. addView（該方法內(nèi)創(chuàng)建了ViewRootImpl對(duì)象）
   ViewRootImpl：setView→requestLayout→scheduleTraversals→doTraversal→performTraversals（最終到達(dá)繪制的入口）
   3.1 performTraversals里面會(huì)往所有子View dispatchAttachedToWindow, 并設(shè)定mAttachInfo，即有了handler。
   其中從WindowManager.addView開(kāi)始就是Activity創(chuàng)建Window的過(guò)程，最終在ViewRootImpl對(duì)象的performTraversals中完成View的繪制（一個(gè)Window對(duì)象對(duì)應(yīng)了一個(gè)ViewViewRootImpl對(duì)象也對(duì)應(yīng)了一個(gè)View對(duì)象，即DecorView）
   performTraversals()是繪制的入口，
   它依次調(diào)用
4. performMeasure()、performLayout()和 performDraw()三個(gè)方法，
   三個(gè)方法內(nèi)部分別調(diào)用了DecorView的measure()、layout()和draw方法。
5. 最后，傳導(dǎo)到我們每一個(gè)View的mesaure()，onMeasure()（可能多次調(diào)用）, layout()，onLayout(), draw() onDraw()函數(shù)。

為什么post就能確保是渲染之后呢？

1. Handler的由來(lái)

在dispatchAttachedToWindow(無(wú)法繼承)被回調(diào)之前，拿不到handler，就往RunQueue里存儲(chǔ)。

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

直到：

    void dispatchAttachedToWindow(AttachInfo info, int visibility) {mAttachInfo = info;...// Transfer all pending runnables.if (mRunQueue != null) {mRunQueue.executeActions(info.mHandler);mRunQueue = null;}

才把我們的消息post出去，執(zhí)行。

2. post的消息，又是如何保證在三大流程之后執(zhí)行呢？

閱讀系統(tǒng)源碼：

scheduleTraversals {postRunnable { //發(fā)送消息執(zhí)行的doTraversal{performTraversals { 2510 ~ 3333行2613 dispatchAttachedToWindow2677 2717 3706 measureHierarchy | 3082 3108 performMeasure3140 performLayout3306 performDraw}}}
}

另外，也有其他情況，會(huì)導(dǎo)致多次執(zhí)行scheduleTraversals：

        if (!cancelDraw) {xxxperformDraw();} else {if (isViewVisible) {// Try againscheduleTraversals();} else {xxxx

即變成了

scheduleTraversals {postRunnable { //發(fā)送消息執(zhí)行的performTraversals { 2510 ~ 3333行2613 dispatchAttachedToWindow   追加：post我們的任務(wù)2677 2717 3706 measureHierarchy | 3082 3108 performMeasure3140 performLayout3306 performDraw追加：scheduleTraversals  先發(fā)送屏障；又通過(guò)mChoreographer.postCallback 發(fā)送一個(gè)異步消息。}			

這里看出，三大流程，其實(shí)是跑在一個(gè)函數(shù)里面！

1. 我們知道，函數(shù)又是跑在handler里面，所以一般情況，我們的post的任務(wù)，在handler MessageQueue需要等待下一個(gè)next取出消息再執(zhí)行，自然而然在三個(gè)流程之后。
2. 即使有額外邏輯導(dǎo)致了觸發(fā)二次scheduleTraversals ，

    void scheduleTraversals() {if (!mTraversalScheduled) {mTraversalScheduled = true;mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);內(nèi)部是post(異步消息) setAsynchronous(true);notifyRendererOfFramePending();pokeDrawLockIfNeeded();}}

它會(huì)通過(guò)消息屏障和異步消息，framework通過(guò)handler這個(gè)機(jī)制，當(dāng)下次next取出msg的時(shí)候，保證取出渲染的消息優(yōu)先完成。