View.post和Handler.post的關系

rEd 2021-08-15 13:37:26 阅读数:632

本文一共[544]字,预计阅读时长:1分钟~
view.post view post handler.post handler

前言

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()方法:

圖片1.png

View.post的執行流程

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

  1. 處理:這裏的處理並非直接執行Runnable,而是統一插入到主線程的MessageQueue中去執行;
  2. “未來的某個時間點”,這個未來的某個時間點指的是perfromTraversals()中將ViewRootImpl中mRunQueue中的所有Runnable插入到MessageQueue之後的某個時間點。必然在performTraversals()之後。

圖片2.png

如上圖,必須得等到整個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大概是這樣:

image.png

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

image.png

end~

版权声明:本文为[rEd]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815133652439m.html