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

编辑文章

标题 *

URL 别名 *

内容 * (支持 Markdown 格式)

# 几种方法可以尝试保持 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**（烧屏问题），除非是特殊用途的内部工具。

配图 (可多选)

选择新图片文件或拖拽到此处

标签