和其他平台类似，Android 中 View 的布局是一个树形结构，各个 ViewGroup 和 View 是按树形结构嵌套布局的，从而会出现用户触摸的位置坐标可能会落在多个 View 的范围内，这样就不知道哪个 View 来响应这个事件，为了解决这一问题，就出现了事件分发机制。
2 事件分发的关键方法Android 中事件分发是从 Activity 开始的，可以看看各组件中事件分发的关键方法
组件
dispatchTouchEvent
onInterceptTouchEvent
onTouchEvent
Activity
√
×
√
ViewGroup
√
√
√
View
√
×
√
Activity：没有 onInterceptTouchEvent 方法，因为如果 Activity 拦截事件，将导致整个页面都没有响应，而 Activity 是系统应用和用户交互的媒介，不能响应事件显然不是系统想要的结果。所以 Activity 不需要拦截事件。
ViewGroup：三个方法都有，Android 中 ViewGroup 是一个布局容器，可以嵌套多个 ViewGroup 和 View，事件传递和拦截都由 ViewGroup 完成。
View：事件传递的最末端，要么消费事件，要么不消费把事件传递给父容器，所以也不需要拦截事件。
3 事件分发流程分析3.1 事件分发流程概览Activity 并不是一个 View，那么 Activity 是如何将事件分发到页面的 ViewGroup 和 View 的呢。我们先看看源码
可以看到，ViewGroup 中的事件分发逻辑还是比较复杂，但抓住关键点后则很容易能看清它的本来面貌
（1）分发的事件包括 DOWN、MOVE、UP、CANCEL 几种，用户一个完整的动作就是由这几个事件组合而成的
（2）只有 DOWN 事件中会寻找消费事件的目标 View，其他事件不会再寻找
（3）DOWN 事件寻找到目标 View 后，后续其他事件都会直接分发至目标 View
（4）事件可以被拦截，拦截后原目标 View 会收到 CANCEL 事件，后续将不会再收到任何事件（这也是这套机制不支持丰富的嵌套滑动的原因）
3.3 事件分发情景分析3.3.1 分发过程没有任何 View 拦截和消费
（1）事件返回时，为了简化理解。dispatchTouchEvent 直接指向了父 View 的 onTouchEvent ，实际上它仅仅是返回给父 View 的 dispatchTouchEvent 一个 false 值（影响了 mFirstTouchTarget 的值），父 View 根据返回值来调用自身的onTouchEvent 方法
（2）ViewGroup 是根据 onInterceptTouchEvent 的返回值（影响了 mFirstTouchTarget 的值）确定是调用子 View 的 dispatchTouchEvent 还是自身的 onTouchEvent 方法
（3）如果所有 View 都没有消费 DOWN 事件，后续 MOVE 和 UP 不会再往下传递，会直接传递给 Activity 的 onTouchEvent 方法
3.3.2 最底层View消费事件，且上层View没有拦截事件
（1）若没有 ViewGroup 对事件进行拦截，而最底层 View 消费了此事件，也就是接收到 DOWN 事件时 View 的 onTouchEvent 返回 true，事件将不会再向上传递给各个 ViewGroup 的 onTouchEvent 方法，而是直接返回，后续的 MOVE 和 UP 事件也将会直接交给 View 进行处理
3.3.3 最底层View没有消费事件，ViewGroup2消费了事件，且上层View没有拦截事件
（1）如果 View 没有消费事件，在层层调用父布局的 onTouchEvent 方法时，有 View 消费此事件，如 ViewGroup2 消费此事件，后续 MOVE 和 UP 事件将会传递给 ViewGroup2 的 onTouchEvent 方法，而且不会再调用 ViewGroup2 的 onInterceptTouchEvent 方法
（2）源码 if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) {} 这个代码中主要调用 onInterceptTouchEvent() 方法和处理是否拦截
第一次是 DOWN 事件会进行判断，所以会调用 onInterceptTouchEvent 拦截方法
第二次非 DOWN 事件，不会再调用 onInterceptTouchEvent 方法。原因如下：
◦如果 DOWN 事件的时候进行过拦截，也就是 onInterceptTouchEvent() 方法返回 true，则 mFirstTouchTarget 必定为 null，不会调用 onInterceptTouchEvent 方法。因为后面不会对这个值赋值，会往下走逻辑，直接调用到此 View 或 ViewGroup 的 onTouchEvent() 方法
◦如果 DOWN 事件没有拦截，但子 View 的 onTouchEvent 都返回 false，只有当前 ViewGroup 的 onTouchEvent 返回 true，mFirstTouchTarget 也同样为 null，也不会调用 onInterceptTouchEvent 方法。因为 mFirstTouchTarget 本质是找能接收事件的子 View，所有子 View 都不接收事件，mFirstTouchTarget 就必然为 null
3.3.4 ViewGroup2拦截了并消费了DOWN事件，其他View没有拦截事件
（1）ViewGroup2 拦截 DOWN 事件后，View 不会接收到任何事件。ViewGroup2 消费事件后，后续 MOVE 和 UP 事件会交给 ViewGroup2 的 onTouchEvent 方法进行处理，且不会再调用 ViewGroup2 的onInterceptTouchEvent 方法
3.3.5 View消费了DOWN事件，ViewGroup2拦截且消费了MOVE事件，其他View没有拦截事件
（1）View 中 DOWN 事件正常传递
（2）当 ViewGroup2 拦截 MOVE 事件后，当前 mFirstTouchTarget 不为空，首先 View 会收到转换后的 CANCEL 事件，mFirstTouchTarget 会置为空，下次 MOVE 事件由于 mFirstTouchTarget 为空，会调用到自己的 onTouchEvent 方法
3.3.6 View消费 DOWN 事件，ViewGroup2拦截且消费了MOVE事件，一定条件后，ViewGroup1再次拦截和消费MOVE事件，其他View没有拦截事件
（1）整个分发过程中没有任何拦截和消费，DOWN 事件会层层往下分发，并层层往上返回 false，MOVE 和 UP 事件则会交给 Activity 的 onTouchEvent 方法进行处理，不再往下分发
（2）分发过程中没有任何拦截但有消费，DOWN 事件会层层往下分发，并层层往上返回false，直到有消费返回 true，MOVE 和 UP 事件则会层层往下分发，最后直接交给消费事件的 View 进行处理，然后层层返回 true
（3）分发过程中有拦截且拦截后消费，DOWN 事件会层层往下分发，直到有拦截后直接交给消费的 View 进行处理，MOVE 和 UP 事件则会层层往下分发，最后直接交给消费事件的 View 进行处理，然后层层返回true
（4）分发过程中不拦截 DOWN 事件，但拦截 MOVE 事件且拦截后消费，第一次拦截，之前收到 DOWN 事件的子 View 会收到 CANCEL 事件，并层层返回；后续 MOVE 和 UP 会层层往下分发，最后直接交给消费事件的 View 进行处理
（5）分发过程中不拦截 DOWN 事件，但拦截 MOVE 事件且拦截后不消费，第一次拦截，之前收到 DOWN 事件的子 View 会收到 CANCEL 事件，并层层返回；后续 MOVE 和 UP 会层层往下分发，最后交给拦截的 View 进行处理，此时由于拦截的 View 没有消费，会层层往上返回 false，最后会交给 Activity 的 onTouchEvent 方法进行处理
以上，是个人的一些分析和经验，欢迎有兴趣的小伙伴一起学习和探讨！
