Android View事件分发机制

MotionEvent封装触摸动作和坐标信息，是事件传递的载体。

主要动作类型：

• ACTION_DOWN- 手指按下
• ACTION_MOVE- 手指移动
• ACTION_UP- 手指抬起
• ACTION_CANCEL- 事件取消

作用：事件分发的入口，由 Activity → ViewGroup → View依次调用，负责将事件传递给正确的View处理。

特点：仅 ViewGroup拥有，决定是否拦截事件。

• 返回 true：拦截事件，交给当前 ViewGroup 的 onTouchEvent处理
• 返回 false / 调用 super：不拦截，继续向下分发

作用：实际处理事件的方法，是事件传递的终点。

• 返回 true：消费事件，事件序列终止
• 返回 false：不消费事件，事件向上回传

特点：外部注入的监听器，在 View 的 dispatchTouchEvent中优先于 onTouchEvent执行。

Android 事件分发遵循"隧道式下发 + 冒泡式处理"的模式：

1. Activity.dispatchTouchEvent()
2   └─ ViewGroup.dispatchTouchEvent()
3        ├─ onInterceptTouchEvent() → true → ViewGroup.onTouchEvent()
4        └─ false → 遍历子View（倒序）
5             ├─ 找到命中（触摸坐标在子View区域内）的子View
6             ├─ 子View.dispatchTouchEvent()
7             │    ├─ 如果有OnTouchListener，先调onTouch()
8             │    └─ onTouchEvent()
9             ├─ 若子View返回true，消费事件，结束
10            └─ 若子View返回false，ACTION_DOWN时继续尝试下一个子View；非DOWN时直接放弃，ViewGroup自己处理

• 隧道式下发：事件从上到下传递，父 ViewGroup 决定是否拦截或分发给子 View
• 冒泡式处理：若子 View 未消费事件（返回 false），则事件向上回传，由父 ViewGroup 的 onTouchEvent处理
• 事件序列锁定：一旦某个子 View 消费了 ACTION_DOWN事件，后续的 MOVE/UP事件将直接发送给该 View，不再重新遍历子 View
• 例外情况：父 ViewGroup 可在后续事件中通过 onInterceptTouchEvent返回 true 拦截，此时子 View 会收到 ACTION_CANCEL事件

在 ViewGroup 的 dispatchTouchEvent中，每次收到 ACTION_DOWN事件时，会调用 cancelAndClearTouchTargets()和 resetTouchState()方法。

这两个方法会清空之前记录的触摸目标（mFirstTouchTarget）和拦截状态（mGroupFlags中的 FLAG_DISALLOW_INTERCEPT）。

因此，当处理新事件序列时，系统会重新尝试将事件分发给子 View，直到找到愿意消费 ACTION_DOWN的子 View。

在非 ACTION_DOWN事件中，ViewGroup 会检查 mFirstTouchTarget是否为 null。

• 不为 null：意味着之前有子 View 消费了 ACTION_DOWN，事件将直接分发给该子 View，不再重新遍历所有子 View
• 父 ViewGroup 拦截：若在后续事件中决定拦截（onInterceptTouchEvent返回 true），则会向子 View 发送 ACTION_CANCEL事件，并将后续事件交给自己的 onTouchEvent处理

作用：子 View 调用此方法会设置 mGroupFlags中的 FLAG_DISALLOW_INTERCEPT标志位。

在 ViewGroup 的 dispatchTouchEvent中，若此标志位为 true，则强制 onInterceptTouchEvent返回 false，即父 ViewGroup 不能拦截后续事件。

本质：多个可滚动的 View 重叠时，系统默认将事件交给上层 View。上层消费 ACTION_DOWN后，事件序列被锁定，下层永久"饿死"。

常见场景：

• 外层垂直 RecyclerView 覆盖内层 ViewPager2（垂直与水平冲突）
• ScrollView 嵌套 RecyclerView（同方向冲突）
• ViewPager2 嵌套 ViewPager2（同方向冲突）

引入：Android 从 Lollipop（API 21）开始引入了 NestedScrollingParent/Child协议，用于解决嵌套滚动冲突。

协议流程：

1. 子 View（如 RecyclerView）调用 startNestedScroll(axes)向父 View 询问是否可以参与嵌套滚动
2. 父 View 通过 onStartNestedScroll回调决定是否参与（返回 true 或 false）
3. 子 View 滚动前，调用 dispatchNestedPreScroll将滚动意图通知父 View
4. 子 View 滚动后，调用 dispatchNestedScroll通知父 View
5. 滚动结束后，调用 onStopNestedScroll

作用：判断 View 是否可以滚动指定方向。

• 参数：direction为 -1（向上）或 1（向下）
• 返回值：true表示可以滚动，false表示不能
• 典型应用：在边界穿透法中，当子 View 滚动到边界时，返回 false让事件穿透给父 View

作用：子 View 通知父 View 在当前事件序列中不要拦截事件。

实现机制：通过设置 mGroupFlags中的 FLAG_DISALLOW_INTERCEPT标志位，强制父 ViewGroup 的 onInterceptTouchEvent返回 false。

局限性：在 ACTION_DOWN阶段无效，因为父 ViewGroup 会通过 resetTouchState()方法清空此标志位。

正确用法：在子 View 的 onTouchEvent中，当确定需要独占事件处理权时调用。

• onInterceptTouchEvent：ViewGroup 特有的方法，用于决定是否拦截事件
• onTouchEvent：View 和 ViewGroup 都有的方法，用于实际处理事件

返回值含义：

• onInterceptTouchEvent返回 true：拦截事件，事件将交给本 ViewGroup 的 onTouchEvent处理
• onInterceptTouchEvent返回 false：不拦截，事件继续向下传递
• onTouchEvent返回 true：消费事件，事件序列结束
• onTouchEvent返回 false：不消费事件，事件向上回传

作用：外部注入的触摸事件监听器。

调用时机：在 View 的 dispatchTouchEvent中优先于 onTouchEvent执行。

返回值影响：若返回 true，事件将不再传递给 View 自身的 onTouchEvent方法。

典型应用：用于监听触摸事件，或在不破坏原有事件处理逻辑的情况下添加额外处理。

错误理解：认为只要子View收到DOWN事件，后续所有事件都会自动传递给它。

正确理解：只有子View消费了DOWN事件（返回true），事件序列才会锁定。若子View未消费（返回false），父ViewGroup仍可拦截后续事件。

错误理解：认为父容器可以在MOVE事件中拦截，即使子View未消费DOWN事件。

正确理解：若子View未消费DOWN事件，后续事件根本不会到达子View的onTouchEvent方法。父容器的拦截逻辑只能在事件序列开始时（DOWN事件）或当子View已消费事件后决定是否中途拦截。

错误理解：认为调用此方法后，父容器将无法再拦截事件。

正确理解：该方法只能对后续事件（非DOWN事件）生效。在ACTION_DOWN事件阶段，父ViewGroup会通过resetTouchState方法清空disallowIntercept标志。

错误理解：认为onInterceptTouchEvent返回true后，事件会被父ViewGroup消费。

正确理解：onInterceptTouchEvent仅决定是否拦截事件，消费事件仍需通过父ViewGroup的onTouchEvent方法。

错误理解：认为可以直接在重写的dispatchTouchEvent中处理事件，无需调用super。

正确理解：若不调用super方法，事件将无法传递给子View。正确的做法是先调用super，再根据需要进行额外处理。

错误理解：认为必须手动重写onInterceptTouchEvent或onTouchEvent来判断滑动方向。

正确理解：Android从API 21开始提供了NestedScrolling协议，通过onStartNestedScroll等方法自动协商滑动方向，是官方推荐的解决方案。

• 日志跟踪：在关键View的dispatchTouchEvent、onInterceptTouchEvent和onTouchEvent中添加日志，跟踪事件传递路径。
• 工具辅助：使用Hierarchy Viewer检查视图层级，确认是否存在重叠或属性设置问题。
• 坐标转换：注意事件坐标是相对于当前View的，若需要在父View中处理，需进行坐标转换。

• 优先使用嵌套滚动机制：对于支持API 21+的项目，应优先使用NestedScrollView或实现NestedScrollingParent/Child接口，避免手动拦截的复杂性。
• 谨慎重写事件分发方法：若必须重写，应理解默认行为并保留其核心逻辑。
• 避免硬编码方向判断：使用canScrollVertically/horizontally等方法动态判断滚动状态。
• 处理ACTION_CANCEL事件：在子View的onTouchEvent中，应对ACTION_CANCEL进行状态清理，确保交互一致性。

• 未调用super方法：在重写的dispatchTouchEvent中直接返回true，导致事件无法传递给子View。
• 坐标系错误：手动转发MotionEvent时，未将坐标转换为目标View的坐标系，导致处理逻辑错误。
• 状态不同步：伪造的事件流可能缺少DOWN事件，导致View内部状态异常。
• 性能问题：在onTouchEvent中频繁创建对象或进行复杂计算，导致卡顿。

单目标、独占式设计：Android事件分发机制是"单目标、独占式"设计，一个事件序列只能由一个View消费。这种设计保证了手势语义的确定性和交互的一致性。

处理权争夺：滑动冲突的本质是多个可滚动View对同一触摸事件的处理权争夺，而非"两个View同时动"。通过理解事件分发机制，可以采用合适的解决方案（如嵌套滚动协议）优雅地解决。

1. 先讲基础：清晰描述事件分发的三个阶段（分发、拦截、处理）和关键方法的作用。
2. 再讲源码：通过ViewGroup的dispatchTouchEvent源码，解释事件锁定和拦截机制的底层实现。
3. 最后讲解决方案：结合实际场景，对比传统拦截法和现代嵌套滚动协议的优缺点。
4. 强调设计原则：解释为何Android采用"单目标、独占式"设计，以及这种设计对用户体验的保障。