Android中View.post和Handler.post的關系

前言

View.post和Handler.post是Android開發中經常使用到的兩個”post“方法,我們經常通過前者去獲取一些View在運行時的渲染數據,或者測量頁面的渲染時間。而後者則是Android的核心Handler的一個方法,它會向對應線程的MessageQueue中插入一條Message,在未來的某個事件點得到執行…..

為什麼要拿這二者來比較?

首先,這二者的名字相同

其次,是View.post()的調用時機和整個View的繪制和渲染有著千絲萬縷的聯系。而這一切的基礎,正是主線程的Handler.post(),理清這二者的關系,能夠加深我們對View渲染、繪制的流程的理解。

View的渲染起點

宏觀上來說,當DecorView被”attach“到Window之上後,程序能夠收到系統分配給各個Activity的同步信號時,View就會開始渲染瞭,當每個同步信號到來時,ChoreoGrapher將會派發出一個信號通知ViewRootImpl進行視圖的渲染,因此,從系統上來看,每次釋放的Vsync同步信號應該是視圖繪制的起點。

從App端來說,當ScheduleTravesals被調用時,會先向MessageQueue中插入一個消息屏障,此時會阻隔其他的同步消息的通過,允許異步消息的進入。然後mChoreoGrapher,向MessageQueue中插入一個視圖更新的信號,最終會走到doTraversals()方法中,在該方法的執行過程中,將會先取消掉同步屏障,然後緊接著執行performTraversals()方法。顯然,消息屏障的作用就是提升peformTraversals的優先級,確保視圖的優先繪制。

不難發現,真正的進行渲染的起點是perfromTraversals()方法:

View.post的執行流程

View.post在不同版本的Android系統中,有著不同的實現,在API24以前,View.post所做的是:當View.post被調用時,直接向ViewRootImpl的mRunQueue中插入一個Runnable,然後在performTraversals()過程中,統一進行處理,這樣一來,View.post()就會按照View.post()的調用順序在”未來的某個時間點“進行執行,這說明:在這一系列的Android版本中,View.post的執行順序就是本身調用View.post()的順序

處理:這裡的處理並非直接執行Runnable,而是統一插入到主線程的MessageQueue中去執行;

“未來的某個時間點”,這個未來的某個時間點指的是perfromTraversals()中將ViewRootImpl中mRunQueue中的所有Runnable插入到MessageQueue之後的某個時間點。必然在performTraversals()之後。

如上圖,必須得等到整個perfromTraversals方法體執行完成(包括)後,才有可能執行下一個Message(這裡標註為瞭Runnable),而perfromTraversals()方法體中,會順序地調用performMeasure()、performLayout()、performDraw()方法,這三個方法走完,意味著視圖已經完成瞭渲染,此時的View.post()執行,必然是能落在視圖創建之後

而API24及之後的版本中,View.post所做的事情發生瞭改變,當View.post()調用時,Runnable被插入到View各自的mRunQueue當中,也就是說,每個View都含有一個mRunQueue,當performTraversals()中,也沒有統一處理瞭,而是根據 performTraversals()->dispatchAttachedToWindows()遞歸地調用到子View時,子View將自己的mRunQueue插入到主線程的MessageQueue,這意味著:在高版本的執行過程中,View.post()的執行順序是按照視圖被迭代到的順序。

不變的是View.post()執行,必然是能落在視圖創建之後,這也是為什麼能夠調用View.post()來獲取一些屏幕上的View的數據的原因。

Handler.post()能像View.post()一樣獲取到寬、高數據嗎?

Activity為我們暴露瞭三個常用的生命周期函數:onCreate()、onStart()、onResume()。通常我們對一些事件的監聽、View的初始化設置都會在這三個生命周期函數中實現,以最後執行的onReumse()為例,我們在其中使用主線程的Handler.post()獲取一個視圖的數據,

我們可以看看結果:

    override fun onResume(){
        super.onResume()
        Handler(Looper.getMainLooper()).post{
            Log.d("getHeight",textView.height.toString())
        }
    }
  D/getHeight: 0

顯然,失敗瞭。

我們知道,一個的Activity的創建初期,DecorView並不會直接就和Activity建立聯系,建立聯系的過程在handleResumeActivity()當中,此時的DecorView被attach到瞭Activity之上。但是,我們需要明確一點:一個View如果沒有和Activity建立聯系,那麼它將收不到系統的同步信號,也就無法更新(更新也沒有意義,因為它沒有地方去顯示),我們看看handleResumeActiivty的執行方法體,可以發現,先走瞭onResume()的回調,再走瞭a.mDecor = decor這一步驟,上文我們提到,視圖更新的事件是以Message的形式,在MessageQueue中”排隊“的,如果我們在onResume()中插入一個消息去獲取渲染之後的寬高數據,那麼這時的MessageQueue大概是這樣:

當前正在執行的是黃色的Message,這是一個從ActivityThread.java中H類發出的調度方法,它將會調用到handleResumeActivity中的一系列方法,最終走到onResume這,我們使用Handler.post(),我們會發現消息被插在瞭黃色的Message之後,但是此時的a.mDecor = decor還沒有執行,更不可能已經發生繪制瞭,這也就意味著壓根沒渲染,沒視圖,自然也沒數據,完整的流程如下:

到此這篇關於Android中View.post和Handler.post的關系的文章就介紹到這瞭,更多相關View.post與Handler.post內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: