1. 从触摸到界面的第一公里：输入子系统到底管了什么
如果你做过几年Android应用开发，大概都遇到过这类问题：自定义View里的焦点冲突、RecyclerView滑动时莫名触发点击、OEM厂商的ROM偶尔出现的触摸不灵。这些问题表面上看是View层的事，但真正追下去，全都会沉到Android的输入子系统。它就是从你手指落到屏幕那一刻起，到你的App收到MotionEvent为止，中间经过的所有环节的总称。
我第一次接触输入子系统，是当年在改一个驱动返修的案子，刚开始以为只是屏幕驱动的问题，改了一周都没起色。后来才明白，问题根本不在驱动，而在输入子系统里的某个超时阈值上。那次之后我才意识到，搞懂输入子系统不只是做Framework开发的专利，做应用、做定制、做系统优化的，都需要对它有完整的认识。
这篇文章我按自己梳理体系的顺序来写：先讲清楚输入子系统在整个Android系统里的定位和数据流向；再把InputReader、InputDispatcher这两个中坚组件拆开逐个看；然后回答一个很多人困惑的问题——我们自己写的代码是怎么接入这个子系统的；接着给一套完整的调试命令和源码阅读路径，最后附上几个真实的排查案例。整体偏向Framework和系统应用开发者，但如果你是在做常规应用开发，这篇同样能帮你定位很多疑难杂症。
2. 纵向看一次触摸的完整旅程
2.1 硬件到底是怎么把手指位置上报的
Android设备上的屏幕，绝大多数是电容式触摸屏。简单说，它靠的是多根电极构成一个网格，手指靠近时改变了电极间的电容，触控IC通过扫描这个电容变化矩阵，就得到了手指的坐标。整个过程大概每几毫秒到十几毫秒刷一次，取决于IC的扫描频率和firmware里的配置。
触控IC得到坐标后，把数据按照I2C、SPI或者USB协议发送给SoC里的对应控制器。Linux内核里对应的是input子系统，它抽象出了input device的概念。你在设备上看到的/dev/input/eventX，就是这些设备开放出来的节点。当有触摸事件发生时，驱动往event节点里写入一个input_event结构体，里面带了type、code、value三个要素。
举个例子，手指按下去，驱动会依次上报：
- EV_ABS / ABS_MT_POSITION_X，带上x坐标值
- EV_ABS / ABS_MT_POSITION_Y，带上y坐标值
- EV_ABS / ABS_MT_TRACKING_ID，带上一串标识触点的ID
- EV_KEY / BTN_TOUCH，值置1表示按下
- EV_SYN / SYN_REPORT，表示上面这些信息在同一个时间点批次上报
之所以用EV_SYN包一层，是因为触摸事件天然是成组出现的，坐标和压力是同一帧的数据，接收端必须等到SYN_REPORT才能确定一批数据完整了。绝大多数触摸不跟手的Bug，追下去通常能在这一层的上报时序上找到线索。
2.2 三个“读”与“派”的主心骨：InputReader与InputDispatcher
内核上报了事件，接下来就轮到Android Framework层接手。这一层有两条大腿，一个叫InputReader，一个叫InputDispatcher，都跑在system_server进程里的InputManagerService中。
IInputReader的职责很简单，概括成一个字就是“读”。它通过EventHub从所有/dev/input/eventX节点读取原始事件，然后把原始的input_event转换成框架层能理解的InputEvent。这个过程包括了坐标归一化、按键去抖、多点触控slot管理、按键映射等处理。
转换完成后，事件不会立刻派发，而是进到一个叫QueuedInputListener的队列里，等待被批量送到InputDispatcher。InputDispatcher才是真正干活的人。它维护了一张窗口注册表，知道当前屏幕上哪些窗口是可见的，各自占据了哪块区域，以及它们的输入通道状态。当一个事件到达，Dispatcher根据事件类型和目标窗口的焦点状态，决定把事件投递给谁，以及要不要等前一个事件处理完再投递下一个。
这两条腿之间的关系，用生活化的办法去理解：InputReader就是前台的服务员，负责把客人（硬件）递过来的菜单（原始事件）抄写清楚，比如客人在哪个位置点了哪道菜；InputDispatcher是后厨的调度员，决定哪个厨师（应用窗口）先做哪道菜，以及做完的菜该端到哪一桌去。
但凡是做过系统级输入问题排查的人，应该都能体会这两个组件对稳定性的影响有多大。InputReader一旦被阻塞，全线触摸都会停住——最典型的现象就是整个系统死Touch，表现为任何触摸都没有反应，而系统其他部分还在运行。
2.3 到了应用侧，View树是怎么分掉这次触摸的
事件从InputDispatcher出来以后，会经过一个叫InputChannel的Socket通道，送达目标应用进程。应用进程这边，ViewRootImpl负责接收事件，然后再把事件交到View树的根部，我们常说的DecorView，由此开启一段事件分发流程。
这段流程所有Android开发者都很熟悉：
- dispatchTouchEvent：入口，负责决定要不要处理这个事件
- onInterceptTouchEvent：ViewGroup专属，决定是否拦截事件，不让子View继续拿
- onTouchEvent：真正处理事件的地方
这个流程最让人纠结的就是事件“分发—拦截—消费”三者之间的关系。一个比较核心的记忆点是：事件总是从外层向内层分发，但拦截发生在分发之前。也就是父View的onInterceptTouchEvent一旦返回true，子View就再也收不到后续事件了。
拦截这个设计的本意，是用来解决“父View和子View都要响应手势但只能有一个赢家”的问题。典型场景就是横向滑动列表嵌在纵向滑动容器里，两个方向都想动，父容器通过拦截机制决定谁胜出。顺便说一句，这个机制可以在ViewGroup里覆写requestDisallowInterceptTouchEvent来让子View强行要求父View不要拦截，这也是很多滑动冲突方案的基础。
最容易被忽略的一点是：事件处理不是以单个事件为单位，而是以“事件序列”为单位的。一个完整的手势序列，从ACTION_DOWN开始，中间一堆ACTION_MOVE，最后ACTION_UP或ACTION_CANCEL结束。序列里的第一个事件ACTION_DOWN决定了整条序列交给谁处理，如果没有人消费这个事件，那么后面的MOVE和UP也都不会有人接手。这也是为什么很多自定义View里，如果ACTION_DOWN返回false会导致后面再也收不到事件。
3. 把InputReader的一次事件循环拆开来看
3.1 EventHub：最底层的“扒皮”
InputReader的第一步，是从EventHub拿事件。EventHub是输入子系统里最靠近内核的一层封装，它维护着一个设备列表，不断通过epoll机制监听所有输入设备节点的可读状态。有事件进来时，EventHub把原始input_event数据读取出来并解析成RawEvent结构。
在我看来，EventHub的设计中最值得学习的一点是，它把“设备管理”和“事件读取”做了非常彻底的解耦。新的输入设备接入时，比如插上USB键盘或者连接蓝牙手柄，EventHub会单独开一个线程去做设备初始化的事，不会阻塞正在处理触摸事件的流程。设备可选的能力如按键布局、触摸屏参数，都由EventHub在设备注册的瞬间加载好，这为后续输入事件的处理提供了统一的视图。
如果你已经自己编译过Android系统做过定制，建议重点看EventHub::getEvents这个方法的返回值类型和数据结构，它直接决定了上层拿到的是“一批”事件还是“一个”事件。为了吞吐效率考虑，实际实现里是会尽力一次读取尽量多的事件的，这样能有效减少从内核态到用户态的切换开销。
3.2 坐标映射、校准、去抖：原始事件到InputEvent的转变
从EventHub拿到RawEvent以后，InputReader要通过不同的Mapper把事件分门别类地转换。触摸屏对应的叫TouchInputMapper，它要做的事情非常多，这里列一些容易出问题的点：
- 坐标归一化。RawEvent里的坐标范围，取决于触控IC的扫描分辨率和上报方式，比如最大坐标可能是4095，而屏幕分辨率是1080x2400，归一化就是把坐标按比例映射到屏幕的物理像素范围。
- 多点触控管理。现代触摸屏上报多点数据时用slot (ABS_MT_SLOT)来区分触点是哪个，InputReader需要把不同slot的数据组合成完整的多指信息。
- 手指抬起检测。有的触摸IC在最后一个手指离开的时候不会明确上报一个“无触点”事件，而是靠Tracking ID变成-1来隐式表达，InputReader需要能正确识别这种状态并把之前的触点信息清掉。
- 边缘抑制和掌误触。这些属于进阶策略，一部分在固件里实现，一部分可以在InputReader层面的配置里调整。
最容易踩的坑是触摸屏的坐标轴方向反了，比如x轴镜像。这种问题在RawEvent层面看数据是完全正常的，必须通过修改驱动或者配置文件的坐标轴参数来修正。还有一种情况是触摸屏和显示屏的分辨率不一致，比如屏是1080x2400，触摸IC上报最大值是720x1600，如果两边没有做好归一化，你会发现触摸点永远比手指实际按的位置偏出一截。
3.3 策略和配置：InputReaderConfiguration里能调什么
InputReader的很多行为逻辑不是写死在内核里的，而是在运行期通过InputManagerService注入的配置来调整。最典型的就是在开发者选项里打开的“显示触摸位置”和“指针位置”，这两个功能就是在InputReader层面加了额外的显示输出。
厂商定制时接触比较多的配置包括：
- 触摸屏灵敏度，在部分设备的触摸参数配置里可以调
- 虚拟按键的映射表
- Stylus（手写笔）相关的配置
- 外接设备的按键布局文件（.kl文件）
如果你们在做的产品需要适配多种触控IC，建议仔细看一下设备树里对input设备的能力上报，以及InputReader怎么利用这些能力做自由配置。很多客制化的“手势唤醒”“双击亮屏”，本质上都是在InputReader层面加入了对特定事件序列的识别逻辑。
4. InputDispatcher：它到底有多操心
4.1 窗口注册表：谁在我上面、谁在我下面
InputDispatcher为什么能把事件准确地发到对应的窗口？靠的是它维护的那张窗口注册表。Android的窗口管理服务WindowManagerService（WMS）每次添加、移除或者调整窗口时，都会同步更新InputDispatcher里的这份登记信息。
每个窗口对应一条WindowState，里面记录了：
- 窗口在屏幕上的可见区域和布局位置
- 窗口的安全区域（对于全面屏应用来说，就是挖孔、刘海周围的区域怎么处理触摸）
- 窗口的InputChannel，事件实际写入的通道
- 窗口的焦点状态、暂停状态（比如是否被遮挡）
这个机制让我想起邮局的分拣中心——每个窗口就是信封上的地址，分拣员看到了地址就能准确投递。如果分拣台的地址簿错了，即使信封上的地址没问题，信也会送错门。
由于这是一份跨进程共享的“登记表”，所以它的生命周期必须非常严谨。如果窗口销毁了但登记表没删干净，后续的事件可能会被发送到一个已经不存在的窗口，这在系统UI层面往往表现为点击无响应或者事件丢失。
4.2 派发策略：为什么有的窗口收不到事件
InputDispatcher对事件的派发并不是“谁在屏幕最上面就给谁”这么简单。实际决策要考虑的因素有：
- 焦点窗口。键盘事件、按键事件这类，是发给焦点窗口的，跟点击位置无关。焦点由WMS管理，通过InputDispatcher执行。
- 触摸目标的命中测试。按下的时候，系统会根据手指坐标计算哪个窗口在触摸事件覆盖区域的最上层，该窗口即成为本次事件序列的目标。
- 可暂停窗口。如果一个窗口处于“paused”状态，比如被一个动画遮住了一半，Dispatcher会把事件改为投递给下层可见窗口，而不是强行发给它。
- ANR状态。如果一个应用已经触发ANR，Dispatcher会中止继续给它投递事件，后续事件会被转给其他窗口或直接丢弃。
这里有个从旧版本到新版本的变化值得关注。Android 12开始用了一些新的事件派发模型，对“事件被消费后是否继续向下派发”的处理和旧版本有差异，如果遇到“下层窗口收不到事件”的问题，建议先确认设备系统版本再定位。
4.3 输入ANR：为什么应用会“无响应”
输入超时是InputDispatcher里的一个时间戳机制。应用通过InputChannel收到事件后，需要在规定时间内处理完成并回执一个“finished”信号给Dispatcher。如果超时未回复，比如主线程被卡死，Dispatcher就会认为该窗口无法及时消费事件，进而触发应用的ANR弹窗。
不同事件类型的超时阈值不一样：
- 触摸事件：5秒
- 按键事件和轨迹球：10秒
- 由于队列积压导致的等待超时：也可能更快触发
开发应用时如果不注意在主线程里做耗时操作，很容易踩中这个机制。尤其是自定义View的onDraw里做了大量计算，或者把磁盘IO放在了UI线程——一旦触摸卡顿超过阈值，系统就会判定应用无响应。
排查输入ANR时，核心看两个数据：一是Dispatcher的等待状态和事件的投递时间戳；二是应用主线程的调用栈。前者可以通过dumpsys input看到，后者用debuggerd或者Android Studio的CPU Profiler抓。
5. 我们自己写的代码是怎么和这套系统对接的
5.1 Window、ViewRootImpl与InputChannel
可能很多做应用的同学从来不需要关心Window是什么，但输入事件分发里，Window才是真正的最小单位。你在Activity里通过setContentView加上的View，是放进了一个由系统管理的Window里的；Dialog是另一个独立的Window；PopupWindow、Toast、输入法窗口，都有各自的Window。
与输入相关的是，每个Window创建一个InputChannel，这个通道是socket对，两端一头连着system_server里的InputDispatcher，另一头连着应用进程。一个Window是否能够接收到触摸事件，决定了它是否在WindowManager里被正确注册并且获取到了焦点。
在系统侧创建Window时，WMS会通过addWindow方法把窗口信息同步给InputDispatcher。多窗口模式下，比如分屏，每个应用窗口都会对应独立的InputChannel，事件通过触摸落点来判断该发给哪个窗口。
5.2 事件从InputChannel到Activity的最后一跳
应用进程的InputChannel端，通过Looper的epoll机制监听可读事件。事件到达时，由Native层的NativeInputQueue读取，然后排入一个监听队列，再通过JNI回调Java层InputEventReceiver的dispatchInputEvent方法。
这里有几个需要特别留意的细节：
- 应用端的输入队列是异步的，等主线程空闲时才处理，但它也会在事件分发前检查主线程是否卡顿，如果卡顿就会打印Choreographer相关的警告日志。
- 事件处理完毕后必须调用finishInputEvent回执，这个环节如果漏了，会导致Dispatcher端永久等待，表现为后续所有事件都被阻塞。
- 从ViewRootImpl到Activity的传递，中间经过了View.post、Handler等一系列机制，这也意味着，如果主线程的MessageQueue被长时间占用，即使InputChannel已经收到事件，也无法被处理，最终引发ANR。
5.3 给应用开发者：怎么让自己处理事件更安全
做过一些大型App之后，我对应用侧事件处理有几点总结：
- 不要重写dispatchTouchEvent来绕过所有事件的传递链，除非真的清楚它在做什么。破坏传递链会让很多系统行为失效，比如可访问性服务、手势导航等。
- 处理触摸事件时尽量少做全局变量赋值和对象创建，触摸事件频率高，短时间内的对象分配会造成GC压力，进而影响帧率和触摸响应。
- 长列表的滑动顺畅度，往往不是View代码的问题，而是父容器拦截事件的行为太“聪明”了。合理地使用requestDisallowInterceptTouchEvent能解决一大半滑动冲突，但要记得在适当时候重置状态。
- 自定义View想要接收到Move事件，一个常见的坑是ACTION_DOWN返回false后整个序列都收不到。务必让ACTION_DOWN返回true。
这些都是踩过才会记住的东西，单独拎出来写在这里。要是你能在一开始做架构设计时就考虑到输入事件的分发链路，后续的疑难杂症会少很多。
6. 实践：调试输入子系统的标准工具箱
6.1 dumpsys input：最常用的现场还原命令
在设备连着adb的情况下，dumpsys input能输出一大批信息。我习惯重点看这么几个部分：
- Input Dispatcher State，里面有一堆窗口的注册信息和通道状态
- FocusedApplication，显示当前持有焦点的应用
- TouchStatesByDisplay，显示各显示设备上的触摸状态
- KeyStatesByDevice，键盘类设备的按键状态
- Configuration，输入相关的系统配置
如果事件没有按预期派发，先看这里。比如应用收不到事件，但dumpsys input里显示窗口已经注册且焦点也在它身上，那问题大概率在应用侧；反过来，如果窗口根本没注册，那就是窗口管理的问题。
补充一句，dumpsys input里输出的内容在不同Android版本间差异很大。我见过很多人在Android 8上的笔记直接拿到Android 13上对着找字段，结果对不上号。建议先看输出的开头部分，那里会标明版本和Build号，心里有底再去找对应版本的源码。
6.2 getevent与sendevent：内核的“心电图”
getevent是直接读/dev/input/eventX的裸数据命令，不打任何框架层补丁，看到的是内核上报的原始值。
比如想确认手指按下时驱动是否正确上报了坐标，执行：
adb shell getevent -lt /dev/input/event2其中-l参数表示同时输出可读的标识名，-t表示带上时间戳。定位触摸问题，这招基本是百试百灵的第一步——先看原始事件是否存在，如果驱动层就没上报，后面框架层再怎么查都白搭。
sendevent则是往设备节点里写入事件，用来模拟一次触摸输入。最常见的情况是：UI上有一个按钮，写脚本自动点击，用于自动化测试或者验证InputReader的处理逻辑。
adb shell sendevent /dev/input/event2 3 57 0 adb shell sendevent /dev/input/event2 3 53 500 adb shell sendevent /dev/input/event2 3 54 500 adb shell sendevent /dev/input/event2 1 330 1 adb shell sendevent /dev/input/event2 0 0 0 adb shell sendevent /dev/input/event2 3 57 -1 adb shell sendevent /dev/input/event2 1 330 0 adb shell sendevent /dev/input/event2 0 0 0这段代码模拟的是：在(500, 500)位置按下，然后抬起。其中3代表EV_ABS，57是TRACKING_ID，53、54分别对应X和Y，1代表EV_KEY，330对应BTN_TOUCH，0 0 0是SYN_REPORT。用的时候注意每个设备的坐标范围不一样，盲按坐标很容易按到屏幕上奇怪的地方。
6.3 input命令：往系统里注入事件的正规方式
如果不想折腾底层设备节点，可以用input命令从Framework层注入事件。
adb shell input tap 500 500 # 在(500,500)位置点一下 adb shell input swipe 500 1000 500 200 300 # 从(500,1000)滑到(500,200)，耗时300ms adb shell input keyevent KEYCODE_HOME # 按Home键 adb shell input text "hello" # 输入文本input命令走的是InputManager.injectInputEvent接口，权限要求比较高，普通应用是没法直接调的，但shell权限可以。自动化测试框架，比如UIAutomator底层也在用它。遇到触摸屏本身是坏的这种场景，这条命令能帮你判断系统其余部分是否正常，因为它绕过了物理触摸屏，直接从框架层注入。
7. 实战：三个典型的输入子系统问题排查记录
7.1 问题一：滑动列表时偶尔触发点击
现象是RecyclerView上下滑动过程，偶尔会误触发某个item的点击事件。从用户角度就是“我明明在滑动，怎么点进去了”。
排查思路从事件序列角度切。滑动过程本来就会产生一系列ACTION_MOVE，如果某个item的点击判断逻辑只盯着ACTION_UP，而没判断在此之前是否有大幅度的位移，就会把一次滑动误判为点击。
解法要么在自定义的点击判断里加slop距离阈值，要么在父容器拦截滑动事件，让滑动时子View收不到相关事件。实践中，也见过一种情况是InputDispatcher把两个快速触摸的触点处理为同一条事件序列，属于底层需要调试的范畴，但概率很小。
如果遇到这个现象，优先怀疑应用侧的touch slop处理逻辑，再考虑输入通道的时序问题。
7.2 问题二：解锁后第一次触摸“丢”掉
现象是息屏一段时间再解锁，第一次触摸屏幕没有反应，第二次之后恢复。这个问题在个别ROM上还挺常见。
追根溯源要看两层。第一层确认底层是否有上报，用getevent看解锁后的第一次触摸有没有数据；第二层看InputDispatcher里该窗口的状态是不是正常的。
我遇到过一次，根因在电源键唤醒的流程中没有正确把输入设备的状态切回active，InputReader在设备重新唤醒后短暂处于一个“假休眠”状态，导致第一批事件被丢弃。这种问题，单靠调应用代码是解决不了的，得去改系统里的电源管理和输入设备状态同步逻辑。
如果你在自己的定制设备上遇到，建议先开一下dumpsys input，看看设备唤醒后的InputReaderConfiguration是不是正确的。
7.3 问题三：屏幕上半部分触摸无响应
现象很好描述：屏幕下半部分正常，上半部分怎么点都没反应，也没有断线。
一般先怀疑是触控屏的布线区域问题，但实际跑了getevent之后发现，事件在上报的时候，坐标范围整体被限制在半屏范围内。继续查是InputReader在归一化时用了一个错误的坐标范围配置，把原本应该覆盖整个屏幕的触摸区域，算成了只有半屏。
关键点是设备和驱动的坐标范围配置没对齐。只要把触摸相关的分辨率配置修正到和实际屏幕一致，问题就消失了。这个案例提醒我们，触摸不灵不一定是硬件坏了，软件层的坐标范围配置搞错也会一模一样。
8. 源码阅读路径：把这套体系吃进去的路子
想深入理解Android输入子系统，直接去翻源码是最快也是最慢的路。我建议不要从framework层开始，而是按下面的顺序往下啃：
- frameworks/native/services/inputflinger/reader/InputReader.cpp：看事件读取和转换
- frameworks/native/services/inputflinger/dispatcher/InputDispatcher.cpp：看事件派发策略
- frameworks/base/services/core/java/com/android/server/input/InputManagerService.java：理解Java侧怎么管理上面两个native组件
- frameworks/base/core/java/android/view/ViewRootImpl.java：从应用侧回望事件接收的处理
- frameworks/base/core/java/android/view/ViewGroup.java：理解View树的事件分发
如果你是从应用开发转过来看这套源码的，刚开始容易被C++代码劝退，建议先抓住几个关键的接口和数据流。InputReader和InputDispatcher之间的交互在Native层完成，但它们都受InputManagerService控制，节点间的牵线是理解整个架构的钥匙。
另外特别提醒一下，不同Android版本的目录组织发生了不小的变化，特别是Android 13以后，把inputflinger拆分成了reader和dispatcher两个目录。如果照着旧版本的路径找文件，会很迷惑。遇到找不着文件的情况，先确认版本号再决定要不要换个分支。
9. 几点经验总结
做输入子系统相关的开发调试，我这几年的体会有几条特别深：
第一，优先确认事件有没有到目标窗口。很多看起来是View层分发的问题，其实根本没走到View层。用dumpsys input加getevent这套组合拳，基本能在五分钟内定位到事件在哪个环节断掉了。
第二，事件序列的完整性至关重要。做自定义View处理触摸逻辑时，永远要把ACTION_CANCEL当回事。系统在动画打断、窗口切换时会下发CANCEL事件，处理不好这个事件，应用就会出现“按钮卡住按不下去”的bug。
第三，多点触控的坑远比单点触控多。每个触点都有自己的tracking id，匹配错位会导致触摸错乱。排查这类问题，手工在getevent里盯原始数据是最快的路子。
第四，改动系统级输入逻辑时，务必考虑兼容性。同一条路径在横竖屏切换、分屏、无障碍模式下的行为完全不同。很多在标准流程下没问题的改动，一放进特殊使用场景就崩了。
这条技术路线的门槛确实不低，但一旦掌握，整个Android系统的运行机理在你的脑子里都会清晰一大截。输入子系统是离用户最近、也最容易出体感问题的一块，值得投入时间吃透。
