Down、up事件的分发过程

目录
1.事件分发介绍
2.Down、up事件的分发过程
3.onTouchListener、onClickListener调用时机
4.事件拦截应用
5.NestedScrollingParent
6.Behavior的使用
7.NestedScrollingChild接口来源
Android里面的动作都是由Down/Up/Move事件组成的，下面就这三个动作分析下在函数内的传递。但是这些动作是怎么传入activity中呢？

传递箭头
每种颜色代表一种事件，其中Cancel事件时函数内部自己产生的事件，在高版本上才有的。箭头左右顺序代表时间先后顺序。下面分情况进行介绍
1、当onInterceptTouchEvent都不拦截事件时
此时Activity、viewGroup1、ViewGroup2的onInterceptTouchEvent都不拦截事件，down事件在ViewGroup2的onTouchEvent函数中进行消费。

（1）分析Down事件传递过程
down传递时主要会为mFirstTouchEvent赋值，并做清空操作：

流程如上所示，down事件传递完毕后Activity、ViewGroup1、ViewGroup2的mFirstTouchEvent都会被赋值。
由于ViewGroup2消耗了dowm事件，故在ViewGroup1中mFirstTouchEvent指向ViewGroup2，ViewGroup2中mFirstTouchEvent为null。
（2）Move事件的传递过程
down事件传递结束后，如果有滑动则会调用move事件的分发流程
下面流程图显示代码调用过程：

最终调用到ViewGroup2的onTouchEvent事件，绕过View的onTouchEvent事件。
下面是log

总结：在没有OninterceptTouchEvent()情况下，哪个view消耗了Down事件，其余事件也交给其处理。
2.onInterceptTouchEvent进行拦截
（1）onInterceptTouchEvent在消耗down事件的上层view拦截
ViewGroup1的onInterceptTouchEvent函数只拦截Move事件，不拦截Down事件。

下面看下log日志传递过程。

由上可以看到Move事件成功的被ViewGroup1的onTouchEvent消耗掉了。
但onInterceptTouchEvent拦截后是怎么起作用呢，此时ViewGroup1的mFirstTouchEvent已经指向ViewGroup2了呀？cancel事件又是如何产生的呢？
上面看出，move事件传递到ViewGroup1拦截后会产生cancel事件，cancel事件会继续传递到ViewGroup2的onTouchEvent（）函数，此后会将ViewGroup1的mFirstTouchEvent置空，然后下次move事件就会被ViewGroup2的onTouchEvent捕获。下面是Cancel事件的触发过程。

简单看下cancel事件触发的过程，代码参见sdk27源码。
由此可知，在ViewGroup1产生cancel事件清空ViewGroup1中的mFirstTouchEvent的值，move事件再次传递到ViewGroup1时，

MotionEvent != ACTION_DOWN && mFirstTouchTarget == null 因此拦截事件给onTouchEvent。
因此，下面这句经常听到的结论是有条件的。
image.png
（2）onInterceptTouchEvent在消耗down事件的下层view拦截


这时时拦截不到的，为什么呢？


此时actionMasked ！= down 且 mFirstTouchEvent == null，因此 intercepted，便调用ViewGroup1的onTouchEvent函数。因此onTouchevent在down消耗之后的ViewGroup调用是不能拦截Move事件的。