Android进阶之源码中分析View.post()为何获取控件宽高

开发 前端
为什么 View.post() 的操作是可以对 UI 进行操作的呢,即使是在子线程中调用 View.post()? 今天我们就来分析分析

[[425705]]

本文转载自微信公众号「Android开发编程」,作者Android开发编程。转载本文请联系Android开发编程公众号。

前言

为什么 View.post() 的操作是可以对 UI 进行操作的呢,即使是在子线程中调用 View.post()?

今天我们就来分析分析

一、View.post源码深入分析

1、View.post()

View 的 post 方法如下:

  1. public boolean post(Runnable action) { 
  2.     // 1、首先判断AttachInfo是否为null 
  3.     final AttachInfo attachInfo = mAttachInfo; 
  4.     if (attachInfo != null) { 
  5.         // 1.1如果不为null,直接调用其内部Handler的post 
  6.         return attachInfo.mHandler.post(action); 
  7.     } 
  8.     // 2、否则加入当前View的等待队列 
  9.     getRunQueue().post(action); 
  10.     return true
  • AttachInfo 是 View 的静态内部类,每个 View 都会持有一个 AttachInfo,它默认为 null;
  • 如果mAttachInfo为空,就执行:把action加入当前view的等待队列;

2、getRunQueue().post()

看下 getRunQueue().post():

  1. private HandlerActionQueue getRunQueue() { 
  2.     if (mRunQueue == null) { 
  3.         mRunQueue = new HandlerActionQueue(); 
  4.     } 
  5.     return mRunQueue; 
  • getRunQueue() 返回的是 HandlerActionQueue;
  • 调用了 HandlerActionQueue 的 post 方法:
  1. public void post(Runnable action) { 
  2.     // 调用到postDelayed方法,这有点类似于Handler发送消息 
  3.     postDelayed(action, 0); 
  1. // 实际调用postDelayed 
  2. public void postDelayed(Runnable action, long delayMillis) { 
  3.     // HandlerAction表示要执行的任务 
  4.     final HandlerAction handlerAction = new HandlerAction(action, delayMillis); 
  5.     synchronized (this) { 
  6.         if (mActions == null) { 
  7.             // 创建一个保存HandlerAction的数组 
  8.             mActions = new HandlerAction[4]; 
  9.         } 
  10.         // 表示要执行的任务HandlerAction 保存在 mActions 数组中 
  11.         mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction); 
  12.         // mActions数组下标位置累加1 
  13.         mCount++; 
  14.     } 

3、HandlerAction

HandlerAction 表示一个待执行的任务,内部持有要执行的 Runnable 和延迟时间;=

  1. private static class HandlerAction { 
  2.     // post的任务 
  3.     final Runnable action
  4.     // 延迟时间 
  5.     final long delay; 
  6.     public HandlerAction(Runnable action, long delay) { 
  7.         this.action = action
  8.         this.delay = delay; 
  9.     } 
  10.     // 比较是否是同一个任务 
  11.     // 用于匹配某个 Runnable 和对应的HandlerAction 
  12.     public boolean matches(Runnable otherAction) { 
  13.         return otherAction == null && action == null 
  14.                 || action != null && action.equals(otherAction); 
  15.     } 

postDelayed() 创建一个默认长度为 4 的 HandlerAction 数组,用于保存 post() 添加的任务;

梳理总结:

  • 我们调用 View.post(Runnable) 传进去的 Runnable 操作,在传到 HandlerActionQueue 里会先经过 HandlerAction 包装一下,然后再缓存起来;
  • 在 执行 View.post(Runnable) 时,因为这时候 View 还没有 attachedToWindow,所以这些 Runnable 操作其实并没有被执行,而是先通过 HandlerActionQueue 缓存起来;

4、AttachInfo

看下 AttachInfo 的创建过程,先看下它的构造方法:

  1. AttachInfo(IWindowSession session, IWindow window, Display display, 
  2.                ViewRootImpl viewRootImpl, Handler handler, Callbacks effectPlayer, 
  3.                Context context) { 
  4.         mSession = session; 
  5.         mWindow = window; 
  6.         mWindowToken = window.asBinder(); 
  7.         mDisplay = display; 
  8.         // 持有当前ViewRootImpl 
  9.         mViewRootImpl = viewRootImpl; 
  10.         // 当前渲染线程Handler 
  11.         mHandler = handler; 
  12.         mRootCallbacks = effectPlayer; 
  13.         mTreeObserver = new ViewTreeObserver(context); 
  14.     } 

AttachInfo 中持有当前线程的 Handler;

4.1、mAttachInfo 赋值:

  1. void dispatchAttachedToWindow(AttachInfo info, int visibility) { 
  2.     // 给当前View赋值AttachInfo,此时所有的View共用同一个AttachInfo(同一个ViewRootImpl内) 
  3.     mAttachInfo = info; 
  4.     if (mOverlay != null) { 
  5.         // 任何一个View都有一个ViewOverlay 
  6.         // ViewGroup的是ViewGroupOverlay 
  7.         // 它区别于直接在类似RelativeLaout/FrameLayout添加View,通过ViewOverlay添加的元素没有任何事件 
  8.         // 此时主要分发给这些View浮层 
  9.         mOverlay.getOverlayView().dispatchAttachedToWindow(info, visibility); 
  10.     } 
  11.     mWindowAttachCount++; 
  12.     if ((mPrivateFlags & PFLAG_SCROLL_CONTAINER) != 0) { 
  13.         mAttachInfo.mScrollContainers.add(this); 
  14.         mPrivateFlags |= PFLAG_SCROLL_CONTAINER_ADDED; 
  15.     } 
  16.     //  mRunQueue,就是在前面的 getRunQueue().post() 
  17.     // 实际类型是 HandlerActionQueue,内部保存了当前View.post的任务 
  18.     if (mRunQueue != null) { 
  19.         // 执行使用View.post的任务 
  20.         // 注意这里是post到渲染线程的Handler中 
  21.         mRunQueue.executeActions(info.mHandler); 
  22.         // 保存延迟任务的队列被置为null,因为此时所有的View共用AttachInfo 
  23.         mRunQueue = null
  24.     } 
  25.     performCollectViewAttributes(mAttachInfo, visibility); 
  26.     // 回调View的onAttachedToWindow方法 
  27.     // 在Activity的onResume方法中调用,但是在View绘制流程之前 
  28.     onAttachedToWindow(); 
  29.     ListenerInfo li = mListenerInfo; 
  30.     final CopyOnWriteArrayList<OnAttachStateChangeListener> listeners = 
  31.             li != null ? li.mOnAttachStateChangeListeners : null
  32.     if (listeners != null && listeners.size() > 0) { 
  33.         for (OnAttachStateChangeListener listener : listeners) { 
  34.             // 通知所有监听View已经onAttachToWindow的客户端,即view.addOnAttachStateChangeListener(); 
  35.             // 但此时View还没有开始绘制,不能正确获取测量大小或View实际大小 
  36.             listener.onViewAttachedToWindow(this); 
  37.         } 
  38.     } 

5、executeActions

mRunQueue 就是保存了 View.post() 任务的 HandlerActionQueue;此时调用它的 executeActions 方法如下:

  1. public void executeActions(Handler handler) { 
  2.     synchronized (this) { 
  3.         // 任务队列 
  4.         final HandlerAction[] actions = mActions; 
  5.         // 遍历所有任务 
  6.         for (int i = 0, count = mCount; i < count; i++) { 
  7.             final HandlerAction handlerAction = actions[i]; 
  8.             //发送到Handler中,等待执行 
  9.             handler.postDelayed(handlerAction.action, handlerAction.delay); 
  10.         } 
  11.         //此时不在需要,后续的post,将被添加到AttachInfo中 
  12.         mActions = null
  13.         mCount = 0; 
  14.     } 
  • 遍历所有已保存的任务,发送到 Handler 中排队执行;
  • 将保存任务的 mActions 置为 null,因为后续 View.post() 直接添加到 AttachInfo 内部的 Handler;

6、performTraversals

  • dispatchAttachedToWindow() 的调用时机是在 View 绘制流程的开始阶段;
  • 在 ViewRootImpl 的 performTraversals 方法,在该方法将会依次完成 View 绘制流程的三大阶段:测量、布局和绘制;
  1. // View 绘制流程开始在 ViewRootImpl 
  2. private void performTraversals() { 
  3.     // mView是DecorView 
  4.     final View host = mView; 
  5.     if (mFirst) { 
  6.         ..... 
  7.         // host为DecorView 
  8.         // 调用DecorVIew 的 dispatchAttachedToWindow,并且把 mAttachInfo 给子view 
  9.         host.dispatchAttachedToWindow(mAttachInfo, 0); 
  10.         mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(true); 
  11.         dispatchApplyInsets(host); 
  12.         ..... 
  13.     }  
  14.    mFirst=false 
  15.    getRunQueue().executeActions(mAttachInfo.mHandler); 
  16.    // View 绘制流程的测量阶段 
  17.    performMeasure(); 
  18.    // View 绘制流程的布局阶段 
  19.    performLayout(); 
  20.    // View 绘制流程的绘制阶段 
  21.    performDraw(); 

7、dispatchAttachedToWindow

  • 每个 Activity 都有一个关联的 Window 对象,用来描述应用程序窗口,每个窗口内部又包含一个 DecorView 对象,DecorView 对象用来描述窗口的视图 — xml 布局;
  • 通过 setContentView() 设置的 View 布局最终添加到 DecorView 的 content 容器中;
  • DecorView 的 dispatchAttachedToWindow 方法的执行过程,DecorView 并没有重写该方法,而是在其父类 ViewGroup 中:
  1. void dispatchAttachedToWindow(AttachInfo info, int visibility) { 
  2.     mGroupFlags |= FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW; 
  3.     super.dispatchAttachedToWindow(info, visibility); 
  4.     mGroupFlags &= ~FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW; 
  5.     // 子View的数量 
  6.     final int count = mChildrenCount; 
  7.     final View[] children = mChildren; 
  8.     // 遍历所有子View 
  9.     for (int i = 0; i < count; i++) { 
  10.         final View child = children[i]; 
  11.         // 遍历调用所有子View的dispatchAttachedToWindow 
  12.         // 为每个子View关联AttachInfo 
  13.         child.dispatchAttachedToWindow(info, 
  14.                 combineVisibility(visibility, child.getVisibility())); 
  15.     } 
  • for 循环遍历当前 ViewGroup 的所有 childView,为其关联 AttachInfo;
  • 子 View 的 dispatchAttachedToWindow,首先为当前 View 关联 AttachInfo,然后将之前 View.post() 保存的任务添加到 AttachInfo 内部的 Handler;
  • performTraversals() 会先执行 dispatchAttachedToWindow(),这时候所有子 View 通过 View.post(Runnable) 缓存起来的 Runnable 操作就都会通过 mAttachInfo.mHandler 的 post() 方法将这些 Runnable 封装到 Message 里发送到 MessageQueue 里;
  • mHandler 我们上面也分析过了,绑定的是主线程的 Looper,所以这些 Runnable 其实都是发送到主线程的 MessageQueue 里排队,等待执行。然后 performTraversals() 继续往下工作,相继执行 performMeasure(),performLayout() 等操作;
  • 等全部执行完后,表示这个 Message 已经处理完毕,所以 Looper 才会去取下一个 Message,这时候,才有可能轮到这些 Runnable 执行;
  • 所以,这些 Runnable 操作也就肯定会在 performMeasure() 操作之后才执行,宽高也就可以获取到了;

总结

View.post(Runnable) 内部会自动分两种情况处理,当 View 还没 attachedToWindow 时,会先将这些 Runnable 操作缓存下来;否则就直接通过 mAttachInfo.mHandler 将这些 Runnable 操作 post 到主线程的 MessageQueue 中等待执行;

View.post() 任务能够保证在所有 View 绘制流程结束之后被调用,故如果需要依赖 View 绘制任务,此时可以优先考虑使用该机制;

 

责任编辑:武晓燕 来源: Android开发编程
相关推荐

2021-05-17 09:50:06

Kubebuilde源码CURD

2024-06-19 08:32:13

2017-04-28 09:58:21

AndroidLinearLayou宽高

2017-09-05 15:27:33

View Api23Api24

2016-09-22 15:50:38

JavascriptRedux源码解析

2021-08-17 13:41:11

AndroidView事件

2019-12-23 09:13:11

Python数据语言

2021-12-06 14:52:08

动画Android补间动画

2016-03-14 09:43:47

androidview总结

2021-09-30 07:36:51

AndroidViewDraw

2021-09-05 07:35:58

lifecycleAndroid组件原理

2011-03-23 10:30:01

LAMPApache源码

2021-10-03 15:08:32

Android

2021-09-02 07:00:01

Glide流程Android

2021-08-28 07:48:04

AndroidActivityRecActivitySta

2022-04-06 14:55:45

Harmony同步机制鸿蒙

2021-09-09 06:55:43

AndroidViewDragHel原理

2021-09-07 06:40:25

AndroidLiveData原理

2010-02-06 13:28:31

Android源码

2015-02-11 17:49:35

Android源码自定义控件
点赞
收藏

51CTO技术栈公众号