做移动端H5的时候我攒了一个叫“buzz”的小模块。项目代号就一个字buzz干的事也跟这个单词的本意一样让手机在合适的时机“嗡”一下。说白了就是调用浏览器自带的振动接口给页面加上真实的触觉反馈。这个需求一开始看着不起眼不少人觉得不就一个navigator.vibrate()的事吗可真要做得稳、做得不突兀、兼容性问题处理干净里面坑比想象中多得多。这篇文章把我踩过的坎、想清楚的逻辑和最终落地的方案完整写出来给做H5互动、移动端WebApp和混合应用的朋友一个可以直接抄作业的参考。1. 这个叫“buzz”的项目到底做了什么1.1 一个被忽略的反馈通道人类接收信息靠的不只是眼睛和耳朵触觉是更原始、更直接的一条通道。你在手机上打字、玩游戏、按实体键那种“咯噔”一下的手感本质上就是设备在给你发送触觉信号。但在Web页面里这个通道常年是断的。我之前接的那个H5项目是个互动营销页面有刮奖、抽奖转盘、答题闯关这些玩法。每次抽奖结果出来页面上当然有动画、有弹窗视觉反馈很丰富但用户手指在屏幕上点来点去却感觉“轻飘飘”的。尤其是在比较嘈杂的环境里用户可能根本没注意到结果已经弹出来了。当时产品提了一个很朴素的需求能不能让手机振一下让用户手上的感觉告诉他“结果出来了”。说实话这个需求在移动端原生App里很容易实现但我们是H5页面跑在浏览器里当时团队里一半人不知道浏览器还能控制手机振动。其实浏览器还真的能这就是Web Vibration API常用的就是navigator.vibrate()这个方法。它在Android生态里的Chrome、Firefox以及大部分国产浏览器内核中都有良好支持而在iOS Safari上至今仍在“计划中”。我做的buzz模块就是围绕这个API做的一整套封装、降级和体验优化方案。1.2 这个模块的目标和边界项目代号叫buzz目标非常聚焦给H5页面提供一套简单、统一、可控的振动反馈能力同时在不支持振动的环境下自动降级不破坏原有体验。我给自己定的边界很明确只做“反馈”不做“输入”。也就是说buzz只管在合适的时机发出振动信号不管用户手指怎么滑、怎么按。另一个边界是buzz不负责业务逻辑的编排只提供一个一个的“手势”拿“抽奖结果”这种业务事件来说业务方决定什么时候触发buzz决定怎么振两边职责分开。做了一段时间后我越发觉得这个模块值得单独拎出来讲。因为“让页面会振动”这件事看起来是加几行代码实际上牵扯到兼容性判断、振动模式设计、页面生命周期管理、用户手势限制、甚至和音频反馈的配合。这些问题如果不在设计初期想清楚后面越用越别扭。2. 技术底座Web Vibration API关键知识点2.1 先认识navigator.vibrate()这个老朋友Web Vibration API规范上叫Vibration API它的核心入口就一个方法navigator.vibrate()。这个API的兼容性列表在caniuse里看很直观Android Chrome从37开始支持Android Firefox从32开始支持包括三星、小米、华为等自带浏览器基本都通过了WebView内核的Chromium所以在Android这边可以说是“基本全线可用”。iOS Safari直到我写这套方案的版本都还没真正开放振动权限页面里调用它只会静默失败。navigator.vibrate()接受一个参数可以是数字也可以是数字数组。传数字时表示持续振动多少毫秒比如navigator.vibrate(200)就是让手机持续振动200毫秒。传数组时数组的每个元素交替表示“振动”和“停止”的毫秒数例如[200, 100, 200]就是振动200ms、停100ms、再振动200ms。数组第一个数一定是振动即使你传了0开头那也只是“先停0ms”再进入下一个振动段。这里有个细节值得注意持续振动的时长上限。虽然在规范文档里没有硬性规定上限值但浏览器实现中普遍对超长的振动做了截断。以Android Chrome为例当连续振动时间超过某个阈值不同版本不完全一样大概在10秒到1分钟之间浏览器会直接截断。原因是设计振动API的初衷是给人“短暂反馈”不是拿手机当按摩棒。2.2 数组模式才是振动体验的灵魂很多人第一次接触这个API以为只能做“嗡嗡嗡”的直振其实不是。数组参数可以做到非常细腻的振动节奏这才是buzz模块的核心价值所在。举几个实际的例子// 短促的轻击适合按钮按下 navigator.vibrate(15); // 清脆的两连击适合结果弹出 navigator.vibrate([30, 50, 30]); // 三段式提醒模式比较强烈适合警告 navigator.vibrate([80, 40, 80, 40, 80]); // 长按触发的持续振动 navigator.vibrate([50, 20, 50, 20, 100]);数组模式的本质是用“振动 - 停顿 - 振动”的时间序列来组合出不同的手感。就像摩斯电码一样短振和长振组合起来就能传递出不同的语义。这比简单的“持续振动200ms”高级得多因为200ms的持续振动无论用在哪个场景都是同一个感觉而数组模式可以设计出“轻触”“确认”“警告”这种有差异的反馈语言。我实际测试下来短振动的时长设计非常讲究。15ms已经能产生清晰的触感但不会让人觉得很吵。30ms更像一次明确的“嗒”感。超过100ms的连续振动就有点“厚重”了一般用于需要强烈提醒的场景不能滥用。设计buzz的模式库时我反复调整了不下十版最后定下来的模式在我自己真机测试里达到了“既明显又不恼人”的效果。2.3 浏览器运行条件HTTPS、用户手势和页面可见性任何Web API都有运行条件Vibration API也不例外。这个API只能在安全上下文HTTPS或localhost中调用如果你在HTTP环境下打开页面navigator.vibrate根本不存在或者会被策略拦截。混合应用里如果你的WebView原生层配置了允许不安全的来源那又是另一回事但常规的线上H5一定要走HTTPS。更隐蔽的一个条件是用户手势。大多数移动端浏览器要求振动API必须在用户手势事件比如touchstart、click、pointerdown的调用栈里执行不能莫名其妙地在页面刚加载完时自己振一下。Chrome Android在早期版本里还允许任意时机调用后来也收紧了这个策略和自动播放限制差不多都是为了防止页面骚扰用户。实际下来在一个setTimeout里调用navigator.vibrate(200)如果定时器是在点击事件的回调里启动的一般没问题但如果是在页面初始化时凭空调用的很可能被当作“无用户参与的振动”而被忽略。页面可见性也要考虑。如果用户已经切到后台或锁屏了振动会被系统静默或者继续响应但是在锁屏界面振动这个体验非常突兀。buzz模块在设计初期就在visibilitychange事件上挂了清理逻辑页面一藏起来就立刻终止所有振动。3. 设计buzz模块时的方案选型3.1 不是简单包一层而是设计一套反馈语言很多人的第一反应是写个公共函数function buzz(pattern) { if (navigator.vibrate) navigator.vibrate(pattern); }这种写法可以用在小项目里但它的缺陷也很明显没有模式管理、没有防抖、没有降级、没有生命周期处理。如果只是某个按钮加一次振动这样够了。但如果我们想在整个项目里形成一套一致的手感就必须把“怎么振”这件事抽象出来定成一套规范。我管这叫“反馈语言”。就像设计系统会规范颜色、字体、间距一样振动反馈也应该有它自己的语义化标签。比如light指那种极短促的轻触confirm指操作成功后的确认感warning指强烈提醒。业务方不应该关心具体振动模式是[30, 50, 30]还是[15]他们只需要说“这里我想给个确认反馈”buzz自动映射到具体的振动序列。这样视觉、交互、前端三方沟通时就有一门共同语言。3.2 模块结构一个VibrationManagerbuzz模块最终设计成了一个单例管理器核心结构大概长这样const DEFAULT_PATTERNS { light: 15, tap: [15, 30, 15], confirm: [30, 50, 30], success: [40, 30, 15, 30, 40], warning: [80, 40, 80, 40, 80], }; class VibrationManager { constructor() { this.enabled this.isSupported(); this.locked false; } isSupported() { return typeof navigator ! undefined vibrate in navigator; } fire(type) { if (!this.enabled || this.locked) return; const pattern DEFAULT_PATTERNS[type]; if (!pattern) return; try { navigator.vibrate(pattern); } catch (e) { // 捕获异常振动失败绝不影响业务 } } stop() { if (this.enabled) { navigator.vibrate(0); } } lock() { this.locked true; } unlock() { this.locked false; } } const vibrationManager new VibrationManager();这个类还有一个lock机制用于处理连续触发的场景。比如用户连点三次抽奖按钮如果每次点击都触发一次success振动三次振动指令会叠加在振动队列里实际效果就是“振了一长串”非常糟糕。加上锁后在振动进行期间忽略新的振动请求等振完再解锁。后面踩坑章节我还会详细讲这个问题。3.3 降级策略在没有振动能力的平台制造“替代手感”iOS Safari不支持振动这是Web平台上永远绕不开的现实。难道iOS用户就不配拥有反馈吗显然不是。我的处理方式是引入“视觉补偿反馈”。降级的核心思路是把“振动”这个触觉信号转换成用户能感知到的视觉信号。比如按钮被按下时本来应该振一下在iOS上我就给按钮添加一个瞬时的缩放动画有点像原生iOS按钮的按压效果。动画时长极短大约100到150ms用来模拟那种“咯噔”的阻尼感。.btn-pressed { animation: buzz-feedback 120ms ease-out; } keyframes buzz-feedback { 0% { transform: scale(1); } 40% { transform: scale(0.95); } 100% { transform: scale(1); } }这种降级不是单纯地“没有就没有”而是用另一种通道尽量填补体验空缺。实际体验中这种按压缩放配合轻量的透明度变化能比较有效地补偿振动缺失的手感。当然视觉补偿不能替代真正的触觉但它至少让iOS用户不会觉得“点起来轻飘飘”。4. 核心实现细节与实操要点4.1 反馈模式设计定义一套“手感词汇表”模式设计是整个buzz模块我认为最值得反复琢磨的部分。振动模式既不能太轻导致感知不到也不能太重导致像骚扰电话。我把常用模式分成几个层级每个层级服务于不同的交互场景。light级别对应最普通的按钮触摸反馈一般是15ms左右的单次短振。这个时长在Android上刚好能产生明确的触点感受不会让整机震动听起来像“嗒”一下。tap级别对应需要强调的离散操作比如开关切换、标签选择模式是[15, 30, 15]两下短促的振动足够让人知道切换生效了。confirm级别对应操作成功的确认模式是[30, 50, 30]比tap更加“稳”一点有明确的起止感。success级别对应流程完成的庆祝感比如抽奖结果弹出、任务达成模式是[40, 30, 15, 30, 40]这段模式在真机上听起来像“嗒—嗒嗒—嗒”比较有节奏。warning级别对应错误或强提醒模式是[80, 40, 80, 40, 80]振感强、时间长一般用于需要用户警觉的场景。每个模式我都用真机测过。要注意的是同一段模式在不同手机上的实际体验差异极大转子马达和线性马达的启动延迟不一样低端机反应迟钝、高端机干脆利落。所以不能把我们代码里的振动参数当成绝对标准只能在真机上反复微调找到绝大多数设备都能感知的区间。4.2 把werkzeug放在一边如何正确接入业务事件buzz模块本身不感知业务它只提供fire(type)这样的出口。但如何接入业务事件是有讲究的。我在项目里做了事件桥接层让业务方通过一个语义化的方法调用而不是直接操作振动对象。比如抽奖结果回来时业务代码是这样的function handleLotteryResult(success) { if (success) { vibrationManager.fire(success); } else { vibrationManager.fire(warning); } showResultModal(success); }调用方只关心是成功还是失败具体振多长时间、振动几次由buzz在内部决定。好处是当我们需要调整振动模式时只需要改模式表不需要满项目搜索调用点。随着页面越来越多不同页面可能对同一种反馈有不同偏好我还在模块里支持了全局模式和临时覆盖模式但默认情况下保证所有页面手感一致。4.3 页面生命周期与性能优化细节移动端页面的生命周期远比PC复杂振动模块必须对它敬畏。我把visibilitychange事件和一个页面卸载清理逻辑直接写进了模块内部。当页面不可见时立即调用navigator.vibrate(0)把振动队列清空防止用户把页面切后台后手机还在怀里嗡嗡响。document.addEventListener(visibilitychange, () { if (document.hidden) { vibrationManager.stop(); } });这段逻辑看起来简单但它解决了很多没做过振动开发的开发者不会想到的问题用户可能正在点按钮此时突然来电提醒页面切到后台如果没有清理逻辑振动会和来电冲突结果非常尴尬。性能方面振动API本身不涉及图形渲染但它经常在动画代码中触发。如果动画帧率本来就低再叠加振动调度可能会让低端机的页面更卡。我的建议是振动调用一律放在主线程的事件回调里不要频繁地在requestAnimationFrame循环里反复触发振动命令。还有一点不要在滚动容器里监听滚动事件来触发振动滚动频率太高这样既有性能问题也会因为连续振动让用户觉得页面“疯了”。如果需要滚动到某个位置时给一个反馈应该做节流。4.4 振动与音频反馈的联动单纯的手部振动再加上同步的音频反馈整体感觉会立刻立体起来。最简单的做法是同一个事件既触发振动又播放一个极短的音效。比如点击按钮时同时“嗒”一声和“嗡”一下反馈就非常完满了。但AudioContext在移动端的自动播放限制同样存在。Chrome要求必须先有用户手势才能解锁音频上下文。所以我在buzz里设计了一个统一的唤醒入口const audioCtx new AudioContext(); function playClickSound() { // 必须确保 audioCtx 已经处于 running 状态 if (audioCtx.state suspended) { audioCtx.resume(); } // 创建一个极短的 osc 音 const osc audioCtx.createOscillator(); const gain audioCtx.createGain(); osc.connect(gain); gain.connect(audioCtx.destination); osc.frequency.value 800; gain.gain.setValueAtTime(0.2, audioCtx.currentTime); gain.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime 0.05); osc.start(); osc.stop(audioCtx.currentTime 0.06); }注意这个audioCtx.resume()必须在用户点击事件里调用否则会被浏览器拒绝。同理振动API的执行也必须发生在用户手势链中。实际经验是把音频和振动放在同一个事件回调里让两条反馈同时触发减少因为异步拆开导致的违反手势策略风险。5. 实测过程与踩坑记录5.1 真机测试哪些设备振哪些设备不吭声做移动端开发模拟器永远代替不了真机。buzz模块的真机测试我专门拉了一张兼容性表把同事手上的备用机都借来测了一遍结果比caniuse的数据有意思得多。设备/浏览器是否支持振动实际体验Android 12 / Chrome 95支持振动干脆利落模式区分度高Android 10 / 小米浏览器支持振动偏“软”短振时感知较弱Android 11 / 微信内置浏览器支持部分WebView内核振动有效但响应有明显延迟Android 9 / 华为自带浏览器支持模式完全可用但长振被系统限制得比较短iOS 15 / Safari不支持静默失败navigator.vibrate是undefinediOS 15 / 微信内置浏览器不支持同上无振动无报错这里有个结论同样一段[30, 50, 30]在小米浏览器上感知很弱在最新Chrome上就很清楚。原因是线性马达和转子马达的差异以及各家系统对振动API的实现差异。所以做模式设计时不能只在一台高端旗舰机上调一定要拿几台中低端机做对照。5.2 踩坑一iOS Safari完全不支持怎么让测试通过iOS不支持在大部分项目里并不算Bug因为页面本身在iOS上可以正常运行只是没有振动反馈。问题在于如果产品经理和测试抱着“必须有反馈”的预期去验收就会被打回。我的处理办法是提前把降级方案做在前面并在项目文档里写明确iOS上使用按压缩放动画替代振动。这样测试验收时iOS上的确也能看到反馈不过是视觉层面的而不是触觉层面的。这个预期管理非常重要不然等到交付前才被发现又要手忙脚乱地补方案。5.3 踩坑二桌面浏览器调试时完全不振动开发时如果在桌面Chrome的开发者工具里模拟移动端设备navigator.vibrate在大部分情况下是存在的但调用后PC根本没有马达自然不会有任何反馈。所以很多人在电脑上调了一下午以为代码有问题其实只是桌面硬件不支持。解决方式用Android真机开启USB调试通过chrome://inspect远程调试页面的实际运行效果或者在本地局域网用手机直接访问开发服务器。真机上的反馈才是唯一的验证标准开发者工具只能用来验证API是否存在、参数是否正确。5.4 踩坑三连续触发振动变成一股又长又乱的振动这个坑我真正踩实过也是buzz模块引入lock锁机制的直接原因。假设用户连点三下按钮三次click事件各调用了一次fire(success)。如果不加控制浏览器会把三次振动模式塞进同一个振动队列振出来就是“嗡——嗡——嗡——”的长条完全失去了模式的意义。解决方案除了lock锁还有一个更精细的做法记录上一次振动的结束时间如果新请求到来时上一种模式还没振完先调用一次navigator.vibrate(0)清空队列再调用新模式。两种方案各有选择lock更适合“一次操作一个反馈”的交互而清队列适合“允许连续反馈但每次都要完整呈现”的场景。5.5 踩坑四页面里多个buzz实例互相打架早期代码里我图省事直接在组件里创建了多个VibrationManager结果A组件的振动还没结束B组件又振了一下整个页面的振动节奏全乱了。后来我把VibrationManager改成了单例模式整个页面只有一个入口才解决了这个互相覆盖的问题。这个教训让我想明白一件事像振动这种全局性的反馈通道就不应该设计成“每个组件私有”的东西。反馈是一套系统不是某种局部状态。这一点跟全局Toast提示是一样的道理你不希望页面上同时冒出十个Toast。6. 常见问题与排查技巧实录6.1 常见问题速查表我把实际运行中收集到的典型问题整理一下做成速查表方便后续维护的同学快速定位。问题现象可能原因解决方案Android上调用无反应页面不是HTTPS环境把页面部署到HTTPS或localhost下再测试页面刚加载时调用无反应没有在用户手势中调用将振动调用放在click/touchstart事件回调内iOS上完全不振动iOS Safari不支持Web Vibration API启用视觉缩放补偿反馈连续点击后振动变成一条长振多个振动请求叠加到振动队列加lock锁或先调用vibrate(0)清空队列页面切到后台还在振动没有监听visibilitychange清理振动在不可见时立即调用vibrate(0)微信内置浏览器中振动时有时无WebView内核版本差异或权限策略低优先级反馈可以放弃关键反馈使用强模式振动调用导致页面上出现报错navigator.vibrate不是函数先做能力检测typeof navigator.vibrate function设置的80ms长振实际振得比预期短系统/浏览器对连续振动时长有限制把长振拆成多个短振组合或降低对时长的预期6.2 排查思路从“不振动”到“振错了”遇到振动相关问题时我有一套固定的排查顺序。先确认协议环境看页面是否在HTTPS下再确认调用时机是不是在用户手势事件里接着确认设备能力navigator.vibrate是否存在最后确认队列状态是不是被之前的振动占用。这套顺序能解决70%以上的问题。还有个小技巧调试时在控制台手动执行navigator.vibrate([100, 50, 100])如果真机通过USB远程调试连接着直接就能在手机上感受到效果。这比反复刷新页面改代码高效得多。控制台执行时也是从用户手势上下文中调用的通常能通过浏览器策略限制。6.3 独家避坑千万别让buzz成为“报警器”在项目推广阶段我观察到一种滥用倾向业务方觉得振动很酷于是按钮、弹窗、轮播都加上了振动反馈。到最后用户打开页面手机像马达一样震个不停结果变成了负体验。后来我发起了一个“振动礼仪”约定只有真正需要用户感知节点时才启用振动普通滑动、次要按钮不加振动同一个交互流程内最多触发一次振动默认模式下振感不超过200ms。这个约定的效果立竿见影。页面整体的“手感”反而变好了用户能感知到的振动都是关键节点的信号而不是噪音。现在我把这条经验写进模块的Readme里作为使用规范的一部分。7. 这个模块后续还可以怎么扩展7.1 结合Gamepad API的探索Web平台上有另一个跟“反馈”相关的APIGamepad API它允许浏览器读取游戏手柄状态并且一些手柄带有振动马达可以通过navigator.getGamepads()拿到的hapticActuators来触发振动。虽然目前这个能力和移动端关系不大但如果页面未来要支持连接到手机上的蓝牙手柄这套震动反馈机制可以复用buzz的模式设计思路只是调用对象不同。7.2 长按振动与“模拟强度”原生API其实没有提供振动强度的控制只能通过振动时长和间隔来模拟。我后来做了一个长按交互的实验用户长按按钮时用setInterval循环执行短促振动并且随着长按时长增加逐步把振动时间从15ms加长到60ms。这样在手感上会产生一种“振动变强”的幻觉。虽然它不如原生触觉API细腻但在Web端已经是一种很实用的模拟方案。实现要点是interval的回调里同样要检查页面可见性和振动状态否则长按期间用户切到后台定时器还在触发振动就会造成持续的骚扰。7.3 把手感当成产品设计的一部分buzz模块做到后面我发现它已经超越了“调用一个API”的技术层面变成了一种设计语言。靠谱的反馈设计原则无非就三条短促、少次、有语义。短促指振动时长尽量短少次指单次操作只振一下有语义指每种反馈都要有明确的意义不能所有场景都用同一个模式。这几条我写在了模块的规范文档里新同学接手项目时先看文档就知道什么场景该用light、什么场景应该用success不需要靠猜。如果再重新做一遍这个模块我会把“反馈模式表”单独抽成一个配置文件方便运营配置不同的手感风格。目前的版本还是硬编码在代码里改动一次要发一次版。接口设计上也可以再抽象一层让buzz同时支持振动和视觉补偿两种输出由内部根据环境自动切换调用方完全无感。这个方向在Web标准演进之后说不定还能对接更底层的Haptic API。对我来说buzz这个项目的价值不只是让页面会振而是让我明白了一个道理反馈的终极目标不是“有多明显”而是“刚刚好”。
H5振动反馈实战：用navigator.vibrate打造buzz模块
做移动端H5的时候我攒了一个叫“buzz”的小模块。项目代号就一个字buzz干的事也跟这个单词的本意一样让手机在合适的时机“嗡”一下。说白了就是调用浏览器自带的振动接口给页面加上真实的触觉反馈。这个需求一开始看着不起眼不少人觉得不就一个navigator.vibrate()的事吗可真要做得稳、做得不突兀、兼容性问题处理干净里面坑比想象中多得多。这篇文章把我踩过的坎、想清楚的逻辑和最终落地的方案完整写出来给做H5互动、移动端WebApp和混合应用的朋友一个可以直接抄作业的参考。1. 这个叫“buzz”的项目到底做了什么1.1 一个被忽略的反馈通道人类接收信息靠的不只是眼睛和耳朵触觉是更原始、更直接的一条通道。你在手机上打字、玩游戏、按实体键那种“咯噔”一下的手感本质上就是设备在给你发送触觉信号。但在Web页面里这个通道常年是断的。我之前接的那个H5项目是个互动营销页面有刮奖、抽奖转盘、答题闯关这些玩法。每次抽奖结果出来页面上当然有动画、有弹窗视觉反馈很丰富但用户手指在屏幕上点来点去却感觉“轻飘飘”的。尤其是在比较嘈杂的环境里用户可能根本没注意到结果已经弹出来了。当时产品提了一个很朴素的需求能不能让手机振一下让用户手上的感觉告诉他“结果出来了”。说实话这个需求在移动端原生App里很容易实现但我们是H5页面跑在浏览器里当时团队里一半人不知道浏览器还能控制手机振动。其实浏览器还真的能这就是Web Vibration API常用的就是navigator.vibrate()这个方法。它在Android生态里的Chrome、Firefox以及大部分国产浏览器内核中都有良好支持而在iOS Safari上至今仍在“计划中”。我做的buzz模块就是围绕这个API做的一整套封装、降级和体验优化方案。1.2 这个模块的目标和边界项目代号叫buzz目标非常聚焦给H5页面提供一套简单、统一、可控的振动反馈能力同时在不支持振动的环境下自动降级不破坏原有体验。我给自己定的边界很明确只做“反馈”不做“输入”。也就是说buzz只管在合适的时机发出振动信号不管用户手指怎么滑、怎么按。另一个边界是buzz不负责业务逻辑的编排只提供一个一个的“手势”拿“抽奖结果”这种业务事件来说业务方决定什么时候触发buzz决定怎么振两边职责分开。做了一段时间后我越发觉得这个模块值得单独拎出来讲。因为“让页面会振动”这件事看起来是加几行代码实际上牵扯到兼容性判断、振动模式设计、页面生命周期管理、用户手势限制、甚至和音频反馈的配合。这些问题如果不在设计初期想清楚后面越用越别扭。2. 技术底座Web Vibration API关键知识点2.1 先认识navigator.vibrate()这个老朋友Web Vibration API规范上叫Vibration API它的核心入口就一个方法navigator.vibrate()。这个API的兼容性列表在caniuse里看很直观Android Chrome从37开始支持Android Firefox从32开始支持包括三星、小米、华为等自带浏览器基本都通过了WebView内核的Chromium所以在Android这边可以说是“基本全线可用”。iOS Safari直到我写这套方案的版本都还没真正开放振动权限页面里调用它只会静默失败。navigator.vibrate()接受一个参数可以是数字也可以是数字数组。传数字时表示持续振动多少毫秒比如navigator.vibrate(200)就是让手机持续振动200毫秒。传数组时数组的每个元素交替表示“振动”和“停止”的毫秒数例如[200, 100, 200]就是振动200ms、停100ms、再振动200ms。数组第一个数一定是振动即使你传了0开头那也只是“先停0ms”再进入下一个振动段。这里有个细节值得注意持续振动的时长上限。虽然在规范文档里没有硬性规定上限值但浏览器实现中普遍对超长的振动做了截断。以Android Chrome为例当连续振动时间超过某个阈值不同版本不完全一样大概在10秒到1分钟之间浏览器会直接截断。原因是设计振动API的初衷是给人“短暂反馈”不是拿手机当按摩棒。2.2 数组模式才是振动体验的灵魂很多人第一次接触这个API以为只能做“嗡嗡嗡”的直振其实不是。数组参数可以做到非常细腻的振动节奏这才是buzz模块的核心价值所在。举几个实际的例子// 短促的轻击适合按钮按下 navigator.vibrate(15); // 清脆的两连击适合结果弹出 navigator.vibrate([30, 50, 30]); // 三段式提醒模式比较强烈适合警告 navigator.vibrate([80, 40, 80, 40, 80]); // 长按触发的持续振动 navigator.vibrate([50, 20, 50, 20, 100]);数组模式的本质是用“振动 - 停顿 - 振动”的时间序列来组合出不同的手感。就像摩斯电码一样短振和长振组合起来就能传递出不同的语义。这比简单的“持续振动200ms”高级得多因为200ms的持续振动无论用在哪个场景都是同一个感觉而数组模式可以设计出“轻触”“确认”“警告”这种有差异的反馈语言。我实际测试下来短振动的时长设计非常讲究。15ms已经能产生清晰的触感但不会让人觉得很吵。30ms更像一次明确的“嗒”感。超过100ms的连续振动就有点“厚重”了一般用于需要强烈提醒的场景不能滥用。设计buzz的模式库时我反复调整了不下十版最后定下来的模式在我自己真机测试里达到了“既明显又不恼人”的效果。2.3 浏览器运行条件HTTPS、用户手势和页面可见性任何Web API都有运行条件Vibration API也不例外。这个API只能在安全上下文HTTPS或localhost中调用如果你在HTTP环境下打开页面navigator.vibrate根本不存在或者会被策略拦截。混合应用里如果你的WebView原生层配置了允许不安全的来源那又是另一回事但常规的线上H5一定要走HTTPS。更隐蔽的一个条件是用户手势。大多数移动端浏览器要求振动API必须在用户手势事件比如touchstart、click、pointerdown的调用栈里执行不能莫名其妙地在页面刚加载完时自己振一下。Chrome Android在早期版本里还允许任意时机调用后来也收紧了这个策略和自动播放限制差不多都是为了防止页面骚扰用户。实际下来在一个setTimeout里调用navigator.vibrate(200)如果定时器是在点击事件的回调里启动的一般没问题但如果是在页面初始化时凭空调用的很可能被当作“无用户参与的振动”而被忽略。页面可见性也要考虑。如果用户已经切到后台或锁屏了振动会被系统静默或者继续响应但是在锁屏界面振动这个体验非常突兀。buzz模块在设计初期就在visibilitychange事件上挂了清理逻辑页面一藏起来就立刻终止所有振动。3. 设计buzz模块时的方案选型3.1 不是简单包一层而是设计一套反馈语言很多人的第一反应是写个公共函数function buzz(pattern) { if (navigator.vibrate) navigator.vibrate(pattern); }这种写法可以用在小项目里但它的缺陷也很明显没有模式管理、没有防抖、没有降级、没有生命周期处理。如果只是某个按钮加一次振动这样够了。但如果我们想在整个项目里形成一套一致的手感就必须把“怎么振”这件事抽象出来定成一套规范。我管这叫“反馈语言”。就像设计系统会规范颜色、字体、间距一样振动反馈也应该有它自己的语义化标签。比如light指那种极短促的轻触confirm指操作成功后的确认感warning指强烈提醒。业务方不应该关心具体振动模式是[30, 50, 30]还是[15]他们只需要说“这里我想给个确认反馈”buzz自动映射到具体的振动序列。这样视觉、交互、前端三方沟通时就有一门共同语言。3.2 模块结构一个VibrationManagerbuzz模块最终设计成了一个单例管理器核心结构大概长这样const DEFAULT_PATTERNS { light: 15, tap: [15, 30, 15], confirm: [30, 50, 30], success: [40, 30, 15, 30, 40], warning: [80, 40, 80, 40, 80], }; class VibrationManager { constructor() { this.enabled this.isSupported(); this.locked false; } isSupported() { return typeof navigator ! undefined vibrate in navigator; } fire(type) { if (!this.enabled || this.locked) return; const pattern DEFAULT_PATTERNS[type]; if (!pattern) return; try { navigator.vibrate(pattern); } catch (e) { // 捕获异常振动失败绝不影响业务 } } stop() { if (this.enabled) { navigator.vibrate(0); } } lock() { this.locked true; } unlock() { this.locked false; } } const vibrationManager new VibrationManager();这个类还有一个lock机制用于处理连续触发的场景。比如用户连点三次抽奖按钮如果每次点击都触发一次success振动三次振动指令会叠加在振动队列里实际效果就是“振了一长串”非常糟糕。加上锁后在振动进行期间忽略新的振动请求等振完再解锁。后面踩坑章节我还会详细讲这个问题。3.3 降级策略在没有振动能力的平台制造“替代手感”iOS Safari不支持振动这是Web平台上永远绕不开的现实。难道iOS用户就不配拥有反馈吗显然不是。我的处理方式是引入“视觉补偿反馈”。降级的核心思路是把“振动”这个触觉信号转换成用户能感知到的视觉信号。比如按钮被按下时本来应该振一下在iOS上我就给按钮添加一个瞬时的缩放动画有点像原生iOS按钮的按压效果。动画时长极短大约100到150ms用来模拟那种“咯噔”的阻尼感。.btn-pressed { animation: buzz-feedback 120ms ease-out; } keyframes buzz-feedback { 0% { transform: scale(1); } 40% { transform: scale(0.95); } 100% { transform: scale(1); } }这种降级不是单纯地“没有就没有”而是用另一种通道尽量填补体验空缺。实际体验中这种按压缩放配合轻量的透明度变化能比较有效地补偿振动缺失的手感。当然视觉补偿不能替代真正的触觉但它至少让iOS用户不会觉得“点起来轻飘飘”。4. 核心实现细节与实操要点4.1 反馈模式设计定义一套“手感词汇表”模式设计是整个buzz模块我认为最值得反复琢磨的部分。振动模式既不能太轻导致感知不到也不能太重导致像骚扰电话。我把常用模式分成几个层级每个层级服务于不同的交互场景。light级别对应最普通的按钮触摸反馈一般是15ms左右的单次短振。这个时长在Android上刚好能产生明确的触点感受不会让整机震动听起来像“嗒”一下。tap级别对应需要强调的离散操作比如开关切换、标签选择模式是[15, 30, 15]两下短促的振动足够让人知道切换生效了。confirm级别对应操作成功的确认模式是[30, 50, 30]比tap更加“稳”一点有明确的起止感。success级别对应流程完成的庆祝感比如抽奖结果弹出、任务达成模式是[40, 30, 15, 30, 40]这段模式在真机上听起来像“嗒—嗒嗒—嗒”比较有节奏。warning级别对应错误或强提醒模式是[80, 40, 80, 40, 80]振感强、时间长一般用于需要用户警觉的场景。每个模式我都用真机测过。要注意的是同一段模式在不同手机上的实际体验差异极大转子马达和线性马达的启动延迟不一样低端机反应迟钝、高端机干脆利落。所以不能把我们代码里的振动参数当成绝对标准只能在真机上反复微调找到绝大多数设备都能感知的区间。4.2 把werkzeug放在一边如何正确接入业务事件buzz模块本身不感知业务它只提供fire(type)这样的出口。但如何接入业务事件是有讲究的。我在项目里做了事件桥接层让业务方通过一个语义化的方法调用而不是直接操作振动对象。比如抽奖结果回来时业务代码是这样的function handleLotteryResult(success) { if (success) { vibrationManager.fire(success); } else { vibrationManager.fire(warning); } showResultModal(success); }调用方只关心是成功还是失败具体振多长时间、振动几次由buzz在内部决定。好处是当我们需要调整振动模式时只需要改模式表不需要满项目搜索调用点。随着页面越来越多不同页面可能对同一种反馈有不同偏好我还在模块里支持了全局模式和临时覆盖模式但默认情况下保证所有页面手感一致。4.3 页面生命周期与性能优化细节移动端页面的生命周期远比PC复杂振动模块必须对它敬畏。我把visibilitychange事件和一个页面卸载清理逻辑直接写进了模块内部。当页面不可见时立即调用navigator.vibrate(0)把振动队列清空防止用户把页面切后台后手机还在怀里嗡嗡响。document.addEventListener(visibilitychange, () { if (document.hidden) { vibrationManager.stop(); } });这段逻辑看起来简单但它解决了很多没做过振动开发的开发者不会想到的问题用户可能正在点按钮此时突然来电提醒页面切到后台如果没有清理逻辑振动会和来电冲突结果非常尴尬。性能方面振动API本身不涉及图形渲染但它经常在动画代码中触发。如果动画帧率本来就低再叠加振动调度可能会让低端机的页面更卡。我的建议是振动调用一律放在主线程的事件回调里不要频繁地在requestAnimationFrame循环里反复触发振动命令。还有一点不要在滚动容器里监听滚动事件来触发振动滚动频率太高这样既有性能问题也会因为连续振动让用户觉得页面“疯了”。如果需要滚动到某个位置时给一个反馈应该做节流。4.4 振动与音频反馈的联动单纯的手部振动再加上同步的音频反馈整体感觉会立刻立体起来。最简单的做法是同一个事件既触发振动又播放一个极短的音效。比如点击按钮时同时“嗒”一声和“嗡”一下反馈就非常完满了。但AudioContext在移动端的自动播放限制同样存在。Chrome要求必须先有用户手势才能解锁音频上下文。所以我在buzz里设计了一个统一的唤醒入口const audioCtx new AudioContext(); function playClickSound() { // 必须确保 audioCtx 已经处于 running 状态 if (audioCtx.state suspended) { audioCtx.resume(); } // 创建一个极短的 osc 音 const osc audioCtx.createOscillator(); const gain audioCtx.createGain(); osc.connect(gain); gain.connect(audioCtx.destination); osc.frequency.value 800; gain.gain.setValueAtTime(0.2, audioCtx.currentTime); gain.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime 0.05); osc.start(); osc.stop(audioCtx.currentTime 0.06); }注意这个audioCtx.resume()必须在用户点击事件里调用否则会被浏览器拒绝。同理振动API的执行也必须发生在用户手势链中。实际经验是把音频和振动放在同一个事件回调里让两条反馈同时触发减少因为异步拆开导致的违反手势策略风险。5. 实测过程与踩坑记录5.1 真机测试哪些设备振哪些设备不吭声做移动端开发模拟器永远代替不了真机。buzz模块的真机测试我专门拉了一张兼容性表把同事手上的备用机都借来测了一遍结果比caniuse的数据有意思得多。设备/浏览器是否支持振动实际体验Android 12 / Chrome 95支持振动干脆利落模式区分度高Android 10 / 小米浏览器支持振动偏“软”短振时感知较弱Android 11 / 微信内置浏览器支持部分WebView内核振动有效但响应有明显延迟Android 9 / 华为自带浏览器支持模式完全可用但长振被系统限制得比较短iOS 15 / Safari不支持静默失败navigator.vibrate是undefinediOS 15 / 微信内置浏览器不支持同上无振动无报错这里有个结论同样一段[30, 50, 30]在小米浏览器上感知很弱在最新Chrome上就很清楚。原因是线性马达和转子马达的差异以及各家系统对振动API的实现差异。所以做模式设计时不能只在一台高端旗舰机上调一定要拿几台中低端机做对照。5.2 踩坑一iOS Safari完全不支持怎么让测试通过iOS不支持在大部分项目里并不算Bug因为页面本身在iOS上可以正常运行只是没有振动反馈。问题在于如果产品经理和测试抱着“必须有反馈”的预期去验收就会被打回。我的处理办法是提前把降级方案做在前面并在项目文档里写明确iOS上使用按压缩放动画替代振动。这样测试验收时iOS上的确也能看到反馈不过是视觉层面的而不是触觉层面的。这个预期管理非常重要不然等到交付前才被发现又要手忙脚乱地补方案。5.3 踩坑二桌面浏览器调试时完全不振动开发时如果在桌面Chrome的开发者工具里模拟移动端设备navigator.vibrate在大部分情况下是存在的但调用后PC根本没有马达自然不会有任何反馈。所以很多人在电脑上调了一下午以为代码有问题其实只是桌面硬件不支持。解决方式用Android真机开启USB调试通过chrome://inspect远程调试页面的实际运行效果或者在本地局域网用手机直接访问开发服务器。真机上的反馈才是唯一的验证标准开发者工具只能用来验证API是否存在、参数是否正确。5.4 踩坑三连续触发振动变成一股又长又乱的振动这个坑我真正踩实过也是buzz模块引入lock锁机制的直接原因。假设用户连点三下按钮三次click事件各调用了一次fire(success)。如果不加控制浏览器会把三次振动模式塞进同一个振动队列振出来就是“嗡——嗡——嗡——”的长条完全失去了模式的意义。解决方案除了lock锁还有一个更精细的做法记录上一次振动的结束时间如果新请求到来时上一种模式还没振完先调用一次navigator.vibrate(0)清空队列再调用新模式。两种方案各有选择lock更适合“一次操作一个反馈”的交互而清队列适合“允许连续反馈但每次都要完整呈现”的场景。5.5 踩坑四页面里多个buzz实例互相打架早期代码里我图省事直接在组件里创建了多个VibrationManager结果A组件的振动还没结束B组件又振了一下整个页面的振动节奏全乱了。后来我把VibrationManager改成了单例模式整个页面只有一个入口才解决了这个互相覆盖的问题。这个教训让我想明白一件事像振动这种全局性的反馈通道就不应该设计成“每个组件私有”的东西。反馈是一套系统不是某种局部状态。这一点跟全局Toast提示是一样的道理你不希望页面上同时冒出十个Toast。6. 常见问题与排查技巧实录6.1 常见问题速查表我把实际运行中收集到的典型问题整理一下做成速查表方便后续维护的同学快速定位。问题现象可能原因解决方案Android上调用无反应页面不是HTTPS环境把页面部署到HTTPS或localhost下再测试页面刚加载时调用无反应没有在用户手势中调用将振动调用放在click/touchstart事件回调内iOS上完全不振动iOS Safari不支持Web Vibration API启用视觉缩放补偿反馈连续点击后振动变成一条长振多个振动请求叠加到振动队列加lock锁或先调用vibrate(0)清空队列页面切到后台还在振动没有监听visibilitychange清理振动在不可见时立即调用vibrate(0)微信内置浏览器中振动时有时无WebView内核版本差异或权限策略低优先级反馈可以放弃关键反馈使用强模式振动调用导致页面上出现报错navigator.vibrate不是函数先做能力检测typeof navigator.vibrate function设置的80ms长振实际振得比预期短系统/浏览器对连续振动时长有限制把长振拆成多个短振组合或降低对时长的预期6.2 排查思路从“不振动”到“振错了”遇到振动相关问题时我有一套固定的排查顺序。先确认协议环境看页面是否在HTTPS下再确认调用时机是不是在用户手势事件里接着确认设备能力navigator.vibrate是否存在最后确认队列状态是不是被之前的振动占用。这套顺序能解决70%以上的问题。还有个小技巧调试时在控制台手动执行navigator.vibrate([100, 50, 100])如果真机通过USB远程调试连接着直接就能在手机上感受到效果。这比反复刷新页面改代码高效得多。控制台执行时也是从用户手势上下文中调用的通常能通过浏览器策略限制。6.3 独家避坑千万别让buzz成为“报警器”在项目推广阶段我观察到一种滥用倾向业务方觉得振动很酷于是按钮、弹窗、轮播都加上了振动反馈。到最后用户打开页面手机像马达一样震个不停结果变成了负体验。后来我发起了一个“振动礼仪”约定只有真正需要用户感知节点时才启用振动普通滑动、次要按钮不加振动同一个交互流程内最多触发一次振动默认模式下振感不超过200ms。这个约定的效果立竿见影。页面整体的“手感”反而变好了用户能感知到的振动都是关键节点的信号而不是噪音。现在我把这条经验写进模块的Readme里作为使用规范的一部分。7. 这个模块后续还可以怎么扩展7.1 结合Gamepad API的探索Web平台上有另一个跟“反馈”相关的APIGamepad API它允许浏览器读取游戏手柄状态并且一些手柄带有振动马达可以通过navigator.getGamepads()拿到的hapticActuators来触发振动。虽然目前这个能力和移动端关系不大但如果页面未来要支持连接到手机上的蓝牙手柄这套震动反馈机制可以复用buzz的模式设计思路只是调用对象不同。7.2 长按振动与“模拟强度”原生API其实没有提供振动强度的控制只能通过振动时长和间隔来模拟。我后来做了一个长按交互的实验用户长按按钮时用setInterval循环执行短促振动并且随着长按时长增加逐步把振动时间从15ms加长到60ms。这样在手感上会产生一种“振动变强”的幻觉。虽然它不如原生触觉API细腻但在Web端已经是一种很实用的模拟方案。实现要点是interval的回调里同样要检查页面可见性和振动状态否则长按期间用户切到后台定时器还在触发振动就会造成持续的骚扰。7.3 把手感当成产品设计的一部分buzz模块做到后面我发现它已经超越了“调用一个API”的技术层面变成了一种设计语言。靠谱的反馈设计原则无非就三条短促、少次、有语义。短促指振动时长尽量短少次指单次操作只振一下有语义指每种反馈都要有明确的意义不能所有场景都用同一个模式。这几条我写在了模块的规范文档里新同学接手项目时先看文档就知道什么场景该用light、什么场景应该用success不需要靠猜。如果再重新做一遍这个模块我会把“反馈模式表”单独抽成一个配置文件方便运营配置不同的手感风格。目前的版本还是硬编码在代码里改动一次要发一次版。接口设计上也可以再抽象一层让buzz同时支持振动和视觉补偿两种输出由内部根据环境自动切换调用方完全无感。这个方向在Web标准演进之后说不定还能对接更底层的Haptic API。对我来说buzz这个项目的价值不只是让页面会振而是让我明白了一个道理反馈的终极目标不是“有多明显”而是“刚刚好”。