
本文探讨了在移动设备锁屏时 web 音频播放中断的根本原因,并提供基于现代浏览器能力的可行方案,包括利用 `audiocontext` 恢复策略、`mediasession` api 增强控制力,以及对系统唤醒锁(system wake lock)等前沿标准的实践展望。
在构建 Web 端类原生音乐播放器时,一个常见却棘手的问题是:当用户锁屏后,JavaScript 事件循环被浏览器主动挂起或降频,导致 ended 事件无法触发、src 切换失败,音频队列播放中断。这并非代码逻辑缺陷,而是移动浏览器(尤其是 Firefox for Android、部分 iOS Safari 版本)为省电而实施的后台限制策略——即使使用
✅ 核心解决方案:利用浏览器“媒体播放豁免”机制
现代移动浏览器(Chrome/Edge on Android ≥ v84,Safari on iOS ≥ 15.4)对已进入播放状态的 提供后台运行豁免:只要首次播放由用户手势(如点击)触发,且后续操作不中断媒体上下文,浏览器会允许音频持续播放并响应 ended 事件,即使屏幕锁定。
关键实践要点如下:
-
必须由用户手势触发首次播放(不可自动播放):
const audio = document.querySelector('#player'); let queue = ['song1.mp3', 'song2.mp3', 'song3.mp3']; let currentIndex = 0; // ✅ 正确:绑定到按钮点击 document.getElementById('play-btn').addEventListener('click', async () => { try { await audio.play(); // 首次播放需 await Promise setupQueue(); } catch (err) { console.error("Playback failed:", err); } }); function setupQueue() { audio.addEventListener('ended', () => { currentIndex = (currentIndex + 1) % queue.length; audio.src = queue[currentIndex]; audio.play().catch(e => console.warn("Auto-play blocked:", e)); }); } -
保持 AudioContext 活跃(可选但推荐)
某些场景下(如混音、可视化),显式管理 AudioContext 可增强稳定性:let audioContext; function resumeAudioContext() { if (audioContext?.state === 'suspended') { audioContext.resume().catch(e => console.warn("Resume failed:", e)); } } // 在 play() 后及 ended 回调中调用 resumeAudioContext() -
启用 MediaSession 提升系统级兼容性
设置元数据可提升锁屏界面显示效果,并间接强化播放生命周期管理:if ('mediaSession' in navigator) { navigator.mediaSession.metadata = new MediaMetadata({ title: 'Track 1', artist: 'Artist Name', album: 'Album Title', artwork: [{ src: '/icon-192.png', sizes: '192x192' }] }); // 可选:处理锁屏界面的播放控制 navigator.mediaSession.setActionHandler('nexttrack', () => { // 手动触发下一曲(增强健壮性) audio.dispatchEvent(new Event('ended')); }); }
⚠️ 注意事项与边界情况
- iOS Safari 限制更严格:即使满足上述条件,部分 iOS 版本在长时间锁屏(如 10+ 分钟)后仍可能暂停 JS;建议配合 setTimeout 心跳检测(非精确,仅作兜底)。
- Web Workers 无法直接播放音频:Worker 中无 HTMLMediaElement 或 AudioContext,不能替代主页面播放逻辑。
- Screen Wake Lock ≠ 解决方案:该 API 仅防止屏幕熄灭,不保证 JS 继续执行,且需用户授权、违背 UX 原则,不推荐用于纯音频场景。
- System Wake Lock 尚未落地:W3C 正在推进的 System Wake Lock API 理论上可维持 CPU 活跃,但截至 2024 年仍处于提案阶段,无主流浏览器实现,不可用于生产环境。
✅ 总结:稳态实践路径
| 措施 | 是否必需 | 说明 |
|---|---|---|
| 用户手势触发首次 play() | ✅ 必需 | 浏览器强制要求,否则静音/阻断 |
| ended 事件链式切换 src | ✅ 必需 | 标准且轻量的核心逻辑 |
| MediaSession 元数据配置 | ✅ 强烈推荐 | 提升锁屏体验与系统兼容性 |
| AudioContext.resume() 调用 | ⚠️ 按需添加 | 针对含 Web Audio 的复杂场景 |
| 屏幕常亮或 System Wake Lock | ❌ 不推荐 | 无效或不可用,违背设计原则 |
最终,稳定实现锁屏连续播放的关键在于尊重浏览器媒体策略——以合规方式启动播放、善用系统提供的媒体生命周期豁免机制,而非试图绕过限制。随着 Web 标准演进(如 Background Fetch、Periodic Sync 的未来整合),长期方案将更成熟,但当下,上述实践已在 Chrome、Edge、Safari 主流版本中验证有效。










