我不想再踩坑了：蘑菇视频官网的后台播放这样设置更稳

我不想再踩坑了：蘑菇视频官网的后台播放这样设置更稳

作为做过多个在线视频/音频项目的运营与技术协调人，花过不少时间帮产品把“前台能播，后台就能稳播”这件事从概念变成稳定上线的功能。下面把蘑菇视频官网在实现后台播放时最实用、最不容易踩坑的方案整理成一份可直接落地的操作指南，既有前端实现技巧，也有移动端及原生 App 的配合要点，最后附上常见问题与排查方法，方便发布前逐项验证。

为什么要把后台播放做好（一句话）

• 用户希望在切换应用或锁屏时，视频的声音能继续播放，体验更连续；做好这点能提升留存、提升付费转化率、并减少用户投诉。

先看结论（发布前的最小可交付清单）

• 若目标是仅保留声音：优先提供 audio 流而非 video 元素。
• 必须用户主动触发播放（首次播放需用户手势），之后在后台能持续播放。
• 在网页端接入 MediaSession API（提供锁屏控制和通知栏信息）。
• 对 iOS 做特殊兼容（Safari 对 video 在后台策略不同）。
• 在原生 App 或 WebView 场景，配合设置允许后台音频（Android/iOS 各自配置）。

前端实现（官网优先推荐） 1) 明确需求：是“视频在后台也看得到画面”还是“切后台保留声音”？

• 大部分场景用户只是想继续听声音：把播放切换到 audio 流会更稳。
• 要在后台继续保留画面几乎不现实（手机系统会挂起视频渲染），应改为分离音轨策略。

2) 优先用 元素承载播放（示例思路）

• 用户点击播放后，创建或激活 audio 元素来播放音频源（可以是视频的音频流或单独的音频文件）。
• 优点：浏览器对 audio 比 video 在后台播放支持更好；在锁屏时能继续输出声音。
• 简单示例： var audio = document.createElement('audio'); audio.src = 'https://your.cdn.com/path/to/audio.mp3'; audio.play().catch(function(err){ /* 处理未授权自动播放 */ });

3) 对 HLS（m3u8）场景的处理

• Safari（iOS/macOS）原生支持 HLS，可以直接给 audio/video 源指向 m3u8。
• 其他浏览器使用 hls.js：在创建 audio 元素后，使用 hls.js attachMedia(audio) 播放。
• 确保 CDN 支持 CORS，否则 hls.js 会失败。

4) MediaSession API（极大提升体验）

• 在支持的浏览器中设置 navigator.mediaSession.metadata 与 action handlers，可在锁屏或通知栏显示专辑图、标题，并响应播放/暂停/下一首等控制。
• 简单示例： if ('mediaSession' in navigator) { navigator.mediaSession.metadata = new MediaMetadata({ title: '标题', artist: '作者', artwork: [{ src: 'cover.jpg', sizes: '512x512' }] }); navigator.mediaSession.setActionHandler('play', function(){ audio.play(); }); navigator.mediaSession.setActionHandler('pause', function(){ audio.pause(); }); }

5) Autoplay 与用户手势

• 现代浏览器普遍禁止未经用户交互的自动播放（尤其含音频），因此先引导用户完成一次明确点击（比如“点击播放”大按钮），之后由该播放上下文维持会话。
• 可用“静音自动播放 + 用户解静音”作为过渡，但体验不佳且存在兼容风险，实操上尽量采用明确点击。

移动端浏览器兼容要点

• iOS Safari
• video 在切后台或锁屏时常被挂起；若想后台播放，应该使用 audio 元素或在 webapp（添加到主屏后的独立模式）中结合 audio。
• 在 video 元素上加上 playsinline、webkit-playsinline 可以阻止全屏，但是并不保证后台继续播放音频。
• 结论：把播放源暴露成 audio（或拆分音轨）更稳。
• Android Chrome
• audio 元素在切到后台或锁屏时通常能继续播放。结合 MediaSession，可在通知栏显示控制。
• PWA/添加到桌面后表现更接近原生。

原生 App / WebView 场景（如果官网有配套 App）

• Android
• 在原生播放器中使用前台服务（foreground service）或 MediaBrowserService + MediaSessionCompat，声明播放权限与前台通知，能够在锁屏和后台维持音频。
• 注意 Android 电池优化（Doze）可能影响长期后台运行，建议配合前台服务与正确的 Notification。
• iOS（原生）
• 在 Xcode 的 Capabilities 中开启 Background Modes -> Audio，使用 AVAudioSession 并设置为 Playback category，确保在锁屏或切后台时继续播放。
• WebView
• 原生容器需要允许音频后台播放（Android 的 WebView 可能需要配置 setMediaPlaybackRequiresUserGesture(false) 并在 App 层允许后台播放；iOS 的 WKWebView 需设置 allowsInlineMediaPlayback 等）。

常见坑与排查（踩过的坑和解决办法）

• 坑：用 video 元素直接期待后台播放 → 结果：iOS、部分浏览器会直接暂停渲染或暂停播放。
• 解决：切换到 audio 元素或提供音频专流。
• 坑：首次播放依赖自动播放失败，用户抱怨不能后台播放。
• 解决：把首屏交互设计得明确，使用明显的“播放”按钮并在用户触发后完成播放初始化。
• 坑：第三方广告/分析 SDK 干扰播放线程，或浏览器因后台限制停止计时器，导致播放控制失效。
• 解决：把播放控制尽量放到原生 audio + MediaSession，避免通过 setInterval 等依赖前台计时的逻辑来维护播放。
• 坑：HTTPS / CORS 问题导致 hls.js 或跨域资源失败。
• 解决：确认所有媒体资源走 HTTPS，且服务器返回正确的 CORS 头。
• 坑：电池优化策略在 Android 上杀死进程，导致后台不稳。
• 解决：在 App 层面处理白名单或使用前台服务；网页端建议引导用户通过 App 或 PWA 方式获得更稳定体验。

上线前的测试矩阵（至少覆盖这些设备/场景）

• iPhone Safari（正常网页 + 添加到主屏幕后的独立模式）
• Android Chrome（常规）
• Android 原生 WebView（若有 App）
• 屏幕锁定、切换到其他应用、接听来电、切换网络（Wi‑Fi ↔ 蜂窝）
• 使用不同网络类型（HLS 低带宽切片是否能无缝切换）

小结（快速回顾）

• 若目标是“切后台也能继续听声音”，第一选择是把播放交给 audio 元素或音频流，配合 MediaSession。
• 要求用户主动触发一次播放，之后后台播放通常能保持稳定。
• iOS 对 video 的后台策略最挑剔，官网实现时要以 audio 优先思路兼容处理。
• App 场景下，通过原生后台音频权限能获得最稳定的体验。