触摸屏测试
尚未检测到触摸屏
你的浏览器没有报告支持触摸的指针。如果该设备确实有触摸屏，一些浏览器只有在你真正触摸屏幕的那一刻才会显示出来。
试着点按上方的方框 —— 即使浏览器自身的能力检测漏掉了，真实的触摸依然会被检测到。
用一根或多根手指在上方方框内点按、滑动并长按。
已触摸 16 格中的 0 格
覆盖整个屏幕,而不仅仅是上方的方框——这是触及面板真实边缘的唯一方式。
浏览器报告的信息
- 最大同时触点数(声明值)
- —
- 检测到触摸输入
- —
- 是否暴露子帧触摸采样
- —
同时触摸数
最多同时 0 个
用一根或多根手指触摸该区域即可测量此项。
触点详情
压力
触摸该区域以测量此项。
触点大小
触摸该区域以测量此项。
触控笔倾斜与旋转
尚未检测到触控笔(笔型)接触。
静止稳定性
将一根手指尽量静止地按在区域上，然后点击开始。
幽灵触摸
请在约 20 秒内不要触摸屏幕，然后点击开始。
触摸报告频率
将一根手指按在区域上并缓慢移动，然后点击开始。
总结
- 已检测到触摸屏
- 多点触控符合声明
- 区域的每个部分都能记录触摸
- 按住的触摸保持稳定
- 未触摸时没有虚假触摸
- 报告真实压力或触点大小
- 没有因手势拦截而丢失触摸
大多数触摸屏测试工具只显示一个可点击的网格，就称之为“测试”。这个工具测量的是单靠网格无法显示的内容——你的浏览器是否真的能同时识别一根以上的手指，静止不动的手指是否会自行漂移，屏幕在完全没有触碰时是否会记录幽灵触摸，以及浏览器是否暴露真实的压力或接触面积数据。本工具有意拒绝猜测两件事：以毫秒为单位的触摸延迟(没有任何网页 API 会记录手指实际触碰玻璃的确切瞬间)，以及以毫米为单位的校准精度(没有任何 API 会报告屏幕的真实物理尺寸)。这两点在本页都会得到诚实的解释，而不是编造出来的数字。
工作原理
- 触摸测试区域. 用一根或多根手指在方框上点按、滑动并长按。每被触摸过的格子都会亮起，进度提示会显示你已覆盖了多少区域。
- 切换到全屏扫描以覆盖真实边缘. 内嵌方框只能覆盖页面本身占据的区域。切换到全屏扫描,即可触及屏幕的真实边缘,而不仅仅是这个方框——退出后,上一次的全屏扫描结果仍会保留。
- 同时尝试多根手指. 同时将两根或更多手指放在区域上，看看浏览器实际报告的同时触点数与它声明支持的数量相比如何。
- 检查静止稳定性. 尽量让一根手指保持不动，然后运行稳定性检测——它会观察在你没有刻意移动时，报告的位置漂移了多少。
- 监测幽灵触摸. 完全不触碰屏幕运行检测——它会监测出现故障的传感器可能自行记录的虚假触摸。
- 查看触点详情. 检查你的设备是否报告真实的压力和接触面积数据，还是像大多数没有此类传感器的屏幕一样，只发送固定的默认值。
为什么不显示延迟或毫米精度
没有任何网页 API 会记录手指实际触碰玻璃的确切瞬间——浏览器给出的时间戳是在触摸已经经过操作系统自身的输入处理流程之后才生成的。要测量真实延迟，需要对着屏幕的高速摄像机，而不是一个网页。毫米精度也从另一个角度存在同样的问题——浏览器 API 不会报告屏幕的物理尺寸，只会报告像素分辨率，因此无法将像素偏移换算成真实距离。
为什么覆盖扫描无法捕捉每一种死区
这项测试只能看到通过页面本身到达浏览器的内容。内嵌方框只能覆盖页面占据的那部分屏幕——全屏扫描能触及得多得多,直达屏幕的真实边缘,但即便如此,设备的状态栏、屏幕导航手势、刘海屏和圆角仍超出了任何网页所能检测的范围。因此,无论哪种区域,边缘附近未点亮的格子都可能只是这个标签页无法触及的地方,而不是硬件故障的证据。
- 你确实还没有滑过那个位置——这是最简单、也是最常见的原因。
- 你用的是内嵌方框而不是全屏扫描,而内嵌方框只能覆盖页面本身占据的那部分屏幕。
- 在页面感知之前，浏览器已将该触摸拦截为系统手势(比如屏幕边缘滑动)。
- 该区域位于浏览器界面、刘海屏或圆角之下,即使全屏页面也无法触及。
多点触控：“声明值”与“实测值”的真正含义
你的浏览器一开始就会报告一个 maxTouchPoints 数值——这是它对硬件支持多少同时触点的自我声明。这项测试会单独记录它实际检测到同时触摸的最大手指数，并将两者对比。低于声明值的结果通常只是说明你还没有同时尝试足够多的手指，或者手机操作系统把同时触点数限制得比屏幕本身允许的更低。
高于声明值的结果同样真实，也值得了解——一些浏览器与操作系统的组合会低报 maxTouchPoints，即使其硬件实际支持的同时触点数比宣传的更多。
静止稳定性：触摸版的摇杆漂移
健康的触摸屏应该在手指按住的整个过程中，把位置报告在起始点的一个像素以内。这项测试要求你尽量保持一根手指不动，并观察报告的位置偏离其稳定点有多远，同时忽略最初极短的一瞬间——手指刚接触时，接触面积仍在扩大，这种稳定过程并非缺陷。
- 稳定——接触稳定后未检测到明显漂移。
- 略有漂移——在手指略微潮湿或温热时，许多电容屏上属于正常现象。
- 不稳定——漂移明显大于稳定按住时应有的水平。
幽灵触摸：正在出故障的触摸屏是什么样子
幽灵触摸是指屏幕在没有人真正触碰的情况下记录到的接触——相当于卡住的按键。这项测试要求你大约 20 秒不要触碰屏幕，并统计这段时间内检测到的任何触摸，但会忽略最初极短的一瞬间(那是启动检测的点按的余波，而非幽灵触摸)。
压力与接触面积：读取一个可能并不存在的传感器
无论实际硬件是否真的有办法测量它们，Web 的 Pointer Events API 在每次触摸中都会包含一个压力值和接触的宽度/高度。在没有真实压力传感器的触摸屏上，每次触摸返回的压力都是同一个固定不变的值。这项测试会留意这一点——如果在大量样本中数字始终没有真正变化，它会诚实地报告“无压力传感器”，而不是显示一个看似有意义、实则一动不动的数值。
接触面积也是同样的道理——没有真实接触几何传感器的设备，每次触摸都报告固定的 1×1 像素点，这项测试会如实说明这一点，而不是假装你的手指真的只有一像素宽。
不会上传任何内容
本页上的每一项测量——你触摸的位置、同时使用了多少手指、按住的稳定程度、是否出现幽灵触摸、压力与接触面积——都直接从浏览器自身的触摸事件中读取，并完全在这个标签页内处理。关于你如何触摸屏幕的任何信息都不会被发送到任何地方。
常见问题
为什么这项测试无法以毫秒为单位测量触摸延迟？
没有任何网页 API 会记录手指实际触碰玻璃的确切瞬间——浏览器给出的时间戳是在触摸已经经过操作系统自身的输入处理流程之后才生成的。测量真实延迟需要高速摄像机，而不是网页。
为什么这项测试不显示毫米精度？
浏览器 API 不会报告屏幕的物理尺寸，只会报告像素分辨率，因此没有可靠的方法把像素偏移换算成真实距离。本页显示的任何毫米数字，都只是伪装成测量结果的猜测。
覆盖扫描时边缘的格子始终不亮，是我的屏幕坏了吗？
不一定。这项测试只能看到真正到达网页本身的触摸，而设备的状态栏、系统手势边缘、刘海屏或圆角都超出了任何网页能检测的范围。在断定是硬件故障之前，不妨专门针对那个位置再扫描一次。
我的设备声明的同时触点数比这项测试观测到的更多，为什么？
最可能的原因是你还没有同时尝试过那么多手指。也可能是手机操作系统把同时触点数限制得比屏幕本身支持的更低。
这项测试观测到的同时触点数比我浏览器声明的还多，这是漏洞吗？
不是，这是一个真实且有用的发现。一些浏览器与操作系统的组合会低报 maxTouchPoints 的数值，即使其硬件实际支持的同时触点数比宣传的更多。
压力检测结果显示我的触摸屏“没有压力传感器”，这准确吗？
大多数触摸屏确实没有办法测量你按压的力度，无论触摸力度如何，都会始终报告同一个固定的压力值。这项测试会在大量样本中留意这一点，然后才会得出没有真实传感器的结论。
这个工具会上传或存储任何内容吗？
不会。所有测量都在你的浏览器标签页内本地运行，离开页面后不会被发送或保存到任何地方。
除了手机和平板，触控笔记本电脑也能用吗？
可以。任何被浏览器报告为具有粗略(支持触摸)指针的设备，包括触控笔记本电脑，在这里的工作方式都是一样的。
关于你如何触摸屏幕的任何信息都不会被上传、记录或发送到任何地方。所有测量——触摸位置、同时接触数量、静止稳定性、幽灵触摸、压力、接触面积——都从浏览器自身的触摸事件中读取，并完全在这个浏览器标签页内处理。