触摸屏检测需综合判断。首先用 navigator.maxtouchpoints 检查设备是否支持触摸，其次通过 window.matchmedia(‘(hover: none) and (pointer: coarse)’) 判断用户是否主要使用手指交互，最后结合实际触摸事件动态调整 ui，而非仅依赖 ontouchstart 属性，因该方式不够准确且无法反映真实交互意图。
在浏览器环境中检测用户是否支持触摸屏，并不是一个简单的“是”或“否”的判断题，它更像是在收集各种线索，然后根据这些线索来推断。最核心且相对可靠的线索来自 navigator.maxTouchPoints 和 window.matchMedia 结合的媒体查询。单一的属性或事件判断往往不够全面，甚至可能误导。
解决方案
要相对准确地检测BOM中用户的触摸屏支持，我们需要综合运用几种方法，因为没有一个银弹能解决所有情况，特别是面对混合设备时。
首先，最直接且现代的属性是 navigator.maxTouchPoints。这个属性返回设备支持的最大并发触摸点数。如果它大于0，通常意味着设备具备触摸输入能力。
if (navigator.maxTouchPoints > 0) { console.log("设备可能支持触摸屏，最大触摸点数: " + navigator.maxTouchPoints); // 进一步的逻辑，例如调整UI} else { console.log("设备可能不支持触摸屏，或当前没有活动的触摸输入。");}
然而，仅仅依赖 navigator.maxTouchPoints 并不总是完美的。比如，一些带有手写笔输入的设备，maxTouchPoints 也会大于0，但用户可能并不习惯用手指触摸。更重要的是，我们常常想知道的不是“设备有没有触摸能力”，而是“用户当前是否主要通过触摸进行交互”。
这时，window.matchMedia 配合CSS媒体查询就显得尤为重要，特别是 (hover: none) and (pointer: coarse) 这个组合。
hover: none：表示主输入设备不支持悬停。鼠标和触控板通常支持悬停，而手指触摸则不支持。pointer: coarse：表示主输入设备的精确度较低，通常指手指触摸。鼠标和手写笔通常是 pointer: fine。
将两者结合起来，可以更准确地判断设备是否主要为触摸设计，或用户倾向于使用触摸：
function isTouchDevice() { // 检查 maxTouchPoints const hasTouchPoints = navigator.maxTouchPoints > 0; // 检查媒体查询 const prefersTouchInteraction = window.matchMedia('(hover: none) and (pointer: coarse)').matches; // 综合判断，但需要注意，这依然是一种推断 return hasTouchPoints && prefersTouchInteraction;}if (isTouchDevice()) { console.log("根据综合判断，这很可能是一个主要通过触摸交互的设备。"); // 针对触摸屏优化UI} else { console.log("这可能是一个鼠标/键盘主导的设备，或混合设备。");}
这种组合判断通常更为可靠，它试图捕捉用户交互的“意图”而非仅仅是硬件能力。当然，它也并非万无一失，例如一些桌面浏览器为了开发者调试，可能会模拟触摸事件，从而导致误判。
为什么仅仅检查ontouchstart不足以判断触摸屏支持？
在过去，开发者确实很喜欢用 document.documentElement.ontouchstart !== undefined 这样的方式来判断触摸屏支持。我个人也用过，觉得方便快捷。但说实话，这种方法现在看来，用“过时”来形容都显得客气了，它根本就是不准确的。
首先，ontouchstart 只是一个事件处理器属性的存在与否，它反映的是浏览器是否支持 touchstart 这个事件，而不是设备是否真的有触摸屏。很多桌面浏览器，为了兼容性和方便开发者调试，即使没有触摸屏，也可能在 window 或 document 对象上暴露 ontouchstart 属性。这就像你家里装了门铃按钮，但并不代表你家外面真的有人在按门铃。
其次，即使 ontouchstart 存在，也无法告诉你设备的触摸能力是怎样的，比如是单点触摸还是多点触摸。它更无法区分是手指触摸、手写笔触摸，还是某种辅助设备。现代前端开发需要更精细的控制和判断，而 ontouchstart 提供的粒度太粗糙了。
再者，这种基于事件属性的特性检测，在标准化的道路上已经被 navigator.maxTouchPoints 和媒体查询所取代。后者提供了更明确、更符合W3C规范的方式来获取这些信息。依赖一个非标准或已废弃的检测方式，无疑是在给自己未来的维护挖坑。所以，当我看到代码里还在用 ontouchstart 做判断时，总会觉得有点惋惜，毕竟有更好的方式摆在那里。
混合设备（如触屏笔记本）的触摸检测有哪些特殊考量？
混合设备，比如那些带触摸屏的笔记本电脑，或者某些二合一平板电脑，是触摸检测中最让人头疼的场景。它们同时拥有鼠标/触控板和触摸屏两种输入方式，这就让我们的判断变得复杂起来。
我的经验是，在这种设备上，navigator.maxTouchPoints 几乎总是大于0，因为它们确实有触摸屏。但关键在于 window.matchMedia('(hover: none) and (pointer: coarse)') 的表现。很多时候，如果笔记本的主输入模式仍然被认为是鼠标/触控板（例如，用户更频繁地使用触控板），那么 hover: hover 和 pointer: fine 可能会是默认值。这意味着，即使设备有触摸能力，浏览器也可能认为用户当前更倾向于使用精确的指针设备。
这种情况下，我们面临的挑战是：是根据设备能力来调整UI，还是根据用户当前的实际交互模式来调整？我个人倾向于后者。如果用户正在用鼠标，即使设备支持触摸，UI也应该优先考虑鼠标操作的便利性，例如显示悬停效果。反之，如果用户开始触摸屏幕，那么UI应该立即响应，例如放大触摸目标。
这就引出了一个更深层次的问题：我们真的需要“检测”触摸屏吗？或者说，我们更应该“响应”触摸事件？对于混合设备，我倾向于采取一种更动态、更“事件驱动”的策略。例如，当实际的 touchstart 事件发生时，我们才去切换UI到触摸优化模式，而不是在页面加载时就一刀切地判断。这就像你不能因为一个人有汽车驾照，就假设他每次出门都开车，他可能今天想走路呢。
除了检测，如何在Web应用中优化触屏用户体验？
检测触摸屏支持只是第一步，真正的挑战和价值在于如何基于这种检测（或更直接地，基于触摸事件本身）来优化Web应用的用户体验。这可不是简单地把按钮变大那么简单，它涉及到很多细节，而且这些细节往往能决定用户对你的应用是爱还是恨。
首先是触摸目标（Touch Targets）。这是最基础也最容易被忽视的一点。在触摸屏上，用户的指尖远不如鼠标指针精确。所以，所有可点击、可交互的元素，比如按钮、链接、表单输入框，都应该有足够大的触摸区域。通常建议至少44×44像素。我见过太多网站，在手机上点一个很小的图标，点半天点不准，那种挫败感真的让人想摔手机。
其次是手势支持。触摸屏不仅仅是点击，它还有滑动、捏合、双指缩放等手势。如果你的应用涉及到图片浏览、地图、长列表等，考虑加入这些手势支持会极大提升用户体验。例如，图片库可以支持左右滑动切换，地图可以支持双指缩放。当然，这需要一些JavaScript库或自定义实现来处理 touchstart, touchmove, touchend 事件。
再来是虚拟键盘的处理。当用户在触摸设备上点击输入框时，虚拟键盘会弹出来，这可能会遮挡一部分内容，甚至导致页面布局错乱。我们需要确保输入框被聚焦时，它仍然在可视区域内，并且不会被键盘遮挡。有时候，可能需要用JavaScript来滚动视图，或者调整布局。
还有一点很关键，是悬停（Hover）状态的替代方案。在鼠标主导的设备上，我们习惯用 :hover 来给用户提供视觉反馈，比如鼠标移到按钮上时变色。但在触摸屏上，没有“悬停”这个概念。所以，那些只在悬停时才显示的信息或功能，需要找到替代的展现方式，比如点击后显示，或者始终可见。
最后，性能。触摸操作对页面的响应速度非常敏感。任何卡顿、延迟都会让用户觉得应用“不跟手”。所以，优化动画、减少不必要的重绘和回流，确保JavaScript执行效率，对于触摸屏用户体验来说至关重要。这就像你用手去触碰一个物体，如果它反应迟钝，你就会觉得它很“笨重”。
以上就是BOM中如何检测用户的触摸屏支持？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1508384.html
微信扫一扫 
支付宝扫一扫 
