Android中View.post和Handler.post的关系是什么

这篇文章主要介绍“Android中View.post和Handler.post的关系是什么”，在日常操作中，相信很多人在Android中View.post和Handler.post的关系是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Android中View.post和Handler.post的关系是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

为什么要拿这二者来比较？

首先，这二者的名字相同

其次，是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的关系是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注编程网网站，小编会继续努力为大家带来更多实用的文章！