先把结论放在前面：Android 的事件分发不是"一条线走到底"，而是一套在 ViewGroup 手里被反复裁决的分层机制——dispatchTouchEvent 决定"谁处理"，onInterceptTouchEvent 决定"要不要截"，onTouchEvent 决定"处理不处理"，performClick 决定"算不算点击"。 四者各司其职，任何一层写错，表现出来的现象都会指向另外三层，所以这题只看现象几乎无法定位，必须把整条路径在脑子里跑一遍。
事件分发是 View 体系里最容易被"背成模板"的一块。面试中常见的两种丢分方式：一种是只背 onInterceptTouchEvent 返回 true 就"解决冲突"，不问返回 true 之后子 View 的 dispatchTouchEvent 还走不走；另一种是知道有 requestDisallowInterceptTouchEvent，但说不清它在 ViewGroup 里的具体拦截时机。答不到"事件被拦截时 ACTION_DOWN 会不会重发"这一层，基本就停在门外。
一条手势在系统里经历了什么
从手指抬起 ACTION_DOWN 到 ACTION_UP，系统不是把事件直接塞给某个 View，而是先把一整串 MotionEvent 交给 Activity 的窗口，再由窗口交给 DecorView，由 DecorView 这个 FrameLayout 逐层向下派发。理解这条链路的起点是：分发权自上而下，掌握在容器手里；处理权自下而上，容器自己不消费就落到叶子节点。
一次完整的手势里，事件大体分成三段：
- 第一段（DOWN）：
ACTION_DOWN到达时，ViewGroup 会在自己的所有子 View 中做一次命中测试，命中结果记在mFirstTouchTarget与TouchTarget链上。这一步同时决定后续的 MOVE 是否还会往下派发。 - 第二段（MOVE）：
ACTION_MOVE反复到达，ViewGroup 每次都会先问自己"要不要拦截"，决定拦截后会把已经在派发链上的事件统统截走，取消子 View 的手势。 - 第三段（UP/CANCEL）：手势结束，ViewGroup 要么把 UP 继续派发下去，要么根据拦截状态自己合成一个
ACTION_CANCEL发给子 View，把它们的状态机"复位"。
这里的关键机制是 TouchTarget 链。ViewGroup 记的不是一个 View，而是一条从根到叶的链，链上每个节点带着自己被触摸的 MotionEvent 副本（用于坐标转换）。所以 MOVE 事件向下派发时，ViewGroup 会沿途替换事件坐标，把事件从父坐标系转换到子坐标系，命中区域（touchDelegate、扩大点击区的 TouchDelegate）才得以生效。"为什么子 View 收到的 MOVE 坐标和手指在屏幕上的坐标不一样"这类问题，答案就在这段转换里。
最常见的坑是
第一层坑：把 requestDisallowInterceptTouchEvent(true) 写在 ACTION_DOWN 的开头。
这句话在实践中被滥用到了"一按就废掉整个手势链"的程度。正确做法是：先在 DOWN 里只记录坐标（downX/downY），不申请豁免；等到 MOVE 且位移超过 touchSlop、方向判定明确属于自己之后，再调用 requestDisallowInterceptTouchEvent(true)。 这样父容器在用户还在"犹豫是横滑还是竖滑"的那几十毫秒里仍然有机会接管，一旦方向确定，横向的子 View 再把父容器锁死。过早申请豁免的直接后果是外层容器在整个手势周期内彻底失效，出现"横滑列表里套着的 ViewPager 怎么都滑不动"。
第二层坑：拦截后忘记给子 View 发 CANCEL。
ViewGroup 在拦截时会调用 cancelAndClearTouchTargets，并通过 dispatchTransformedTouchEvent 给子 View 派发 ACTION_CANCEL。但若自定义容器重写了 onInterceptTouchEvent 或手动干预了派发流程，漏掉 CANCEL 就会让子 View 内部的 VelocityTracker、GestureDetector、乃至按压态高亮统统停留在"按下"状态，表现为松手后按钮还是选中样式、动画不回弹、后续点击集体错位。排查"松手后状态不复位"这类问题，第一动作就是查 CANCEL 有没有送达。
第三层坑：把 onTouchEvent 返回 true 的时机搞错，导致不可点击。
常见写法是 onTouchEvent 里只处理 ACTION_DOWN 并返回 true，但在 ACTION_DOWN 里先做了个耗时判断再返回 false——手指按下被判定为"不处理"，事件就顺着容器链继续往上冒，最终无人消费，这一整串手势尽数丢失。规范做法是：onTouchEvent 一旦决定接管（返回 true）就要对整个手势负责，直到 UP 或 CANCEL 都有响应，不能中途放弃。
还有一个更隐蔽的坑：把 performClick 删掉。 很多人在自定义 View 里直接 return true 吞掉事件，觉得点击逻辑自己写了就行，却没意识到这会同时丢掉无障碍语义与辅助功能点击。系统的 onTouchEvent 内部在判定为点击时会调用 performClick()，而 performClick() 才是 AccessibilityEvent.TYPE_VIEW_CLICKED 的派发点。删掉它的代价是：TalkBack 读不到这个控件、自动化测试找不到它、屏幕朗读用户无法操作。规范做法是在 UP 之后显式调用 performClick()，并把 setOnClickListener 的逻辑放在这里。
代码里见真章
先看一个方向判定的通用实现，它同时解决"过早申请豁免"和"CANCEL 缺失"两个问题：
class DirectionLockLayout @JvmOverloads constructor(
context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr) {
private val touchSlop = ViewConfiguration.get(context).scaledTouchSlop
private val maxScrollBefore = 120
private var downX = 0f
private var downY = 0f
private var isHorizontal = true // 本次手势的方向判定结果
private var locked = false // 方向是否已锁定
// 父容器专用：只处理"垂直方向需要本容器处理"的场景
private val verticalOnly = true
override fun onInterceptTouchEvent(ev: MotionEvent): Boolean {
when (ev.actionMasked) {
MotionEvent.ACTION_DOWN -> {
downX = ev.x
downY = ev.y
locked = false
isHorizontal = false
}
MotionEvent.ACTION_MOVE -> {
if (locked) return false // 已锁定为横向，本容器不再争抢
val dx = ev.x - downX
val dy = ev.y - downY
if (kotlin.math.abs(dx) > touchSlop || kotlin.math.abs(dy) > touchSlop) {
if (verticalOnly) {
// 方向是水平 → 明确让给子 View
isHorizontal = kotlin.math.abs(dx) > kotlin.math.abs(dy)
} else {
isHorizontal = kotlin.math.abs(dx) > kotlin.math.abs(dy)
}
locked = true
// 关键：判定完成此刻才通知父容器锁死，而非 DOWN 阶段
parent?.requestDisallowInterceptTouchEvent(isHorizontal)
}
}
}
return locked && !isHorizontal // 判定为纵向需求时由本容器接管
}
override fun onTouchEvent(ev: MotionEvent): Boolean {
when (ev.actionMasked) {
MotionEvent.ACTION_DOWN -> {
downX = ev.x; downY = ev.y
return true // 一旦接管，UP/MOVE/CANCEL 都要有响应
}
MotionEvent.ACTION_UP -> {
performClick() // 保住无障碍语义
return true
}
MotionEvent.ACTION_CANCEL -> return true
}
return super.onTouchEvent(ev)
}
override fun performClick(): Boolean {
super.performClick()
// 真正的点击业务逻辑放这里，而不是放在 ACTION_DOWN
return true
}
}
这段代码值得盯三处：第一处，parent?.requestDisallowInterceptTouchEvent 放在 locked = true 之后，也就是方向判定完成之后，而不是 DOWN 那一刻；第二处，onTouchEvent 在 DOWN 返回 true 后对 UP/CANCEL 都有分支，避免"接管到一半被丢下"；第三处，performClick() 的显式调用，把无障碍点击的语义接回来。
再看一个容易被忽略的场景——在 DOWN 阶段父容器不拦截，但手指移动后决定拦截，此时子 View 需要收到 CANCEL。ViewGroup 内部的 dispatchTransformedTouchEvent 会做这件事，但前提是你没有把 onInterceptTouchEvent 的返回值当成"最终结果"直接 return 而跳过了 super 链上的清理逻辑。实践规范是：onInterceptTouchEvent 里只做判定与状态记录，拦截后的清理动作交给父类完成（super.onInterceptTouchEvent(ev) 保持调用链完整），这是最省心的做法。
override fun onInterceptTouchEvent(ev: MotionEvent): Boolean {
// 只记录与判定，不手动清理子 View 状态
val result = judgeDirection(ev)
if (result) parent?.requestDisallowInterceptTouchEvent(true)
return result // 是否清理由 super 内部的 cancelAndClearTouchTargets 决定
}
关于多点触控，这里补一个常被问到的点：ACTION_POINTER_DOWN 到来时，如果当前手势还没锁定，应该重新做一次方向判定并重置内部状态；如果已经锁定，就沿用之前的方向但要把新的指针加入跟踪（用 getActionIndex 取到具体的 pointer id）。多指场景的规范是"用 pointer id 而不是 index 追踪每一根手指"，因为 index 会随着手指抬起而重排。
MotionEvent.ACTION_POINTER_DOWN -> {
val idx = ev.actionIndex
val pid = ev.getPointerId(idx)
// 若尚未锁定，用新增手指重置方向基准
if (!locked) {
downX = ev.getX(idx); downY = ev.getY(idx) }
activePointers += pid
}
MotionEvent.ACTION_POINTER_UP -> {
val idx = ev.actionIndex
val pid = ev.getPointerId(idx)
activePointers -= pid
// 抬起的手指不是主手指时，不应改变锁定方向
if (ev.getPointerId(0) == pid && activePointers.isNotEmpty()) {
val newIdx = 0
downX = ev.getX(newIdx); downY = ev.getY(newIdx)
}
}
面试中的经典考点
问：为什么 ACTION_DOWN 之后子 View 就固定了，后续 MOVE 还会重新命中测试吗？
答：不会。ViewGroup 在 DOWN 阶段通过 findTargetTagForTouchEvent + addTouchTarget 建立 TouchTarget 链并记在 mFirstTouchTarget 上，之后的 MOVE 沿这条链派发，不做重新命中。这带来一个实践含义：如果 DOWN 落在了子 View A 上，手势中途移到子 View B 上，B 不会收到任何事件，直到整个手势结束。所以"滑动过程中想让下方 View 接管"必须自己实现（或在 MOVE 中主动改派发目标）。
问：requestDisallowInterceptTouchEvent 是怎么传到祖先的？
答：它不是"通知"，而是沿 Parent 引用向上打标记。ViewGroup 里维护一个 mGroupFlags 标志位（FLAG_DISALLOW_INTERCEPT），这个标志是同一容器内各个子 View 共享的——ViewGroup 内部用一个布尔字段记录"有子 View 申请过豁免"，setFlags/clearFlags 由容器自己完成，祖先容器在 onInterceptTouchEvent 开头检查它。关键细节是"共享"而非"逐个"：一个兄弟 View 申请豁免，整个容器的其他兄弟也一并受影响。这也解释了"为什么横向列表里的某个子 View 调了豁免，同层其他控件的父容器也拦不动了"——属于共享标志的必产物。
问：怎么排查"点击没反应"？
答：按这条顺序走，效率最高：① 确认 onTouchEvent 是否返回 true（用断点或日志打返回路径）；② 确认 UP 时是否调用了 performClick；③ 确认 View 的 clickable/enabled 状态；④ 确认上层容器有没有把事件截走（打印 onInterceptTouchEvent 的返回值与 dispatchTouchEvent 的分支）；⑤ 确认坐标是否落在 touchDelegate 或被 View 的 padding/位移影响。
问：事件分发和嵌套滚动（NestedScrolling）是什么关系？
答：嵌套滚动不是事件分发的替代，而是事件分发之上的补充。父容器 onInterceptTouchEvent 一旦返回 true，子 View 就彻底收不到 MOVE，此时子 View 内部的 NestedScrollChild 无法把"还有多远"交给父容器处理。规范做法是父容器在准备拦截时返回 false，同时启用 NestedScrollingChild，让滚动量通过 onStartNestedScroll → onNestedScroll 一路传上去，由父容器决定消费多少（CoordinatorLayout 就是这套机制的实现者）。这也是为什么"CoordinatorLayout 里放 RecyclerView 能联动"，而"自己写的 ScrollView 里放 RecyclerView 联动失效"——多数时候后者没有接 NestedScrollingChild。
问：onInterceptTouchEvent 里调用 requestDisallowInterceptTouchEvent 有意义吗？
答：没有意义，甚至有害。这个方法的设计目的是子 View 调用、通知它的父容器；在 onInterceptTouchEvent 里调用时，向上传递的语义是"本节点都不打算处理，却告诉祖先别处理"，逻辑上是矛盾的。父容器想阻止更上层拦截，应该在自己已经拦截（返回 true）之后，依赖派发路径自然阻断，而不是靠这个标志。
落到项目里怎么做
一条能写进代码规范的红线：自绘可点击控件，必须同时满足三条——ACTION_DOWN 返回 true、对 UP/CANCEL 都有响应、UP 之后调用 performClick()。 缺一条，都是缺陷而不是风格问题。
配套实践三条：① 把方向判定抽成可复用的基类，统一 touchSlop、方向锁、CANCEL 处理，避免每个业务容器重写一遍并各漏一处；② 调试手势问题优先用 adb shell getevent -l 看原始事件流，比在代码里加日志更接近真相；③ 涉及嵌套滚动的场景优先用官方嵌套滚动契约而不是拦截，拦截方案会在多指、边缘滑动、非线性滚动上不断出问题。
给正在准备面试的你
这题的答法要落到"四个方法的分工与协作"。推荐这条线：先把 dispatchTouchEvent → onInterceptTouchEvent → onTouchEvent → performClick 的分工讲清（谁裁决、谁消费、谁派发无障碍）→ 讲 TouchTarget 链与坐标系转换，解释 MOVE 坐标为什么变了 → 讲三个坑：过早申请豁免、漏发 CANCEL、删掉 performClick → 落到"方向判定在 MOVE 里做、豁免在判定之后申请"这条规范。能被追问到"拦截后子 View 的 DOWN 还在不在、MOVE 从哪来"，说明真读过 ViewGroup 的实现；能讲清 FLAG_DISALLOW_INTERCEPT 是共享标志，说明踩过"一个子 View 影响了兄弟"的坑。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：自定义-View-进阶：onDraw-与-Paint-的进阶用法
下一篇预告：滑动冲突解决：外部拦截与内部拦截
有任何问题欢迎在评论区留言交流。
