Android進階之源碼中分析View.post()為何獲取控件寬高
本文轉(zhuǎn)載自微信公眾號「Android開發(fā)編程」,作者Android開發(fā)編程。轉(zhuǎn)載本文請聯(lián)系A(chǔ)ndroid開發(fā)編程公眾號。
前言
為什么 View.post() 的操作是可以對 UI 進行操作的呢,即使是在子線程中調(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的等待隊列
 - getRunQueue().post(action);
 - return true;
 - }
 
- AttachInfo 是 View 的靜態(tài)內(nèi)部類,每個 View 都會持有一個 AttachInfo,它默認(rèn)為 null;
 - 如果mAttachInfo為空,就執(zhí)行:把action加入當(dāng)前view的等待隊列;
 
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方法,這有點類似于Handler發(fā)送消息
 - postDelayed(action, 0);
 - }
 
- // 實際調(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)建一個保存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 表示一個待執(zhí)行的任務(wù),內(nèi)部持有要執(zhí)行的 Runnable 和延遲時間;=
- private static class HandlerAction {
 - // post的任務(wù)
 - final Runnable action;
 - // 延遲時間
 - final long delay;
 - public HandlerAction(Runnable action, long delay) {
 - this.action = action;
 - this.delay = delay;
 - }
 - // 比較是否是同一個任務(wù)
 - // 用于匹配某個 Runnable 和對應(yīng)的HandlerAction
 - public boolean matches(Runnable otherAction) {
 - return otherAction == null && action == null
 - || action != null && action.equals(otherAction);
 - }
 - }
 
postDelayed() 創(chuàng)建一個默認(rèn)長度為 4 的 HandlerAction 數(shù)組,用于保存 post() 添加的任務(wù);
梳理總結(jié):
- 我們調(diào)用 View.post(Runnable) 傳進去的 Runnable 操作,在傳到 HandlerActionQueue 里會先經(jīng)過 HandlerAction 包裝一下,然后再緩存起來;
 - 在 執(zhí)行 View.post(Runnable) 時,因為這時候 View 還沒有 attachedToWindow,所以這些 Runnable 操作其實并沒有被執(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,此時所有的View共用同一個AttachInfo(同一個ViewRootImpl內(nèi))
 - mAttachInfo = info;
 - if (mOverlay != null) {
 - // 任何一個View都有一個ViewOverlay
 - // ViewGroup的是ViewGroupOverlay
 - // 它區(qū)別于直接在類似RelativeLaout/FrameLayout添加View,通過ViewOverlay添加的元素沒有任何事件
 - // 此時主要分發(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()
 - // 實際類型是 HandlerActionQueue,內(nèi)部保存了當(dāng)前View.post的任務(wù)
 - if (mRunQueue != null) {
 - // 執(zhí)行使用View.post的任務(wù)
 - // 注意這里是post到渲染線程的Handler中
 - mRunQueue.executeActions(info.mHandler);
 - // 保存延遲任務(wù)的隊列被置為null,因為此時所有的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();
 - // 但此時View還沒有開始繪制,不能正確獲取測量大小或View實際大小
 - listener.onViewAttachedToWindow(this);
 - }
 - }
 - }
 
5、executeActions
mRunQueue 就是保存了 View.post() 任務(wù)的 HandlerActionQueue;此時調(diào)用它的 executeActions 方法如下:
- public void executeActions(Handler handler) {
 - synchronized (this) {
 - // 任務(wù)隊列
 - 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);
 - }
 - //此時不在需要,后續(xù)的post,將被添加到AttachInfo中
 - mActions = null;
 - mCount = 0;
 - }
 - }
 
- 遍歷所有已保存的任務(wù),發(fā)送到 Handler 中排隊執(zhí)行;
 - 將保存任務(wù)的 mActions 置為 null,因為后續(xù) View.post() 直接添加到 AttachInfo 內(nèi)部的 Handler;
 
6、performTraversals
- dispatchAttachedToWindow() 的調(diào)用時機是在 View 繪制流程的開始階段;
 - 在 ViewRootImpl 的 performTraversals 方法,在該方法將會依次完成 View 繪制流程的三大階段:測量、布局和繪制;
 
- // 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 繪制流程的測量階段
 - performMeasure();
 - // View 繪制流程的布局階段
 - performLayout();
 - // View 繪制流程的繪制階段
 - performDraw();
 - }
 
7、dispatchAttachedToWindow
- 每個 Activity 都有一個關(guān)聯(lián)的 Window 對象,用來描述應(yīng)用程序窗口,每個窗口內(nèi)部又包含一個 DecorView 對象,DecorView 對象用來描述窗口的視圖 — 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
 - // 為每個子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() 會先執(zhí)行 dispatchAttachedToWindow(),這時候所有子 View 通過 View.post(Runnable) 緩存起來的 Runnable 操作就都會通過 mAttachInfo.mHandler 的 post() 方法將這些 Runnable 封裝到 Message 里發(fā)送到 MessageQueue 里;
 - mHandler 我們上面也分析過了,綁定的是主線程的 Looper,所以這些 Runnable 其實都是發(fā)送到主線程的 MessageQueue 里排隊,等待執(zhí)行。然后 performTraversals() 繼續(xù)往下工作,相繼執(zhí)行 performMeasure(),performLayout() 等操作;
 - 等全部執(zhí)行完后,表示這個 Message 已經(jīng)處理完畢,所以 Looper 才會去取下一個 Message,這時候,才有可能輪到這些 Runnable 執(zhí)行;
 - 所以,這些 Runnable 操作也就肯定會在 performMeasure() 操作之后才執(zhí)行,寬高也就可以獲取到了;
 
總結(jié)
View.post(Runnable) 內(nèi)部會自動分兩種情況處理,當(dāng) View 還沒 attachedToWindow 時,會先將這些 Runnable 操作緩存下來;否則就直接通過 mAttachInfo.mHandler 將這些 Runnable 操作 post 到主線程的 MessageQueue 中等待執(zhí)行;
View.post() 任務(wù)能夠保證在所有 View 繪制流程結(jié)束之后被調(diào)用,故如果需要依賴 View 繪制任務(wù),此時可以優(yōu)先考慮使用該機制;
















 
 
 





 
 
 
 