几种方法可以尝试保持 PWA 在后台活跃

除了“静音振荡器”这种利用 Web Audio API 的黑科技外，确实还有其他几种方法可以尝试保持 PWA 在后台活跃。

但需要明确的是：移动操作系统（iOS 和 Android）的设计哲学是“痛恨”后台网页的。为了省电和隐私，系统会想方设法杀掉后台页面的 JS 线程。因此，几乎所有纯 Web 方案都带有一定的“Hack（破解）”性质或特定的局限性。

以下是目前主流的替代方案及其评估：

1. Picture-in-Picture (PiP) API —— 画中画模式

这是目前最“官方”、最合规的后台保活方案，特别适合视频类应用（如 YouTube 播放器）。

• 原理：调用 videoElement.requestPictureInPicture()。浏览器会将视频弹出一个悬浮小窗口。
• 保活逻辑：只要屏幕上有这个悬浮窗（哪怕它很小），操作系统就会认为用户正在观看视频，因此必须保持网页的活跃状态，不仅视频流不会断，与其关联的 JS 逻辑（如进度条更新、自动播放下一首）也能继续运行。
• 优点：
  • 省电：比强制屏幕常亮省电。
  • 合规：这是 W3C 标准 API，不会被浏览器封杀。
  • 稳定：iOS 和 Android 都完美支持，基本不会被杀后台。
• 缺点：
  • 需要用户交互：不能自动触发，必须用户点击按钮。
  • 视觉干扰：屏幕上必须有个窗口（虽然可以拖到角落），对于纯听歌用户来说可能有点碍眼。
  • 内容限制：主要针对 Video 元素。

2. Screen Wake Lock API —— 屏幕唤醒锁

这是一种“曲线救国”的方法：既然后台会被杀，那我就不进后台。

• 原理：调用 navigator.wakeLock.request('screen')。这会阻止屏幕变暗或自动锁屏。
• 保活逻辑：只要屏幕亮着，网页就是前台应用，拥有最高优先级的 CPU 资源，JS 永远不会停止。
• 优点：
  • 极其稳定：绝对不会被打断。
  • 实现简单：一行代码即可。
• 缺点：
  • 烧屏且费电：屏幕必须一直亮着（虽然可以调暗），对 OLED 屏幕不友好，电池消耗大。
  • 口袋误触：手机放口袋里容易误触。
  • 非真正后台：这本质上是“前台保活”，不是“后台保活”。

3. Geolocation API Hack —— 地理位置追踪

这是网约车司机端或导航软件常用的权限，早期很多网页游戏也用它来保活，但现在极不推荐用于音乐播放器。

• 原理：申请 watchPosition 持续获取用户 GPS 位置。
• 保活逻辑：如果网页正在导航或追踪位置，操作系统（特别是 iOS）会赋予其后台运行权限。只要 GPS 图标在状态栏亮着，JS 就能一直运行。
• 优点：保活效果非常强悍。
• 缺点：
  • 隐私红线：用户会看到状态栏有蓝条或绿点提示“正在使用位置”，对于一个音乐 App 来说，这极其可疑，用户容易产生不信任感。
  • 耗电大户：GPS 硬件非常耗电。
  • 审核风险：如果要做成 PWA 上架商店，这种非必要权限会被拒。

4. Service Workers & Background API (仅限特定场景)

这是 PWA 的“正规军”路线，但不适合实时媒体播放逻辑。

• Background Sync API：用于在网络恢复时重发请求（如发离线消息）。它只能短暂唤醒 SW，不能持续运行。
• Background Fetch API：用于后台下载大文件（如缓存一整部电影）。它可以下载，但不能运行播放逻辑。
• Push API：服务器发送推送通知唤醒 SW。虽然能唤醒，但时间极短（几秒钟），不适合维持播放。
• 结论：这些 API 是为了“任务（Task）”设计的，而不是为了“会话（Session）”设计的。

5. Web Lock / Worker Loop (Web Worker 黑科技)

利用 Web Worker 线程进行死循环或高频计时。

• 原理：主线程容易被挂起，但 Web Worker 有时能存活更久。
• 现状：现代浏览器（尤其是 Chrome 80+ 和 iOS 14+）已经修补了这个漏洞。当主页面不可见时，关联的 Worker 也会被降频（Throttling）甚至冻结。现在通常需要配合 setInterval 的特定频率（如 1秒）才能勉强维持，效果不如 AudioContext 稳定。

6. 封装为 TWA (Trusted Web Activity) 或 Hybrid App

如果想要完美的后台体验，最终的解决方案通常是“套壳”。

• 原理：使用 Android 的 TWA 技术，或 Capacitor/Cordova 框架，将 PWA 包装成一个原生 APK/IPA 包。
• 保活逻辑：此时应用变成了原生应用，可以调用原生 Android/iOS 的后台服务（Service）或原生音频播放器。
• 优点：
  • 完美解决后台保活。
  • 可以上架应用商店。
• 缺点：
  • 不再是纯粹的 Web URL，需要打包、签名、安装。
  • 增加了开发复杂度。

总结建议

对于**纯 Web 端（直接浏览器打开）**的音乐播放器：

1. 首选：Web Audio API（静音振荡器）。目前性价比最高，用户无感知，兼容性最好。
2. 备选/辅助：Media Session API。虽然它本身不保活，但必须配合 Audio 使用，提供锁屏控制，增加系统认为“这是媒体应用”的权重。
3. 特定场景：Picture-in-Picture。如果你主要播放视频（MV），引导用户开启画中画是最稳定的方案。

不要尝试 Geolocation（隐私问题）和 Wake Lock（烧屏问题），除非是特殊用途的内部工具。