requestLayout ,invalidate,postInvalidate

requestLayout()
       当动态的移动一个View的位置，或者View的大小、形状发生了变化，我们可以再View中调用这个方法。
       view.requestLayout()。请求布局，如果子View调用了这个方法，其实会从View树重新进行一次测量、布局、绘制最终就会显示子View的最终情况。
       从源码注释可以看出，如果当前View在请求布局的时候，View树正在进行布局流程的话，该请求会延迟到布局流程完成后或者绘制流程完成且下一次布局发现的时候再执行。
       requestLayout()方法中，首先判断当前View树是否正在布局流程，接着为当前子View设置标记位，该标记位的作用就是标记了当前的View是需要进行重新布局的，接着调用mParent.requestLayout()方法，这个十分重要，因为这里是向父容器请求布局，即调用父容器的requestLayout方法，为父容器添加PFLAG_FORCE_LAYOUT标记位，而父容器又会调用它的父容器的requestLayout方法，即requestLayout事件层层向上传递，直到DecorView，即根View，而根View又会传递给ViewRootImpl，也即是说子View的requestLayout事件，最终会被ViewRootImpl接收并得到处理。纵观这个向上传递的流程，其实是采用了责任链模式，即不断向上传递该事件，直到找到能处理该事件的上级，在这里，只有ViewRootImpl能够处理requestLayout事件
。
       ViewRootImpl中，重写了requestLayout方法，会将其中的mLayoutRequested参数置为true，接着调用了scheduleTraversals方法，这个方法是一个异步方法，最终会调用到ViewRootImpl#performTraversals方法，这个方法是核心分别调用measure、layout、draw方法来进行View的三大工作流程。
       我们可以简单的认为mLayoutRequested为true会触发perfomMeasure(内部会调用onMeasure)和performLayout(内部会调用onLayout)。然后在performDraw内部draw的过程中发现mDirty为空，所以onDraw不会被调用，不重绘。
       这么看来requestLayout不会导致onDraw调用了？
       也不见得，我们知道requestLayout会导致perfomMeasure和performLayout，如果在layout过程中发现l,t,r,b和以前不一样，那就会触发一次invalidate。代码在View的setFrame中，这个会在layout时被调用。
所以requestLayout有可能会导致onDraw被调用，也可能不导致onDraw被调用，取决于view的l,t,r,b是否改变
PFLAG_FORCE_LAYOUT，我们再看看measure过程，measure的核心代码处必须满足3个条件之一，就会触发measure。
       if ((mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||
widthMeasureSpec != mOldWidthMeasureSpec ||
heightMeasureSpec != mOldHeightMeasureSpec) {
//…measure核心代码
}
而他自己与他的父族view都会被设置为PFLAG_FORCE_LAYOUT，所以他们都必然会被重新measure，但是其他的view就不一定了，就看这3个条件是否会满足。
       结论是requestLayout会导致部分view重新measure和layout。a的requestLayout必然会导致a,a.p,a.p.p…（父View）的重新measure，ap的requestLayout必定会导致ap.p的measure，但不一定会导致a的measure
       子View调用requestLayout方法，会标记当前View及父容器，同时逐层向上提交，直到ViewRootImpl处理该事件，ViewRootImpl会调用三大流程，从measure开始，对于每一个含有标记位的view及其子View都会进行测量、布局、绘制。

invalidate()
       该方法的调用会引起View树的重绘，常用于内部调用(比如 setVisiblity())或者需要刷新界面的时候,需要在主线程(即UI线程)中调用该方法。
       invalidate有多个重载方法，但最终都会调用invalidateInternal方法，在这个方法内部，进行了一系列的判断，判断View是否需要重绘，接着为该View设置标记位，然后把需要重绘的区域传递给父容器，即调用父容器的invalidateChild方法
       ViewGroup.invalidateChild()。先设置当前视图的标记位，接着有一个do…while…循环，该循环的作用主要是不断向上回溯父容器，求得父容器和子View需要重绘的区域的并集(dirty)。当父容器不是ViewRootImpl的时候，调用的是ViewGroup的invalidateChildInParent方法View.Group.invalidateChildInParent()。这个方法做的工作主要有：调用offset方法，把当前dirty区域的坐标转化为父容器中的坐标，接着调用union方法，把子dirty区域与父容器的区域求并集，换句话说，dirty区域变成父容器区域。最后返回当前视图的父容器，以便进行下一次循环。
       最后调用到ViewRootImpl的invalidateChildInParent方法。可以看出，该方法所做的工作与上面的差不多，都进行了offset和union对坐标的调整，然后把dirty区域的信息保存在mDirty中，最后调用了scheduleTraversals方法，触发View的工作流程，由于没有添加measure和layout的标记位，因此measure、layout流程不会执行，而是直接从draw流程开始。
       总结一下invalidate方法，当子View调用了invalidate方法后，会为该View添加一个标记位，同时不断向父容器请求刷新，父容器通过计算得出自身需要重绘的区域，直到传递到ViewRootImpl中，最终触发performTraversals方法，进行开始View树重绘流程(只绘制需要重绘的视图)。

postInvalidate()
       这个方法与invalidate方法的作用是一样的，都是使View树重绘，但两者的使用条件不同，postInvalidate是在非UI线程中调用，invalidate则是在UI线程中调用。postInvalidate()->postInvalidateDelayed()。
       postInvalidateDelayed()：只有attachInfo不为null的时候才会继续执行，即只有确保视图被添加到窗口的时候才会通知view树重绘，因为这是一个异步方法，如果在视图还未被添加到窗口就通知重绘的话会出现错误，所以这样要做一下判断。
       这里使用了Handler，发送了一个异步消息到主线程，这里发送的是MSG_INVALIDATE，即通知主线程刷新视图。
       一般来说，如果View确定自身不再适合当前区域，比如说它的LayoutParams发生了改变，需要父布局对其进行重新测量、布局、绘制这三个流程，往往使用requestLayout。而invalidate则是刷新当前View，使当前View进行重绘，不会进行测量、布局流程，因此如果View只需要重绘而不需要测量，布局的时候，使用invalidate方法往往比requestLayout方法更高效。

文末小Tip~
onMeasure和onLayout的关系。
       一般认为调用了onMeasure就会调用onLayout，onMeasure和onLayout是强相关的，measure方法在满足3条件时（上面有代码），进入主measure流程，调用onMeasure，然后设置PFLAG_LAYOUT_REQUIRED。所以执行了主measure流程就会给打上需要调用onLayout的标记，所以认为调用了onMeasure就会调用onLayou
。

参考文章
https://blog.csdn.net/litefish/article/details/52859300
https://blog.csdn.net/a553181867/article/details/51583060