硬件层面排查：触摸屏采样率、触摸控制器处理延迟、硬件中断优先级

好，咱们进入硬件层面。说实话，软件写得再漂亮，硬件底子不行，延迟照样扛不住。我见过太多团队，花了几周优化算法，结果一查，触摸屏采样率才 60Hz，那再怎么折腾也是白费。

硬件排查，说白了就是三件事：采样率够不够快、控制器处理有没有拖后腿、中断有没有被别的任务堵住。咱们一个一个来。

采样率，就是触摸屏每秒上报多少次触摸数据。单位是 Hz。比如 120Hz，就是每秒 120 次，约 8.3ms 一次。

为什么这个重要？你想想看，用户手指从 A 点滑到 B 点，如果采样率低，中间的点就少，系统只能靠插值去猜。猜对了还好，猜错了，延迟感就出来了。

经验值参考：

我在项目中遇到过一款平板，标称 120Hz 屏，结果实际采样率只有 60Hz。为什么？驱动里配错了定时器参数。查了两天才发现，你说冤不冤。

排查方法：

用示波器抓触摸屏的中断引脚，看两次中断之间的时间间隔。或者用 getevent 工具，在 Android 上直接看事件时间戳。如果间隔不均匀，说明采样时钟不稳定。

采样率只是第一步。触摸控制器拿到原始电容数据后，还要做滤波、去抖、坐标计算、手势识别。这一套下来，时间就花出去了。

我拆过几款主流的触摸控制器芯片，比如 Synaptics、Goodix、Cypress。它们的处理流程大致是这样的：

原始电容数据 → 基线校准 → 噪声滤波 → 触摸检测 → 坐标计算 → 手势识别 → 上报

每一步都有延迟。尤其是噪声滤波，如果环境干扰大，滤波器阶数就得提高，延迟就上去了。

你看，光控制器内部就吃掉 4-14ms。再加上采样间隔、总线传输、中断响应，轻松上 20ms。

注意：有些控制器支持「低延迟模式」，会跳过部分滤波步骤。但代价是噪声容忍度下降。我建议只在游戏场景下开启，日常使用还是保留滤波，不然误触率会飙升。

好，采样率和控制器都查完了，数据已经出来了。接下来就是中断——触摸控制器通过中断告诉 CPU：「我有新数据了，快来拿！」

问题来了：如果中断优先级设低了，CPU 正在处理别的任务（比如刷屏、解码音频），触摸中断就得排队。这一排，可能就是几毫秒甚至十几毫秒。

我曾经在一个项目里遇到过：触摸偶尔卡顿，查了三天，最后发现是蓝牙中断优先级比触摸高。蓝牙每 7.5ms 来一次中断，每次处理 2ms，触摸中断就被挤到后面去了。改完优先级，问题立刻消失。

中断优先级排查清单：

嗯，这里要注意：中断优先级不是越高越好。如果把触摸中断设成最高，其他关键任务（比如看门狗、电源管理）可能会被饿死。我一般建议设成次高，留一个给系统安全。

咱们把上面三个环节串起来，画张图你就清楚了。

2.8-16.7ms 控制器处理
4-14ms 中断响应
0-10ms 总硬件延迟 ≈ 7-41ms（取决于配置）每个环节都是瓶颈。采样率低 → 丢点；控制器慢 → 延迟；中断被抢 → 抖动

光说不练假把式。我给你一套我常用的排查流程：

一个小技巧：我习惯在触摸 ISR 里加一个计数器，每 1000 次中断打印一次时间戳。如果时间戳间隔不均匀，说明中断响应不稳定。这个方法不需要示波器，纯软件就能排查。

最后，分享几个我踩过的坑：

硬件排查，说白了就是拿数据说话。别猜，用示波器看，用寄存器读，用计数器量。数据不会骗人。