Android進(jìn)階之源碼中分析View.post()為何獲取控件寬高
本文轉(zhuǎn)載自微信公眾號「Android開發(fā)編程」,作者Android開發(fā)編程。轉(zhuǎn)載本文請聯(lián)系A(chǔ)ndroid開發(fā)編程公眾號。
前言
為什么 View.post() 的操作是可以對 UI 進(jìn)行操作的呢,即使是在子線程中調(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的等待隊(duì)列
- getRunQueue().post(action);
- return true;
- }
- AttachInfo 是 View 的靜態(tài)內(nèi)部類,每個 View 都會持有一個 AttachInfo,它默認(rèn)為 null;
- 如果mAttachInfo為空,就執(zhí)行:把a(bǔ)ction加入當(dāng)前view的等待隊(duì)列;
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方法,這有點(diǎn)類似于Handler發(fā)送消息
- postDelayed(action, 0);
- }
- // 實(shí)際調(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) 傳進(jìn)去的 Runnable 操作,在傳到 HandlerActionQueue 里會先經(jīng)過 HandlerAction 包裝一下,然后再緩存起來;
- 在 執(zhí)行 View.post(Runnable) 時,因?yàn)檫@時候 View 還沒有 attachedToWindow,所以這些 Runnable 操作其實(shí)并沒有被執(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()
- // 實(shí)際類型是 HandlerActionQueue,內(nèi)部保存了當(dāng)前View.post的任務(wù)
- if (mRunQueue != null) {
- // 執(zhí)行使用View.post的任務(wù)
- // 注意這里是post到渲染線程的Handler中
- mRunQueue.executeActions(info.mHandler);
- // 保存延遲任務(wù)的隊(duì)列被置為null,因?yàn)榇藭r所有的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實(shí)際大小
- listener.onViewAttachedToWindow(this);
- }
- }
- }
5、executeActions
mRunQueue 就是保存了 View.post() 任務(wù)的 HandlerActionQueue;此時調(diào)用它的 executeActions 方法如下:
- public void executeActions(Handler handler) {
- synchronized (this) {
- // 任務(wù)隊(duì)列
- 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 中排隊(duì)執(zhí)行;
- 將保存任務(wù)的 mActions 置為 null,因?yàn)楹罄m(xù) View.post() 直接添加到 AttachInfo 內(nèi)部的 Handler;
6、performTraversals
- dispatchAttachedToWindow() 的調(diào)用時機(jī)是在 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 其實(shí)都是發(fā)送到主線程的 MessageQueue 里排隊(duì),等待執(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)先考慮使用該機(jī)制;