Android Input事件分发全链路解析：从硬件中断到View onTouchEvent

1. 这不是“点一下屏幕就响应”的简单事：Input事件分发到底在干啥

你有没有试过在Android设备上连续快速点击同一个按钮，结果只触发了一次点击？或者在滑动列表时，手指刚抬起来，列表却还在惯性滚动——这个“余韵”是谁在维持？又或者，你在开发一个自定义View时发现，onTouchEvent()里明明收到了ACTION_DOWN，但后续的ACTION_MOVE却石沉大海？这些现象背后，都绕不开一个被无数开发者口头提起、却极少有人真正拆开看过的黑箱：Android系统服务中的Input事件分发过程。

这不是应用层onClick回调那种“封装好的甜点”，而是从硬件中断信号出发，穿越Linux内核驱动、HAL层、Native服务、Java框架，最终落到你写的Activity或View上的一整条“事件高速公路”。它横跨用户空间与内核空间，牵涉InputManagerService（IMS）、WindowManagerService（WMS）、ViewRootImpl、Choreographer等多个核心组件，任何一个环节卡顿或配置错误，都会导致触摸失灵、响应延迟、手势冲突等“玄学问题”。

我做过不下二十个涉及手势识别、多点触控、输入法拦截、无障碍服务联动的项目，几乎每个都踩过Input分发的坑。比如某次为某高校实验室开发一款教育类手写板App，要求支持毫秒级笔迹追踪和压感模拟，结果在中低端机型上频繁出现“断笔”——不是代码逻辑问题，而是Input事件在IMS到ViewRootImpl的传递链路上被批量丢弃了。后来花三天时间把整个Input路径从/dev/input/eventX设备节点开始逆向梳理，才定位到是InputReader线程的缓冲区大小设置不合理，加上主线程绘制卡顿，共同导致事件积压后被强制裁剪。

所以这篇内容，不讲API怎么调用，不贴几行onTouch代码完事。我们要做的，是像拆解一台精密钟表一样，把Input事件从按下屏幕那一刻起，每一步经过哪个齿轮、哪个游丝、哪个擒纵机构，全部摊开来看。你会看到：为什么一次触摸会产生多个InputEvent对象；为什么WMS要参与事件分发，它到底“管”什么；ViewGroup的dispatchTouchEvent()和IMS之间隔着几道墙；以及最关键的——当你的onInterceptTouchEvent()返回true时，系统底层究竟发生了什么物理层面的变化。这不仅是面试高频题，更是你写出稳定、流畅、可预测交互体验的底层能力基石。

2. 整体设计思路：一条贯穿内核到UI的“事件流水线”

2.1 为什么不能让应用直接读取/dev/input/eventX？

这是理解整个设计逻辑的起点。很多初学者会想：既然触摸数据来自硬件，那App自己打开/dev/input/eventX文件，用epoll监听不就完了？省去所有中间环节，岂不更高效？这个想法很朴素，但恰恰暴露了对操作系统安全模型和资源调度机制的根本误解。

Android是一个多任务、多用户、强隔离的操作系统。/dev/input/eventX是Linux内核暴露给用户空间的字符设备，任何进程只要获得权限，理论上都能open()并read()它。如果每个App都直接读取，会出现三个致命问题：

第一是事件竞争与丢失。假设App A和App B同时监听同一个eventX设备，内核read()操作是不可重入的——一次read()调用会消耗掉缓冲区中的一批事件。A读走了一组包含ACTION_DOWN+ACTION_MOVE的事件，B再read时可能只拿到ACTION_UP，或者干脆阻塞等待。这会导致两个App的触摸逻辑全部错乱。

第二是权限失控与安全风险。直接访问input设备意味着App能捕获所有物理按键（电源键、音量键）、传感器数据（陀螺仪、加速度计），甚至USB外设输入。这完全绕过了Android的Permission机制，等于给了App“上帝视角”。试想一个恶意App通过监听电源键事件，在用户锁屏瞬间偷偷唤醒屏幕并截取密码输入——这种攻击面是系统级不可接受的。

第三是调度失序与性能灾难。input事件是高频、低延迟的硬实时信号。一次120Hz屏幕刷新率下的滑动，每秒可能产生上百个MotionEvent。如果每个App都独立轮询或epoll监听，CPU将被大量无意义的系统调用和上下文切换拖垮。更严重的是，事件处理必须与UI渲染严格同步（VSync），否则就会出现“触摸已发生，画面还没更新”的撕裂感。而App层根本无法协调自己的渲染节奏与系统VSync信号。

因此，Android的设计哲学是：由系统级服务统一接管硬件输入，做集中采集、过滤、路由与调度，再按需、按权、按时序分发给目标应用。这个“统一分发者”，就是InputManagerService（IMS）。

2.2 IMS不是单线程，而是一套协同工作的“三驾马车”

很多人以为IMS就是一个Java类，运行在SystemServer进程中。实际上，IMS的实现是典型的分层架构，由三个关键模块组成，它们运行在不同线程、不同地址空间，通过共享内存和Binder高效协作：

• InputReader：运行在Native层，一个独立的C++线程。它负责最底层的设备读取。它会扫描/sys/class/input/目录，找到所有可用的input设备（如event0对应触摸屏，event1对应按键），然后用非阻塞方式持续read()这些设备节点。读到原始字节流后，它根据Linux input protocol规范（evdev）解析成标准化的RawEvent结构（含type、code、value、when等字段），再转换为InputEvent对象（KeyEvent或MotionEvent）。这个过程不涉及任何业务逻辑，纯数据搬运与格式转换。

• InputDispatcher：同样运行在Native层，另一个独立C++线程。它是真正的“分发大脑”。InputReader将打包好的InputEvent队列，通过一个名为mInboundQueue的无锁环形缓冲区（RingBuffer）交给InputDispatcher。Dispatcher的任务是：确定这个事件该发给谁？以什么顺序？要不要拦截？它会查询WMS维护的窗口堆栈（WindowStack），根据事件坐标（x,y）计算出当前位于焦点的窗口（Window），再通过Binder调用该窗口所属应用的InputChannel，将事件投递过去。注意，Dispatcher本身不执行任何UI操作，它只做决策和投递。

• InputManagerService（Java层）：这才是我们在ActivityManager或WMS文档里看到的那个“IMS”。它运行在SystemServer的Java主线程中，主要职责是对外提供Binder接口，供WMS、AMS等系统服务进行配置和查询。比如WMS在添加新窗口时，会调用IMS的registerInputChannel()方法，把该窗口的InputChannel（一对SocketPair）注册进来；AMS在应用切后台时，会调用setInputWindows()通知IMS更新窗口焦点状态。Java层IMS本身不处理事件，它只是Native层InputReader/Dispatcher的“前台接待员”和“政策制定者”。

这三者的关系，可以类比为一家快递公司：InputReader是“仓库分拣员”，把全国各地寄来的包裹（原始input数据）按标准格式打包成快件（InputEvent）；InputDispatcher是“智能调度中心”，根据收件人地址（窗口坐标）和实时路况（窗口Z-order、焦点状态），规划最优派送路线，并呼叫快递员（Binder调用）；而Java层IMS则是“总部客服”，负责跟各大商场（WMS）、物业（AMS）签合同、改派送规则、查物流状态，但绝不亲手搬箱子。

2.3 事件分发的“双通道”模型：焦点通道 vs. 触摸通道

IMS的分发逻辑并非“一刀切”，而是根据事件类型采用两种截然不同的策略，这直接决定了你日常开发中遇到的绝大多数“为什么没收到事件”的问题根源。

• 焦点通道（Focus Channel）：专用于键盘、方向键、轨迹球等需要焦点的输入设备。它的核心原则是“谁有焦点，谁收事件”。当用户按下方向键，IMS会首先查询当前拥有Input Focus的窗口（通常是EditText或可聚焦的View），然后将KeyEvent直接发给它。这个过程不依赖坐标，纯粹基于焦点管理。这也是为什么你在ListView里按方向键，焦点会在item间跳转，而不是触发onTouchEvent()。

• 触摸通道（Touch Channel）：专用于触摸屏、触控笔等基于坐标的输入设备。它的核心原则是“谁在上面，谁先收”。IMS会根据MotionEvent的x,y坐标，结合WMS提供的窗口布局信息（包括窗口位置、大小、透明度、是否可触摸），从顶层窗口开始逐层向下遍历，找到第一个满足isTouchable()且坐标落在其Bounds内的窗口。这个窗口就是事件的“初始目标”。但请注意，这仅仅是“初始”目标——后续是否真的由它处理，还要经过View体系的层层拦截与分发。

这个“双通道”设计解释了为什么同一个Activity里，EditText能响应键盘输入（焦点通道），而自定义ViewGroup能响应滑动（触摸通道），两者互不干扰。也解释了为什么当你用无障碍服务强制修改窗口焦点时，键盘事件会突然发给一个不该接收的View——你动了焦点通道的开关，但没动触摸通道的坐标映射。

更重要的是，触摸通道的分发是“广播式”的，而非“点对点”的。IMS不会把一个MotionEvent只发给一个View。它只会发给目标窗口的ViewRootImpl，然后由ViewRootImpl启动View树的dispatchTouchEvent()流程，这个流程本身就是一个内部的、递归的“子通道分发”。IMS只管“送到门口”，进门后怎么分，是View体系自己的事。这也是为什么你在onInterceptTouchEvent()里return true，只是告诉父View“我要截胡”，并不影响IMS之前已经做出的“送哪家”的决定。

3. 核心细节解析：从硬件中断到View.onTouchEvent的七步穿透

3.1 第一步：硬件中断与内核驱动（Linux Kernel Layer）

一切始于物理世界。当你用手指触碰电容屏，屏幕控制器检测到电容变化，生成一个硬件中断信号（IRQ），CPU暂停当前任务，跳转到中断处理程序。这个程序属于Linux内核的Input子系统，它会读取控制器寄存器，获取原始坐标（x,y）、压力值（pressure）、触点ID（pointerId）等数据，并将其封装成一个struct input_event结构体。

这个结构体被写入内核为该设备创建的/dev/input/eventX字符设备缓冲区。关键点在于：这个缓冲区是环形的（circular buffer），有固定大小（通常4KB）。如果应用层读取太慢，新事件会覆盖旧事件，造成丢帧。这也是为什么高刷屏设备上，如果InputReader线程被长时间阻塞（比如做了耗时JNI调用），就会出现“触摸跟手性差”的根本原因——不是CPU不够快，而是事件在内核缓冲区就被物理丢弃了。

你可以用getevent -l命令在adb shell中实时观察这个过程：

$ adb shell getevent -l add device 1: /dev/input/event0 name: "ft5436_ts" /dev/input/event0: 0003 0039 00000000 # ABS_MT_TRACKING_ID, 新触点ID=0 /dev/input/event0: 0003 0035 000001a0 # ABS_MT_POSITION_X, x=416 /dev/input/event0: 0003 0036 00000258 # ABS_MT_POSITION_Y, y=600 /dev/input/event0: 0003 0018 00000032 # ABS_MT_PRESSURE, pressure=50 /dev/input/event0: 0000 0000 00000000 # SYN_REPORT, 本次事件包结束

每一行代表一个input_event，最后的SYN_REPORT是同步标记，表示这一组关联事件（一个触点的x,y,pressure）已发送完毕。InputReader正是监听这个SYN_REPORT来判断一个完整MotionEvent是否就绪。

3.2 第二步：InputReader线程解析与批处理（Native Layer）

InputReader运行在一个高优先级的SCHED_FIFO线程中，确保它能及时响应内核事件。它的主循环非常精简：

while (running) { // 1. 从所有已注册的eventX设备read()原始数据 size_t eventCount = mEventHub->getEvents(...); // 2. 解析raw events，生成InputEvent对象 for (size_t i = 0; i < eventCount; i++) { processEvent(&mEventHub->getEventItem(i)); } // 3. 将生成的InputEvent批量推入mInboundQueue mQueues[mCurrentQueue].pushEvents(mEventBuffer, count); }

这里有两个关键优化点：

• 批处理（Batching）：InputReader不会为每一个SYN_REPORT就立刻生成一个InputEvent。它会等待一小段时间（默认5ms），把这段时间内到达的所有SYN_REPORT打包成一个“事件批”（Batch）。这样做的好处是减少InputDispatcher的调度次数，提升吞吐量。坏处是引入了微小的延迟（最多5ms），但对于120Hz屏幕，这个延迟远小于一帧（8.3ms），是可接受的权衡。

• 触点聚合（Pointer Aggregation）：对于多点触控，内核会为每个触点单独发送一组input_event。InputReader会将同一时间戳（when字段）下的所有触点，聚合成一个MotionEvent对象，其中包含pointerCount、pointerProperties[]、pointerCoords[]等数组。这就是为什么你在onTouchEvent()里能通过getPointerCount()拿到当前有几个手指。

提示：如果你的应用对延迟极度敏感（如专业绘图App），可以通过adb shell setprop debug.input.maxBatchSize 1强制禁用批处理，让每个SYN_REPORT都立即生成一个事件。但这会显著增加CPU负载，务必在真机上实测功耗影响。

3.3 第三步：InputDispatcher决策与窗口查找（Native Layer）

InputDispatcher从mInboundQueue中取出InputEvent后，进入最复杂的决策阶段。它要解决的核心问题是：“这个事件，应该发给哪个窗口？”

答案藏在WMS的窗口管理数据结构中。WMS维护着一个全局的WindowList，按Z-order（深度）排序。Dispatcher会执行以下步骤：

1. 坐标归一化：将原始屏幕坐标（x,y）减去窗口的mFrame.left/top，得到相对于该窗口左上角的坐标（localX, localY）。

2. 窗口筛选：遍历WindowList，对每个窗口w检查：

   • w.mHasSurface && w.mReadyToDisplay：窗口是否有有效的Surface且已准备好显示。
   • w.mTouchable：窗口是否设置了FLAG_NOT_TOUCHABLE。
   • w.mInputChannel != null：窗口是否已向IMS注册了InputChannel。
   • (localX, localY)是否在w.mFrame矩形内。

3. 焦点窗口优先：如果事件是KEY_EVENT，Dispatcher会直接选择mCurrentFocus窗口，跳过坐标计算。

4. 触摸窗口选择：对于MOTION_EVENT，Dispatcher会选择第一个通过筛选的窗口（即Z-order最高的那个）。这就是为什么Dialog总是能拦截背后的Activity触摸——它的Z-order更高。

这个过程看似简单，但实际非常耗时，尤其是当窗口树很深、有很多半透明或动画窗口时。为了加速，WMS会为每个窗口维护一个mTouchableRegion（可触摸区域），这是一个经过裁剪的Path，包含了窗口的实际可交互轮廓（考虑了圆角、阴影、clipPath等）。Dispatcher只需用Region.contains(x,y)就能快速判断，无需每次都做复杂的几何计算。

3.4 第四步：Binder跨进程投递与InputChannel通信（IPC Layer）

一旦Dispatcher确定了目标窗口w，它就需要把InputEvent“送过去”。但w的ViewRootImpl运行在应用进程（如pid 12345），而Dispatcher运行在SystemServer进程（pid 1000）。跨进程通信，只能靠Binder。

这里的关键载体是InputChannel。它本质上是一对用socketpair()创建的Unix Domain Socket，一端在SystemServer（ServerChannel），另一端在应用进程（ClientChannel）。WMS在addWindow()时，会创建这对Socket，并通过Binder将ClientChannel的文件描述符（fd）传递给应用进程。应用进程的ViewRootImpl拿到这个fd后，会用epoll监听它。

Dispatcher的投递动作，就是把InputEvent序列化成Parcel，然后write()到ServerChannel的fd里。内核会自动把数据转发到ClientChannel的fd。应用进程的InputEventReceiver（一个HandlerThread）会通过epoll_wait()检测到fd可读，然后read()数据，反序列化成Java层的InputEvent对象。

这个过程的延迟，是整个链条中除内核缓冲区外的第二大瓶颈。实测表明，在中低端设备上，一次Binder调用平均耗时0.3~0.5ms。如果一个滑动事件包含10个MotionEvent，光是跨进程传输就可能占用5ms，接近一帧时间。这也是为什么Google在Android 12+大力推广InputStage机制，允许部分事件（如ACTION_HOVER_MOVE）在Native层就地处理，避免不必要的Binder穿越。

3.5 第五步：ViewRootImpl.dispatchInputEvent与Choreographer协同（Framework Layer）

InputEventReceiver将事件交给ViewRootImpl后，事情并没有结束。ViewRootImpl要做两件至关重要的事：

• VSync对齐：它不会立刻调用View.dispatchTouchEvent()。而是将事件放入一个QueuedInputEvent队列，然后请求Choreographer在下一个VSync信号到来时执行分发。这是为了保证“事件处理”与“UI绘制”严格同步。想象一下，如果onTouchEvent()里修改了View的宽度，而绘制线程正在用旧的宽度画图，就会出现闪烁或错位。VSync对齐是Android实现60fps/120fps流畅动画的基石。

• 事件预处理：在VSync回调中，ViewRootImpl会先调用mAttachInfo.mTreeObserver.dispatchOnPreDraw()等生命周期回调，确保View树状态最新，然后再启动View.dispatchTouchEvent()。

这个VSync对齐的过程，可以用adb shell dumpsys gfxinfo <package>查看。在输出的Janky frames统计中，如果Input handling一项占比很高，说明你的事件分发逻辑（如过于复杂的onInterceptTouchEvent）正在拖慢主线程，导致无法在VSync周期内完成。

3.6 第六步：View树的递归分发与拦截（View Layer）

现在，事件终于来到了你最熟悉的领域：ViewGroup.dispatchTouchEvent()。但请记住，这已经是整个链条的第六步，前面五步的任何失败，都会让你根本收不到这个方法的调用。

dispatchTouchEvent()的标准流程是：

public boolean dispatchTouchEvent(MotionEvent event) { // 1. 如果设置了OnTouchListener且返回true，则直接消费，不走onTouchEvent if (mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && mOnTouchListener.onTouch(this, event)) { return true; } // 2. 否则，调用onTouchEvent，由View自己决定 return onTouchEvent(event); }

而对于ViewGroup，它还多了onInterceptTouchEvent()：

public boolean dispatchTouchEvent(MotionEvent ev) { // 1. 先询问自己要不要拦截 if (onInterceptTouchEvent(ev)) { // 拦截了，后续事件（MOVE/UP）都发给自己，不往下传 return onTouchEvent(ev); } else { // 不拦截，把事件分发给子View return super.dispatchTouchEvent(ev); // 即调用子View的dispatch } }

这里有一个极易被误解的点：onInterceptTouchEvent()的调用时机。它只在ACTION_DOWN时被调用一次。如果返回false，那么对于后续的ACTION_MOVE，dispatchTouchEvent()会直接调用super.dispatchTouchEvent()，而不会再问一遍“要不要拦截”。这意味着，一旦你决定不拦截DOWN，你就放弃了对这次触摸序列的控制权，MOVE和UP事件将永远无法再被你的onInterceptTouchEvent()捕获。

所以，正确的做法是：在DOWN时，根据初始坐标和速度，预判这次手势大概率是什么（点击？长按？滑动？），然后决定是否拦截。如果预判是滑动，就立刻拦截，把MOVE全收下；如果预判是点击，就不拦截，让子View处理，但要在onTouchEvent()里监听MOVE的距离，一旦超过ViewConfiguration.getScaledTouchSlop()，就立刻getParent().requestDisallowInterceptTouchEvent(true)，通知父View“别拦了，我要自己处理滑动”。

3.7 第七步：事件终结与状态重置（Lifecycle Layer）

一个触摸序列（Touch Sequence）的终结，并非以ACTION_UP为唯一标志。IMS和View体系有一套严格的“事件生命周期”管理：

• 序列开始：以ACTION_DOWN为标志。IMS会为这个触点分配一个唯一的pointerId，并记录其初始坐标。ViewRootImpl会创建一个TouchTarget链表，记录当前正在处理该触点的View。

• 序列进行：ACTION_MOVE事件会携带相同的pointerId，IMS确保它们被发往同一个窗口。View体系则通过TouchTarget链表，确保所有MOVE都发给最初接收DOWN的那个View，即使手指滑出了它的Bounds（这是为了保证手势连贯性）。

• 序列结束：以ACTION_UP或ACTION_CANCEL为标志。ACTION_UP表示用户主动抬起手指；ACTION_CANCEL则表示系统强制中断，常见于：

  • 窗口被销毁（如Activity finish）
  • 窗口失去焦点（如弹出Dialog）
  • 系统资源紧张，需要回收InputChannel

当收到CANCEL时，View体系会清空TouchTarget链表，并向所有相关的View发送一个特殊的ACTION_CANCEL事件。这个事件的getActionMasked()返回MotionEvent.ACTION_CANCEL，getActionIndex()为-1。这是你必须处理的信号。如果你在onTouchEvent()里只处理DOWN/MOVE/UP，而忽略了CANCEL，那么当用户在你的自定义View上按下，然后突然切到其他App，你的View内部状态（如isDragging = true）就会永远卡住，导致后续所有交互失效。

注意：ACTION_CANCEL是View体系的“软中断”，它不等于IMS停止发送事件。IMS依然会继续把后续的MOVE/UP发过来，但ViewRootImpl在收到CANCEL后，会忽略所有后续事件，直到下一个ACTION_DOWN。所以，你的onTouchEvent()必须在收到CANCEL时，彻底重置所有与本次触摸相关的状态变量。

4. 实操过程：如何用工具链精准定位Input分发瓶颈

4.1 工具链全景：从内核到Java的四层观测点

要真正掌握Input分发，光看源码是不够的，必须建立一套完整的、可落地的观测工具链。我把它分为四个层次，对应分发路径的四个关键节点：

观测层	工具	观测目标	典型问题
内核层	getevent,cat /proc/interrupts	/dev/input/eventX原始数据流、中断频率	设备驱动bug、硬件抖动、事件丢帧
Native层	adb shell dumpsys input	InputReader/Dispatcher状态、队列长度、丢弃计数	Reader线程卡死、Dispatcher调度延迟、窗口查找失败
IPC层	systrace -a <package> -b 10240 input	Binder调用耗时、InputChannel读写延迟	跨进程通信瓶颈、应用进程InputChannel fd泄漏
Framework层	adb shell dumpsys gfxinfo <package>,Layout Inspector	View.dispatchTouchEvent耗时、Choreographer VSync偏差	onInterceptTouchEvent逻辑过重、onTouchEvent里做耗时操作

这套工具链不是摆设，而是我在某跨平台系统项目中，为解决“游戏手柄映射延迟”问题，花了两周时间打磨出来的。下面我会详细展开每个工具的实战用法。

4.2 内核层诊断：用getevent和interrupts锁定硬件问题

getevent是最直接的“听诊器”。在怀疑是硬件或驱动问题时（如触摸不灵敏、误触发），执行：

# 查看所有input设备及其名称 adb shell getevent -p # 监听指定设备（如event0），并解析为人类可读格式 adb shell getevent -l /dev/input/event0 # 录制10秒事件流到文件，便于离线分析 adb shell "getevent -t /dev/input/event0 | head -n 1000" > event_log.txt

重点观察：

• SYN_REPORT的间隔是否稳定。理想情况下，120Hz屏幕应为8.3ms间隔。如果出现大量>20ms的间隔，说明硬件上报不及时。
• 是否有异常的ABS_MT_DISTANCE或ABS_MT_TOOL_TYPE事件，这可能是屏幕边缘误触或手套模式干扰。
• BTN_TOUCH的up/down是否成对出现。如果只有DOWN没有UP，说明硬件释放信号丢失。

更深层的问题，要看中断。执行：

adb shell cat /proc/interrupts | grep -i "input\|touch\|ft5\|gt9"

输出类似：

123: 12456789 ARM-PL190 12 Level ft5436_ts

数字12456789是该中断被触发的总次数。在设备静止时，这个数字应该几乎不变。如果它在狂涨，说明触摸IC在持续发送虚假中断，是典型的硬件老化或静电干扰。

实操心得：有一次，某款平板在低温环境下触摸失灵。用getevent发现SYN_REPORT间隔从8ms暴涨到50ms。进一步用cat /proc/interrupts发现中断计数停滞。最终确认是触摸IC的晶振在低温下频率漂移，导致内核驱动无法正确解析时序。这个问题只能靠厂商固件升级解决，但getevent帮我们把问题精准定位到了硬件层，避免了在App层做无谓的优化。

4.3 Native层诊断：dumpsys input的隐藏参数

adb shell dumpsys input是分析IMS状态的瑞士军刀，但它的输出信息量巨大，需要知道怎么看重点。执行后，重点关注三个Section：

• Input Reader State：显示InputReader线程的健康状况。

  Input Reader State: Device 0: ft5436_ts Configuration: ... Events: 12456789 (since boot) Last event time: 1234567890 ms Batch size: 5 (max 10)

  Last event time如果远大于当前系统时间（adb shell date +%s%3N），说明InputReader线程已卡死。Batch size如果长期为1，说明批处理被禁用或设备上报频率极低。

• Input Dispatcher State：这是核心，看队列和丢弃。

  Input Dispatcher State: Dispatch latency: 0.000 ms (avg), 12.345 ms (max) Inbound queue length: 0 Outbound queue length: 0 Dropped events: 0 Failed to find focus: 0

  Dispatch latency是Dispatcher处理一个事件的平均耗时，超过1ms就要警惕。Inbound queue length如果持续>0，说明InputReader送得太快，Dispatcher来不及处理。Dropped events非零，说明事件在Dispatcher内部被主动丢弃（如窗口不存在），这是严重的逻辑错误信号。

• Windows：列出所有已注册的窗口及其状态。

  Window 12345678: com.example.app/com.example.MainActivity Input channel: 12345678-abcde (registered) Focus: true Touchable: true Frame: [0,0][1080,2220]

  检查你的目标Activity是否在列表中，Focus和Touchable是否为true。如果为false，说明WMS认为这个窗口不应该接收触摸，常见原因是WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE被错误设置。

提示：dumpsys input默认只显示摘要。要查看完整详情，加-h参数：

adb shell dumpsys input -h # 输出所有可用选项，如 -p 显示详细设备信息，-v 显示详细队列 adb shell dumpsys input -v

4.4 IPC层诊断：Systrace抓取Binder调用火焰图

Binder调用是跨进程的“黑箱”，dumpsys只能看到结果，看不到过程。这时，systrace就是你的X光机。录制命令：

# 启用input和binder标签，录制10秒 systrace.py -a com.example.app -b 10240 -t 10 sched freq input binder gfx wm am # 或者用更简洁的adb命令（Android 10+） adb shell "atrace -b 10240 -t 10 sched freq input binder gfx wm am" > trace.dat

然后用Chrome浏览器打开chrome://tracing，加载trace.dat。

在火焰图中，找到InputDispatcher和InputEventReceiver的轨道：

• InputDispatcher::dispatchOnce：这是Dispatcher的主循环，它的耗时应该<0.5ms。如果拉得很长，说明Dispatcher线程被阻塞。
• binder transaction：这是Binder调用本身。点击它，可以看到target process（目标进程名）和transaction code（通常是INPUT_DISPATCH）。
• InputEventReceiver::onInputEvent：这是应用进程收到事件后的第一个Java方法。它的耗时，就是Binder传输+反序列化的总时间。

通过对比InputDispatcher::dispatchOnce的结束时间和InputEventReceiver::onInputEvent的开始时间，你能精确计算出Binder延迟。如果这个延迟>1ms，且binder transaction本身耗时很短（<0.2ms），那问题很可能出在目标进程的InputEventReceiver线程被其他任务抢占了。

实操心得：在优化某款直播App的弹幕手势时，我们发现滑动延迟高达80ms。用systrace一看，InputEventReceiver::onInputEvent的调用，总是在Choreographer#doFrame之后才发生。原来是因为Choreographer的Callback队列里，有一个耗时20ms的Runnable，把整个主线程占满了。InputEventReceiver虽然是HandlerThread，但它提交的onInputEvent任务，是发给主线程Handler的。所以，任何阻塞主线程的操作，都会间接拖慢Input事件的分发。这个教训，让我从此养成了在Handler.post()前，先用Looper.myQueue().isPolling()检查主线程是否空闲的习惯。

4.5 Framework层诊断：gfxinfo与Layout Inspector双剑合璧

dumpsys gfxinfo是分析UI线程性能的利器。执行：

adb shell dumpsys gfxinfo com.example.app reset # 先重置统计 # 让用户操作一段时间（如快速滑动列表10次） adb shell dumpsys gfxinfo com.example.app

在输出中，找到Profile data in ms:部分，重点关注：

• Draw：onDraw()耗时，超过16ms（60fps）就是Jank。
• Process：ViewRootImpl处理Input事件的耗时，即dispatchInputEvent到deliverInputEvent的时间。
• Execute：Choreographer执行Callback的耗时，包括onTouchEvent()的执行。

如果Process项耗时很高，说明你的onInterceptTouchEvent()或onTouchEvent()里做了太多事。这时，配合Layout Inspector（Android Studio自带），可以实时查看View树：

• 打开Layout Inspector，选择你的App进程。
• 在Component Tree中，右键点击某个View，选择Jump to Source，直接跳到onTouchEvent()的代码。
• 在代码中，对可疑的耗时操作（如Bitmap.createBitmap()、new JSONObject()）打上Debug.startMethodTracing("touch")，再用Traceview分析。

常见问题速查表：

现象	可能原因	排查命令/工具
完全收不到onTouchEvent()	Activity未获得焦点；Window设置了FLAG_NOT_TOUCHABLE；InputChannel未注册	dumpsys input查Windows；adb shell dumpsys window windows | grep -A 5 mCurrentFocus
收到DOWN，但收不到MOVE/UP	onInterceptTouchEvent()在DOWN时返回true，但onTouchEvent()没处理MOVE；或requestDisallowInterceptTouchEvent(false)被误调用	systrace查InputEventReceiver是否收到MOVE；Logcat过滤ViewRootImpl关键字
滑动卡顿，响应迟钝	Process耗时>16ms；ChoreographerVSync偏差大；onTouchEvent()里做了耗时IO	dumpsys gfxinfo；systrace查Choreographer#doFrame；Android Profiler查CPU热点
手势冲突（如ScrollView里嵌套RecyclerView，滑动时两者都动）	父View的onInterceptTouchEvent()未正确判断滑动方向；子View未调用getParent().requestDisallowInterceptTouchEvent(true)	Layout Inspector查View层级；在onInterceptTouchEvent()里Log.d打印getScrollY()和event.getY()

5. 常见问题与排查技巧实录：那些年踩过的坑

5.1 “我的View明明在屏幕上，为什么收不到触摸事件？”——焦点与窗口状态的迷雾

这是新手最常问的问题。表面看，你的ViewsetVisibility(View.VISIBLE)，`