第15章 Input系统与事件分发：InputReader与InputDispatcher
说到Android的输入系统，我脑海里第一个浮现的画面就是：用户手指在屏幕上轻轻一滑，背后却是一场精密的三方协作。InputReader负责从硬件读取原始事件，InputDispatcher负责把事件派发给目标窗口，而事件分发流程则决定了事件如何在Activity、ViewGroup和View之间流转。
这一章，我们就来拆解这套机制。我会结合我过去在项目中踩过的坑，帮你把这块硬骨头啃下来。
15.1 InputReader：从硬件到事件的翻译官
InputReader运行在InputReader线程中。它的核心任务，就是从/dev/input/节点读取原始输入事件，然后转换成Android能理解的KeyEvent或MotionEvent。
我个人习惯把InputReader看作一个翻译官。它不懂什么“手指按下”，它只懂硬件上报的原始数据——比如坐标、压力、时间戳。翻译官的工作就是把这些二进制数据，包装成上层能识别的对象。
核心流程：
- EventHub从设备节点读取原始事件
- InputReader解析并分类事件（触摸、按键、轨迹球等）
- InputReader将事件封装成NotifyArgs，发送给InputDispatcher
我记得有一次，客户反馈某款手机触摸屏偶尔会“跳点”。排查后发现是InputReader在处理多点触控时，没有正确合并同一手指的移动轨迹。说白了，就是翻译官把一句话拆成了两半，导致上层以为有两个手指在操作。
避坑指南：我曾经在调试一个低端设备时，发现触摸响应延迟严重。后来定位到是InputReader线程被其他任务阻塞了。解决方案是把InputReader的优先级调高，并确保它的工作队列不被长时间占用。
15.2 InputDispatcher：事件派发的指挥官
InputDispatcher运行在InputDispatcher线程中。它接收来自InputReader的事件，然后根据当前窗口的焦点状态，把事件派发给合适的应用窗口。
你想想看，如果系统里同时打开了三个应用，用户点了一下屏幕，这个事件该发给谁？这就是InputDispatcher要解决的问题。它维护着一个窗口列表，每个窗口都有自己的输入通道（InputChannel）。
派发策略：
- 按键事件：派发给当前焦点窗口
- 触摸事件：派发给触摸点所在的窗口（通过hit test）
- 如果窗口没有及时处理事件（ANR），Dispatcher会记录并上报
嗯，这里要注意。InputDispatcher并不是简单地把事件扔给窗口就完事了。它还会做事件序列化——比如一个触摸按下事件，必须等到对应的抬起事件处理完，才能派发下一个触摸序列。这是为了防止事件乱序。
我曾经遇到过一个诡异的问题：快速点击按钮时，偶尔会触发两次点击事件。查到最后发现是InputDispatcher在派发事件时，没有正确处理“事件超时重发”的逻辑。说白了，就是网络不好时，TCP重传的那种感觉——但触摸事件不能重传，否则用户就感觉“点一下等于点两下”。
15.3 事件分发流程：Activity → ViewGroup → View
事件从InputDispatcher到达应用进程后，就进入了我们熟悉的UI线程事件分发流程。这个流程的核心方法就三个：dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent。
我经常跟团队里的新人说：理解事件分发，你只需要记住一句话——事件从Activity开始，一层层往下传，如果没人消费，再一层层往回传。
15.3.1 Activity的dispatchTouchEvent
事件首先到达Activity的dispatchTouchEvent方法。Activity会调用Window（实际上是PhoneWindow）的superDispatchTouchEvent，最终把事件交给DecorView。
这里有个细节：Activity的onTouchEvent只有在所有子View都不消费事件时才会被调用。说白了，Activity是事件分发的最后一站。
注意：如果你在Activity的dispatchTouchEvent中直接返回true，事件就不会往下分发。这在某些场景下有用，比如你想拦截所有触摸事件做全局手势。但一定要谨慎，否则子View就收不到事件了。
15.3.2 ViewGroup的onInterceptTouchEvent
ViewGroup是事件分发的关键节点。它有两个核心方法：
- onInterceptTouchEvent：决定是否拦截事件。返回true表示拦截，事件不再分发给子View，而是交给自己的onTouchEvent处理。
- onTouchEvent：处理事件。返回true表示消费了事件，不再向上传递。
我见过很多开发者在这里犯错。比如在ScrollView中嵌套了一个可滑动的ViewPager，结果滑动冲突了。原因就是ScrollView的onInterceptTouchEvent在检测到垂直滑动时拦截了事件，导致ViewPager收不到水平滑动事件。
我的经验：解决滑动冲突，核心就是搞清楚谁应该优先处理事件。通常的做法是：在子View的dispatchTouchEvent中调用父View的requestDisallowInterceptTouchEvent，告诉父View“别抢我的事件”。
15.3.3 View的onTouchEvent
View是事件分发的终点。如果View的onTouchEvent返回true，事件就被消费了。如果返回false，事件会沿着ViewGroup → Activity的路径向上传递。
嗯，这里有个容易被忽略的点：View的CLICKABLE和LONG_CLICKABLE属性会影响onTouchEvent的默认返回值。如果View是可点击的，onTouchEvent默认返回true；否则返回false。
// 伪代码：View的onTouchEvent默认行为
public boolean onTouchEvent(MotionEvent event) {
if (isClickable() || isLongClickable()) {
// 处理点击、长按等
return true;
}
return false;
}15.4 触摸事件与按键事件
触摸事件和按键事件虽然都走InputReader → InputDispatcher → 应用窗口这条路径，但它们的处理方式有显著区别。
| 对比项 | 触摸事件（MotionEvent） | 按键事件（KeyEvent） |
|---|---|---|
| 事件类型 | ACTION_DOWN, ACTION_MOVE, ACTION_UP, ACTION_CANCEL | ACTION_DOWN, ACTION_UP, ACTION_MULTIPLE |
| 派发目标 | 触摸点所在的窗口（hit test） | 当前焦点窗口 |
| 事件序列 | 一个完整的触摸序列从DOWN开始，到UP或CANCEL结束 | 每个按键事件独立，DOWN和UP可能不成对（比如长按） |
| 多点触控 | 支持，通过pointer index区分 | 不支持 |
我记得有一次调试一个游戏手柄的兼容性问题。手柄的按键事件在某个设备上总是被系统拦截，无法传递给游戏应用。查了半天发现是系统设置中把某些按键映射成了系统功能（比如音量键）。解决方案是在InputDispatcher的过滤逻辑中，对特定应用放行这些按键事件。
关键区别：触摸事件依赖“命中测试”（hit test）来确定目标窗口，而按键事件依赖“焦点窗口”。这意味着，如果一个窗口没有焦点，它就无法收到按键事件，但触摸事件仍然可以收到（只要用户点到了它的区域）。
15.5 实战：事件分发中的常见问题
说了这么多理论，我们来点实际的。我在项目中遇到过几个典型问题，分享给你：
- 事件被“吞掉”：子View的onTouchEvent返回false，但父View也没有处理，导致事件丢失。排查方法是在每个dispatchTouchEvent中加日志，看事件流到哪里断了。
- 滑动冲突：两个可滑动的View嵌套在一起。解决方案是使用外部拦截法（父View根据滑动方向决定是否拦截）或内部拦截法（子View通过requestDisallowInterceptTouchEvent控制）。
- ANR问题：InputDispatcher派发事件后，应用主线程长时间没有响应。我曾经遇到一个案例，是因为某个View的onTouchEvent中做了网络请求，导致主线程阻塞。
警告：永远不要在onTouchEvent或dispatchTouchEvent中做耗时操作。这些方法运行在UI线程，任何阻塞都会导致界面卡顿甚至ANR。如果你需要处理耗时逻辑，请使用Handler或异步任务。
好了，这一章的内容就到这里。Input系统是Android Framework中比较底层的一块，但理解了它，你就能更好地掌控应用的事件响应行为。下次遇到触摸不灵、按键没反应、滑动冲突这些问题，你应该知道从哪里入手了。
公众号:蓝海资料掘金营，微信deep3321