做Android开发这几年，最绕不开的一个坎就是触摸事件分发。你在自定义View、嵌套滚动列表、实现侧滑返回、处理双指缩放的时候，都会撞上同一批问题：为什么子View的点击偶尔没反应？为什么我明明拦截了事件，滑动还是一卡一卡的？为什么GestureDetector的回调总不是预期触发？这篇文章我就把触摸事件分发、手势识别和输入优化这三件事放在一起聊，从基础流程到工程实现、再到常见的性能瓶颈，一条链路讲完。适合刚接触自定义控件的初级开发，也适合在面试前想系统梳理一遍的进阶选手，内容偏实战，看完能直接改善你处理触摸事件的思路。
1. 触摸事件分发的基础链路：一次完整触摸的路由过程
1.1 先搞懂MotionEvent和“事件序列”
很多人一开始就卡在“事件序列”这个概念上。所谓序列，就是从用户的手指按下屏幕到离开屏幕之间，系统连续产生的那一串MotionEvent。这一串事件永远从ACTION_DOWN开始，以ACTION_UP或ACTION_CANCEL结束，中间夹着大量的ACTION_MOVE。
注意我用的是“永远”。因为不少bug就是从这里埋下的——如果你在处理触摸时没有从DOWN事件开始建立状态，而是等MOVE来了再去初始化，那一定会出现逻辑错乱。还有一种常被忽略的情况是ACTION_CANCEL，它不是用户主动触发的，而是系统“半路反悔”，觉得这个事件不该给你，临时取消掉了。比如手指按在按钮上还没松，滑动列表把按钮整个移出了可视区域，系统就会给按钮补发一个ACTION_CANCEL。你的自定义View如果只处理DOWN和UP，不处理CANCEL，就可能出现“按钮看起来被按住了却永远弹不回来”的界面假死状态。
再往深了说，MotionEvent本身还带坐标、压力、时间戳等参数。坐标好理解，压力值在三指手势里有点用，时间戳主要用来做速度计算。但更关键的是，一个MotionEvent对象内部可能携带多个历史采样点，也就是批量事件。比如屏幕刷新率为90Hz时，系统可能每帧触发一次触摸回调，但底层驱动采样的频率更高，这些多余的历史点会以getHistoricalX、getHistoricalY的方式附加在当前事件上。很多实时绘制类应用会漏掉历史点，导致绘制轨迹断断续续，这就是“画线不够顺滑”的常见原因。
1.2 三个核心方法，一张表说清职责
Android的事件分发核心就是三个方法：dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent。Backend有很多文章解释方法间的关系，但最容易混淆的是它们的调用时机。
- 当手指按下，事件到达某一层时，首先调用该层的dispatchTouchEvent，这是入口，决定事件最终由谁处理。
- 如果当前层是ViewGroup，dispatchTouchEvent内部会调用它的onInterceptTouchEvent，返回true表示该层要拦截事件，不再向子View分发。
- 如果事件没有被拦截，dispatchTouchEvent会尝试将它发给子View，子View如果消费掉，整个链条就结束了；如果子View不消费，dispatchTouchEvent就会调用本层的onTouchEvent，作为兜底处理。
注意一个细节：onTouchEvent返回true表示消费这个事件，返回false则表示不消费。而dispatchTouchEvent的返回值，本质上就是“有没有人消费掉这个事件”的最终汇总结果。
只看文字不够直观，我建议任何一个自定义View的开发者在写代码前，先背下这个从伪代码里抽出来的规律：
public boolean dispatchTouchEvent(MotionEvent ev) { boolean handled = false; if (onInterceptTouchEvent(ev)) { handled = onTouchEvent(ev); } else { handled = child.dispatchTouchEvent(ev); if (!handled) { handled = onTouchEvent(ev); } } return handled; }当然，真实的ViewGroup实现要复杂得多，涉及子View按顺序遍历、TouchTarget复用、FORWARDED标记位等，但上面的简化模型足够用于日常问题定位。你只要记住一条核心结论：分发的结果不是“一次搞定”，而是每一层都要做判断，任何一个环节返回true，这条链路就终止。
我见过太多同事在这个模型上栽跟头。他们自定义了一个ViewGroup，在onInterceptTouchEvent里对所有事件一律返回true，然后发现子View彻底收不到任何点击事件。这是最经典的“拦截过头”问题。正确姿势是：如果在DOWN时拦截，那子View连DOWN都收不到，后续当然没有事件；如果在MOVE时才拦截，那子View已经拿到了DOWN，它会认为自己是这串事件的责任人，突然被抢走之后，状态就错乱了。
1.3 Activity到View的完整路由：每一层都在做决策
完整的事件流向是这样：硬件驱动把触摸点上报给系统后，经过InputDispatcher，最终投递到当前Activity的Window对象。Window会交给DecorView处理，也就是整个View树的根。从这里开始，dispatchTouchEvent一层一层向下分发，直到最底层的目标View。
很多人困惑一句话——“为什么子View不处理，事件会冒泡回ViewGroup的onTouchEvent？”其实这正是ViewGroup的dispatchTouchEvent在调用完子View的dispatchTouchEvent之后，发现返回false，于是自己调用onTouchEvent来兜底。这个“反向传回”是View类早已设计好的默认逻辑，不需要你手动去传。
这里想强调另一个经常被忽视的点：TouchEvent一旦被某个View消费，后续的MOVE和UP事件在Android的低版本与高版本上行为一致，都会直接发给那个确定的TargetView，不会再做一次完整的拦截判断。但要小心，在Android 5.x之前，MOVE和UP事件在分发时，如果父容器的onInterceptTouchEvent返回true，仍有机会把事件从子View手里夺走。5.0之后有了嵌套滚动机制NestedScrolling，逻辑又变了：很多滚动到底层的消费是通过NestedScrollingChild接口来传递给父容器的，而不是直接靠onInterceptTouchEvent。这也是为什么你用自定义ViewGroup做嵌套滑动的列表时，最好用嵌套滚动体系，不要只盯着事件分发三件套。
2. 手势识别的工程化写法：GestureDetector不该被写成摆设
2.1 GestureDetector到底帮你干了什么
很多项目里手势判断都是临时写死在onTouchEvent里的。比如判断滑动就用“手指移动超过20像素”，判断长按就用“按下超过500毫秒”，这种硬编码受限太大。更合理的方式是用系统提供的GestureDetector，它帮你做了一套标准的手势状态机。
GestureDetector的OnGestureListener里有几个核心回调：onDown表示手指按下、onShowPress表示按下后短暂停留、onSingleTapUp表示一次单击抬起、onScroll表示持续滑动、onLongPress表示长按触发了。另一个配套的OnDoubleTapListener则处理双击事件。它的运作模式很简单，你只需要在View的onTouchEvent每个事件里，把MotionEvent转发给GestureDetector.onTouchEvent()，剩下的事情交给系统。
我在实际项目里有一个心得：onSingleTapUp和onSingleTapConfirmed是两个不同概念。onSingleTapUp在手指抬起的瞬间就会回调，但是如果你绑定了双击监听，系统还要再等一段“DoubleTapTimeout”时间来确认第二次点击有没有来。所以“单击确认”的时机比“单击抬起”要晚几百毫秒。如果你在onSingleTapUp里触发了跳转，用户双击时会先跳走，体验很怪。类似这种细节，是GestureDetector这种状态机帮你处理得最漂亮的地方。
还有一个典型的坑：onScroll回调里的distanceX和distanceY，是本次事件和上一次事件之间的位移差，而不是从按下点到当前点的总位移。如果你想判断“总滑动距离是否超过某个阈值”，必须自己累加。另外，onScroll的velocityX和velocityY经常为0，不是它没算，而是GestureDetector内部用“连续几帧内的平均位移”来估算速度，在刚开始滑动的第一帧，速度确实算不出来。真要精确的瞬时速度，得用VelocityTracker。
2.2 双指缩放：ScaleGestureDetector和它的坑
双指缩放不用自己算两指距离变化，系统提供了ScaleGestureDetector。它的核心参数包括：getScaleFactor()表示缩放比例，getFocusX()和getFocusY()表示双指的中心点，getSpan()表示当前两指间距。常见做法是在onScale回调里用factor乘以当前的绘制比例。
但这里有几个坑不能不提。第一，双指切换时，比如一个手指离开、另一根还按着，ScaleGestureDetector会新建一个“焦点”，spans会突然变大，导致scaleFactor出现异常跳变。一个简单的保护是在onScaleEnd或onTouchEvent里记录“参与手势的手指数量”，当手指数量变化时，重置上一次的span。第二，ScaleGestureDetector默认是等双指都按上才开始计算的，如果你希望“单指先滚动、双指再缩放”，需要自己管理触摸逻辑，在手指数量变化时切换手势模式，这往往是自定义地图、画板类应用最复杂的部分。
2.3 VelocityTracker：千万别自己手算滑动速度
滑动速度是手势识别里的高频需求，比如列表的Fling、滑动删除的张力效果。系统提供的VelocityTracker封装了速度计算，你只需要在Down时obtain，每次事件调用addMovement，需要的时候调用computeCurrentVelocity并读取速度值。
我给出一个常用的标准化写法：
private VelocityTracker mVelocityTracker; private void initVelocityTracker(MotionEvent event) { if (mVelocityTracker == null) { mVelocityTracker = VelocityTracker.obtain(); } mVelocityTracker.addMovement(event); } private void releaseVelocityTracker() { if (mVelocityTracker != null) { mVelocityTracker.recycle(); mVelocityTracker = null; } } private void calcVelocity() { mVelocityTracker.computeCurrentVelocity(1000); // 单位: px/s float velocityX = mVelocityTracker.getXVelocity(); mVelocityTracker.clear(); }computeCurrentVelocity参数的单位是“每多少秒采样一次速度”，传入1000代表每秒，传入1000时速度单位为px/s。如果你想限制速度的上限，可以继续调用setMaxVelocity传入一个最大阈值，系统会帮你钳制。还有一个细节：每次用完请立刻clear()，并把tracker重新拿来复用，不要每个事件都new一个。这个类内部维护了一个浮点数组，频繁创建销毁会带来没有意义的内存抖动。
3. 事件冲突的艺术：外部拦截与内部拦截
3.1 外部拦截法：父容器掌握主导权
所谓外部拦截法，就是把事件判断与拦截的逻辑写在父ViewGroup的onInterceptTouchEvent里。这是最直观、使用面最广的方案。
一个经典的例子：父容器是水平滑动ViewPager，里面嵌了一个竖直滑动的RecyclerView。此时父容器只关心水平方向，所以它的拦截逻辑可以这样写：如果是DOWN事件，直接放行，交给子View处理；如果是MOVE事件，计算水平方向的位移dx和竖直方向的位移dy，只有当水平位移占绝对优势，并且父容器自身需要滚动时，才返回true拦截事件。
这套逻辑最大的优点是简单。父容器在DOWN时不拦截，保证了子View能正常拿到DOWN事件；MOVE阶段发现方向不对再拦截，此时子View会收到一个ACTION_CANCEL，知道自己被剥夺了事件，于是停止当前的动作。这里有个前提：子View必须正确响应ACTION_CANCEL，否则它可能在父容器开始滚动时，还保留着“自己正在处理手势”的幻觉。
我在写这套逻辑时踩过一个具体的坑：在MOVE阶段使用ev.getX()和ev.getY()算位移，没有考虑事件的rawX和rawY。getX是相对于View自身左上角的坐标，在事件传进子View之后，父容器取到的getX依然有效，因为onInterceptTouchEvent在父容器自己身上执行。但如果你在子View的onTouchEvent里拿getX去判断，那计算的基准就会出错。最简单的经验是：涉及跨层级的位置判断一律用rawX/rawY。
3.2 内部拦截法：子View反向要求父容器放权
有些场景下，父容器无法预判手势走向，或者拦截条件要由子View的状态来决定。此时更适合内部拦截法，核心是requestDisallowInterceptTouchEvent。
子View可以通过调parent.requestDisallowInterceptTouchEvent(true)，要求父容器在后续事件里不再拦截。但注意，父ViewGroup在收到这个请求后，onInterceptTouchEvent依然会被调用，但它会在内部检查FLAG_DISALLOW_INTERCEPT标记，如果被标记，就不会真正拦截。也就是说，requestDisallow生效的前提是父ViewGroup在实现onInterceptTouchEvent时没有强行绕过这个标记。所以内部拦截法的约定是：父容器的onInterceptTouchEvent在DOWN时返回false，在MOVE时不拦截，专门留出“把决定权交给子View”的空间，子View在准备开始自己的手势前，通过requestDisallowInterceptTouchEvent(true)锁住整个事件流。
举个实际场景：一个支持双击缩放的图片内部，又内嵌了一个可以横向拖动的元素。当用户手指按下去时，系统并不知道用户是想双击、想缩放、还是想拖动子元素。所以父容器必须在DOWN时放权，子View在自己的onTouchEvent里根据用户行为动态决定——如果判断是拖动子元素，就调用requestDisallowInterceptTouchEvent(true)，让父容器不插手；如果判断是双击，则不停用父容器的行为，让父容器的onInterceptTouchEvent有机会介入。
这里有个隐藏的细节：子View请求disable拦截的时机非常关键。如果你在DOWN事件里就立刻请求disableAll，那父容器连后续MOVE的拦截判断都没机会执行，等于完全锁死了事件流。但如果你在“已经确认手势方向且不希望父容器参与”时才请求disable，父容器在之前已经可以拦截，子View也来得及反悔。这个“时机差”就是很多冲突问题从“能跑”到“丝滑”的距离。
3.3 手势冲突的“方向判定”与TouchSlop
处理横竖滑动冲突时，多数方案是看dx和dy的绝对值谁更大。但这里有一个要害：如果把“方向判定”的时机放在手指按下后的第一时间，就会非常敏感——用户只要稍微斜着按下5度角，方向就已经偏了。实际工程里正确的思路是：先用一段较小的滑动距离“攒经验”，等滑动超过系统阈值TouchSlop后再做方向决策。TouchSlop通过ViewConfiguration.get(context).getScaledTouchSlop()获取，它是系统用来区分“滑动”与“误触”的基准值，通常只有几像素到十几像素。在这段距离内的位移不算滑动，一旦超了，就认为用户在明确地移动手指。
你会发现在实际开发中，只要把方向判断放在TouchSlop之后，手感就会稳定很多。这个方案也适用于“侧滑返回”这类场景：手指在屏幕边缘横向滑动超过TouchSlop才认定为“返回意图”，否则让给子View处理。
4. 输入优化：从能响应到跟手
4.1 触摸响应不跟手，常常是因为触摸链路太重
“跟手”是一个很难量化的软性指标，但它背后有清晰的硬件链路。触摸事件从驱动上报到App的最终回调，中间会经历InputReader、InputDispatcher、应用进程的InputChannel，最终通过主线程的Looper回调到ViewRootImpl，再分发到View树。这整条链路里，任何一点延迟都会被用户感知为“卡顿”。
其中一个最容易被发现的瓶颈是：onTouchEvent和onDraw跑在同一条主线程。如果你在onTouchEvent里做了文件读写、网络请求、数据库查询，那主线程的Looper会被阻塞，触摸事件的后续分发只能排队，画面自然就不跟手。我在一次性能排查中见过这样一个例子：一个列表项的onTouchEvent里写了一个SharedPreferences的commit操作（同步写磁盘），结果用户滑动列表时整帧延迟50ms以上。改成apply之后，卡顿肉眼可见地消失了。
另外要特别注意，触摸事件的回调频率跟屏幕刷新率相关，而不是固定60Hz。120Hz刷新率的手机上，一秒钟回调120次MOVE都不稀奇。这意味着一帧画面只被分配了大概8ms的时间预算。如果你的onTouchEvent里做了一堆轻量级操作，也可能叠加成卡顿。一个经验性建议是：onTouchEvent里的代码要精简到“只修改参数、不执行复杂逻辑”，真正的内容更新放到下一帧的绘制阶段去处理。
4.2 MotionEvent里的批量历史点：别浪费系统给的高频采样
前面提到过，MotionEvent是批量传递的，一个事件里会携带多个历史采样点。很多开发者处理滑动轨迹时只处理当前点，导致绘制轨迹在一个高刷屏上依然断线。更好的写法是在onTouchEvent里循环读取历史点，你可以用event.getHistorySize()拿到历史点个数，再配合getHistoricalX(i)、getHistoricalY(i)、getHistoricalPressure(i)遍历处理。
把历史点全部处理掉，不仅让轨迹更完整，还有一个额外好处：即便主线程在某段时间里有点忙、触摸事件被延迟派发，你也依然能从当前那一个事件里补回多个采样点的数据，这相当于帮触摸链路“追上了丢失的帧”。我自己做的笔画绘制类应用，开启历史点遍历后，线条平滑度提升了一个档次。
4.3 合理使用系统触控参数，别硬编码
触控相关的几个参数常常被忽略：getScaledTouchSlop()是滑动阈值，getScaledMinimumFlingVelocity()和getScaledMaximumFlingVelocity()分别是最小和最大滑行速度。做自定义下拉刷新或控件拖动时，用这些系统参数会让交互手感与全局保持一致，而硬编码一个“15像素”极容易在不同DPI设备上出现体验分裂。
我还想提一个“双击间隔”参数：ViewConfiguration有getDoubleTapTimeout()和getLongPressTimeout()，它们告诉你系统认定的双击间隔和长按临界值。如果你在自定义手势里需要判断“用户是长按还是普通点击”，直接用这些阈值就行，不需要自己猜一个数字。
4.4 用Choreographer把触摸和绘制帧分离
这里分享一个较进阶的优化思路。如果某个操作对实时性要求很高，但每次MOVE事件里又不好直接启动，可以借助Choreographer的帧回调，把“由触摸引发的更新”合并到本帧的Vsync回调里去执行。
思路是这样：手指滑动时会产生一个更新请求，我们不是立刻刷新视图，而是用一个boolean变量标记“需要更新”，并调用Choreographer.postFrameCallback；等系统在本帧的Vsync到来时，再统一执行一次更新。这样不管这一秒触摸事件来了多少次，每一帧最多只更新一次视图，避免重复劳动。手势拖动自定义控件时，我用这个方案成功把CPU占用降了下来，流畅度反而更好。
5. 常见问题与排查技巧：一段摸爬滚打的实录
5.1 几个高频问题的定位速查
我把实战中遇到的典型触摸问题整理成一张表，方便你以后做快速对照：
| 问题现象 | 可能的直接原因 | 排查方向 |
|---|---|---|
| 点击事件偶尔失效 | 父容器在DOWN时拦截了事件，子View从未获得事件 | 打印父容器onInterceptTouchEvent的所有返回值 |
| 列表滑不动，点了都像被吃掉 | 自定义ViewGroup事件分发没调用super，或强制重定向了所有事件 | 检查dispatchTouchEvent里是否直接return true |
| 按下不弹起，松手无反应 | 缺少ACTION_CANCEL的处理，状态一直卡在“按下” | 模拟手势事件或在滚动交互中观察CANCEL是否到来 |
| 双击时先触发单击 | 使用onSingleTapUp而不是onSingleTapConfirmed | 切换为onSingleTapConfirmed |
| onScroll不触发 | 没有把所有事件转发给GestureDetector | 确认onTouchEvent里没漏事件 |
| 滑动不跟手或掉帧 | 触摸回调里干了太多重活 | systrace观察主线程耗时 |
| 双指缩放比例突变 | 手指数量变化导致span跳变 | 在手指数量变化时重置基准span |
5.2 调试工具三板斧：打印、dumpsys、systrace
遇到触摸疑难杂症，我第一件事不是读源码，而是打印事件流日志。最简单的做法是在View的dispatchTouchEvent里打印action和返回值，用Log.d加一个专门的tag。其实99%的问题只要看上十几行事件流日志，原因就清楚了。打印时建议把MotionEvent.ACTION_MASK转换出来的动作值一起存下来，还要带上x和y，方便判断坐标是否异常。
如果怀疑是系统输入分发层面出问题，可以用命令dumpsys input，它能让你看到输入管道的状态、注册的InputMonitors、最近的输入事件记录。这个命令能帮助区分问题出自系统层还是应用层。
而帧级性能问题，我强烈建议用systrace。打开systrace后，触摸事件对应的TouchEvent回调、Vsync信号、Choreographer帧回调都一目了然。你会直观看到：到底是不是某个耗时的onTouchEvent把整帧拉垮了。曾经有一次排查列表卡顿，我从systrace里发现某个自定义View的onTouchEvent里调用了requestLayout，导致每个MOVE都触发一次测量+布局，整棵树全被遍历一遍。去掉后的性能提升立竿见影。
5.3 一个实际案例：快速滑动列表时偶现的抖动
去年我优化过一个“带吸顶效果的双向滑动面板”，用户反馈快速滑动时尾部元素偶尔会抖动。数据结构上看，是外层垂直滑动的ScrollView嵌套了一个水平翻页的自定义ViewGroup。快速滑动时，手指在垂直方向移动的瞬间，水平方向也有微小位移，水平容器一旦检测到dx就立刻拦截事件，把滚动切成了水平方向，然后垂直方向又立刻反抢回来，两者反复拉扯，就产生了抖动。
解决方式就是前面提到的TouchSlop策略：在孩子水平容器里，连续累积一段位移且绝对值超过TouchSlop后，才认定“水平手势意图成立”，此时再调用requestDisallowInterceptTouchEvent(true)锁住事件。而在此之前，位移全部让给父容器的垂直滚动。用完这个方案之后，抖动彻底消失，手感变得干净利落。这件事让我更加确信：触摸相关的问题往往不是单一逻辑错误，而是“状态切换时机”没掌握好。
从事件分发的全链路到手势识别的工程实现，再到输入优化的多线程手段，这几个模块是环环相扣的。我写这篇文章时投入了不少自己的踩坑经验，归根结底就一句体会：触摸事件的处理逻辑，核心是状态机的管理。无论哪个环节，只要理清事件的来源、去向和取消条件，大多数问题都能迎刃而解。最后再分享一个小技巧，以后调试触摸问题时，可以自己建一个LogFilter，把事件流的action和返回值全部标记好，对照着事件序列看问题，你也会慢慢积累出自己的“手感”判断力。
