！！！注意，为了方便查看，文章中代码都做了精简，不是完整代码。
事件的分发顺序
Activity —> ViewGroup —> View
onTouch优先于onClick执行
如果onTouch 返回true,则在dispatchTouchEvent方法分发事件时直接return true,不会再执行onTouchEvent(event)方法。
onTouch 在dispatchTouchEvent中执行，onClick在onTouchEvent(event)中执行。
onTouch调用位置
onClick调用位置
TextView ImageView 默认为不可点击状态,不消耗事件，Button默认为可点击状态，消耗事件。
备注：控件不可点击时，在执行到onTouchEvent方法时，无法进入手势的判断逻辑，所以会return false，反之，View可点击必然return true;
分析源码得知，如果一个View是可点击的，则onTouchEvent会 return true, 由此dispatchTouchEvent也会返回true，即消耗了事件。
clickable的View 默认消耗事件
可重写ViewGroup的onInterceptTouchEvent或者调用requestDisallowInterceptTouchEvent 对事件进行拦截。
但在ViewGroup 的dispatchTouchEvent中接收到ACTION_DOWN 事件时，会重置所有状态，所以注意requestDisallowInterceptTouchEvent的调用时机。
举个栗子，可以在子View的onTouchEvent中调用（此种情景一般是在一个可横向滑动的组件中，嵌套了另一个横向滑动的组件，比如ViewPager里面 存在一个可横向滑动的view，可重写此View,使其在横向滚动的时候，不触发ViewPager的翻页效果）
挖坑~!~!~!~
1>在重写onInterceptTouchEvent 的时候要注意 return true或 false 的时机。
2>可以参考下ScrollView onInterceptTouchEvent 写法，代码如下（精简版）
可以看到 onInterceptTouchEvent返回值 是由mIsBeingDragged 决定的，可以改变mIsBeingDragged值的几个方地方 已经用箭头标志出来，action_down事件时一般情况下会返回false（例外：Scrollview 处于滚动时会返回true）,所以down事件一般不会对事件进行拦截。
那拦截事件的逻辑就到了action_move中，可以简单理解为手指移动一定距离之后，ScrollView就会拦截事件，这样做的好处就是，在未达到滑动的距离的时候，事件可以传递到子View（如果没有这个操作，我们也就无法在子View中调用requestDisallowInterceptTouchEvent 来请求父类 放开的属于自己的事件了）。
当action_down事件到达view时，假如view的dispatchTouchEvent返回false ，则后续的action_up、action_move等不会再到达View.
分析：
1、ACTION_DOWN事件到达ViewGroup之后 通过dispatchTouchEvent分发至View.
2、如View的dispatchTouchEvent返回true则表示View消耗了事件，此时ViewGroup 会记录下此View（源码中使用mFirstTouchTarget记录，可以看下 下面的源码 ）.
3、当后续事件到达时，会先判断是否记录了消耗事件的View,如记录了则继续调用View的dispatchTouchEvent进行事件的分发。
4、反之View的dispatchTouchEvent 返回false ,表示View不消耗事件，ViewGroup 不对此View 进行记录，后续事件到达时，判断没有记录任何View,会执行super.dispatchTouchEvent(event)（ViewGroup 继承了view，此处实际执行的是父view的dispatchTouchEvent).
View中 有dispatchTouchEvent，onTouchEvent。
ViewGroup 有dispatchTouchEvent，onTouchEvent 、onInterceptTouchEvent 。
事件的分发传递机制 核心就是这三两个方法，个人理解：
1、对于ViewGroup中的dispatchTouchEvent主要是用来分发事件的，找到消耗事件的View，将事件传递给它（其实就是调用View的dispatchTouchEvent），然后根据 返回值，来判断此次事件已结束（return true）还是调用自己父View中的dispatchTouchEvent（return false）由自己来消耗事件。
2、对于View，dispatchTouchEvent、onTouchEvent 简单说 就是为了 消耗事件（处理事件），但消耗与否 ，由自身的一些属性决定
1> 在dispatchTouchEvent中如果OnTouchListener 不为空，View enable同时 OnTouchListener.onTouch() 为true,则 dispatchTouchEvent return true 消耗了此次事件。
多说一句，此时，dispatchTouchEvent后续代码不会执行，导致onTouchEvent不会被执行，onClick是在onTouchEvent中被调用，所以此种情况下，onClick回调无效。
2> 如果不符合情况1，此时，会执行dispatchTouchEvent后续代码，即会调用onTouchEvent，在前面也介绍过，View可点击时 ，会消耗事件（如Button）,不可点击时，不消耗事件（如TextView,ImageView）
补充：
Activity的dispatchTouchEvent
代码很少，很好理解，在activity的dispatchTouchEvent的中首先调用了PhoneWindow的superDispatchTouchEvent ，然后巴拉巴拉巴拉~！~！~ 还是看下面的源码吧，找到最后，发现是调用了ViewGroup的dispatchTouchEvent，这样从源码上也可以看出，分发的流程就是Activity->ViewGroup->View了。
getWindow().superDispatchTouchEvent(ev) 如为false,则 没有ViewGroup 或者view消耗事件，最终会调用Activity的onTouchEvent，由Activity自身处理事件。
Activity
PhoneWindow
DecorView
ViewGroup
网友评论