Android 事件分发机制

Android 里的事件分发，通常指 触摸事件分发机制 ，也就是一个 MotionEvent 从屏幕产生后，如何在 Activity、ViewGroup、View 之间传递、拦截和消费。

面试里最常问的核心，就是这 3 个方法：

dispatchTouchEvent()：分发事件
onInterceptTouchEvent()：拦截事件
onTouchEvent()：消费事件

1. 先理解什么是一次事件序列

用户从按下屏幕到手指离开，会形成一组事件，常见包括：

ACTION_DOWN：按下
ACTION_MOVE：移动
ACTION_UP：抬起
ACTION_CANCEL：事件被取消

这一整组从 DOWN 开始，到 UP 或 CANCEL 结束，叫做 一次事件序列。

注意：

一个完整手势一定从 ACTION_DOWN 开始
后续的 MOVE、UP 通常会交给同一个目标 View 处理
如果父容器中途拦截，子 View 会收到 ACTION_CANCEL

2. 事件分发的整体流程

触摸事件的传递顺序通常是：

Activity -> Window -> DecorView -> ViewGroup -> 子View

如果简化来看，可以理解成：

Activity -> 父容器(ViewGroup) -> 子View(View)

当用户点击屏幕时，事件会从外向内传递，谁最终"消费"了这个事件，后续事件通常就继续交给谁处理。

3. 三个核心方法的作用

3.1 `dispatchTouchEvent(MotionEvent ev)`

作用：分发事件

不管是 Activity、ViewGroup 还是 View，基本都会先收到这个方法调用。

它的主要职责不是"处理"，而是决定：

这个事件要不要继续往下传
交给谁处理

返回值含义：

true：事件被当前层级消费，不再继续传递
false：事件没有被当前层级消费，交回上层处理

可以把它理解成"事件入口"。

3.2 `onInterceptTouchEvent(MotionEvent ev)`

作用：事件拦截

这个方法只存在于 ViewGroup 中，普通 View 没有它。

它决定当前父容器要不要拦截事件，不再交给子 View。

返回值含义：

true：拦截，事件交给当前 ViewGroup 自己处理
false：不拦截，继续传给子 View

典型场景：

外层是 ScrollView
内层是 RecyclerView 或自定义可滑动控件
父容器需要根据滑动方向决定是否拦截

3.3 `onTouchEvent(MotionEvent ev)`

作用：真正处理事件

如果事件最终传到了某个 View 或 ViewGroup，通常会在这里消费。

返回值含义：

true：当前 View 消费了事件
false：当前 View 不处理，事件可能回传给父容器

常见情况：

按钮点击
View 的拖动
自定义手势处理

4. `ViewGroup` 的典型分发流程

以父容器 ViewGroup 为例，触摸事件大致会这样走：

事件先到 dispatchTouchEvent()
ViewGroup 调用 onInterceptTouchEvent() 判断是否拦截
如果不拦截，事件继续传给子 View 的 dispatchTouchEvent()
子 View 再决定是否在自己的 onTouchEvent() 中消费
如果子 View 不消费，事件会回到父容器的 onTouchEvent()

可以概括成一句话：

先分发，再决定是否拦截，最后看谁消费。

5. 一个常见的事件传递例子

假设界面结构如下：

text 复制代码

Activity
  └─ LinearLayout(ViewGroup)
       └─ Button(View)

用户点击 Button 时，事件流程大致如下：

Activity.dispatchTouchEvent()
LinearLayout.dispatchTouchEvent()
LinearLayout.onInterceptTouchEvent()
如果返回 false
Button.dispatchTouchEvent()
Button.onTouchEvent()
如果 Button.onTouchEvent() 返回 true，事件结束

如果 LinearLayout.onInterceptTouchEvent() 返回 true，那么事件不会传给 Button，而是直接交给：

LinearLayout.onTouchEvent()

6. 为什么 `ACTION_DOWN` 很关键

在事件分发中，ACTION_DOWN 非常重要，因为系统通常会根据它来确定本次事件序列的目标 View。

常见规律：

如果某个 View 连 ACTION_DOWN 都没有消费
那么后续的 ACTION_MOVE、ACTION_UP 通常也不会继续给它

所以很多点击、滑动问题，第一步都要先看：

ACTION_DOWN 到底是谁接住了。

7. `onTouch()` 和 `onTouchEvent()` 的关系

开发中还经常会碰到 setOnTouchListener()。

执行顺序通常是：

dispatchTouchEvent()
OnTouchListener.onTouch()
onTouchEvent()

如果 onTouch() 返回：

true：表示监听器已经消费事件，onTouchEvent() 通常不会再执行
false：事件会继续走到 onTouchEvent()

这也是很多面试题喜欢问的点。

8. 点击事件为什么能触发 `onClick()`

onClick() 并不是最先收到事件的方法。

通常流程是：

触摸事件先进入 onTouchEvent()
View 判断这是一组有效点击操作
在合适时机回调 performClick()
最终触发 OnClickListener.onClick()

也就是说：

onClick() 的底层基础，仍然是触摸事件分发。

9. 父子滑动冲突为什么会出现

父子滑动冲突本质上就是：

父容器想拦截事件处理自己的滑动
子 View 也想拿到事件处理自己的滑动

例如：

外层横向 ViewPager
内层竖向 RecyclerView

或者：

外层 NestedScrollView
内层列表控件

这时通常要解决的问题就是：

父容器什么时候拦截
子 View 什么时候请求父容器不要拦截

常见方案：

外部拦截法：父容器根据条件决定是否拦截
内部拦截法：子 View 通过 requestDisallowInterceptTouchEvent(true) 请求父容器先别拦截

10. 事件分发的几个重要结论

结论 1：事件总是先从外层往内层传

先到父容器，再到子 View。

结论 2：`onInterceptTouchEvent()` 只有 `ViewGroup` 才有

普通 View 无法拦截事件，只能消费或不消费。

结论 3：谁消费了 `ACTION_DOWN`，后续事件通常就归谁

除非父容器后续发生拦截，导致子 View 收到 ACTION_CANCEL。

结论 4：父容器一旦拦截，子 View 后续通常拿不到本次序列事件

这也是滑动冲突的核心原因。

结论 5：返回值决定事件是否继续传递

true：消费
false：不消费，继续向上或向下走流程

11. 一段帮助记忆的话

可以用一句简单的话记住：

事件先走 dispatchTouchEvent()，父容器再看要不要 onInterceptTouchEvent()，最后由 onTouchEvent() 决定是否消费。

12. 面试回答模板

如果面试官问"Android 事件分发机制是什么"，可以这样答：

Android 事件分发主要是触摸事件在 Activity、ViewGroup 和 View 之间的传递过程。核心有三个方法：dispatchTouchEvent() 负责分发，onInterceptTouchEvent() 负责拦截，onTouchEvent() 负责消费。事件通常从外层向内层传递，ViewGroup 可以决定是否拦截给子 View；如果子 View 消费了 ACTION_DOWN，后续事件一般也会继续交给它处理。如果父容器中途拦截，子 View 会收到 ACTION_CANCEL。这个机制经常用来解决父子滑动冲突等问题。

13. 总结

Android 事件分发机制的本质，就是：

事件如何传递
谁可以中途拦截
最终由谁消费

真正理解这套机制后，像下面这些问题都会更容易分析：

按钮为什么点了没反应
onClick() 为什么不执行
自定义 View 为什么收不到事件
父子滑动冲突该怎么处理

点我跳转面试题传送阵

Android 事件分发机制