uni-app实现类似喜马拉雅的锁屏控制逻辑

在前端开发内容学习中，uni-app实现类似喜马拉雅的锁屏控制逻辑是常见主题。很多人在阅读时会遇到概念分散、步骤不清和注意点难以归纳的问题。本文按照基础概念、操作流程和关键细节，对相关内容进行整理。

锁屏后音频继续播放需用uni.createInnerAudioContext并配置autoplay=false、显式play()，Android需启用后台运行，iOS需配置requiredBackgroundModes=["audio"]；锁屏控制失效需原生设置audio session；进度同步须在canplay后seek并持久化状态。

锁屏后音频继续播放必须开启后台音频能力

uni-app 默认情况下，iOS 和 Android 应用在进入后台或锁屏时会暂停 Webview 中的 <audio> 播放，这是系统级限制。单纯靠 JS 控制 play() 无法绕过。关键前提是：你得让音频真正走系统原生音频通道，而不是仅依赖 H5 <audio> 标签。

实际做法是用 uni.createInnerAudioContext() 创建上下文，并配合以下配置：

• 设置 context.autoplay = false（避免 iOS 启动即播被拦截）
• 调用 context.src 后必须显式触发 context.play()
• Android 需在 manifest.json 中勾选「启用后台运行」；iOS 需在 manifest.json → "mp-weixin" → "requiredBackgroundModes" 添加 ["audio"]（仅 App 平台有效，H5 不支持锁屏控制）

锁屏界面媒体控制按钮不响应？检查 audioSession 配置

即使音频在后台跑起来了，锁屏界面的播放/暂停/上一首等按钮仍可能灰掉或无反应——这通常是因为没正确设置音频会话（audio session）行为。uni-app 自身不暴露底层 session API，需通过原生插件或条件编译补充。

Android 方面，需确保 AndroidManifest.xml 中声明了 android.permission.FOREGROUND_SERVICE，并在启动音频时调用 startForeground()；iOS 方面，除了前面提到的 requiredBackgroundModes，还需在 App.vue 的 onShow 中调用原生桥接方法设置 AVAudioSessionCategoryPlayback 和激活 session。

常见错误现象：MediaControl not available 或锁屏按钮点击无日志输出。此时检查是否漏掉 iOS 的 AVAudioSession 激活，或 Android Service 未提升为前台服务。

监听锁屏/唤醒事件只能靠平台原生能力

uni-app 的 onHide/onShow 在锁屏时并不可靠：iOS 上锁屏大概率不触发 onHide，Android 行为也不一致。不能依赖这些生命周期做状态同步。

可行方案是通过条件编译接入原生模块：

• iOS：用 UNNotificationServiceExtension + MPNowPlayingInfoCenter 更新当前播放信息，并监听 UIApplication.willResignActiveNotification 和 UIApplication.didBecomeActiveNotification
• Android：用 AudioManager 监听 AudioManager.ACTION_AUDIO_BECOMING_NOISY，或注册 Intent.ACTION_SCREEN_OFF/Intent.ACTION_SCREEN_ON（需动态权限）

注意：H5 环境完全无法监听锁屏事件，visibilitychange 只能判断页面是否被切换，不能区分锁屏和切应用。

进度同步与状态持久化容易断连

用户锁屏后切到其他 App，再回来时经常发现播放进度“跳回开头”或状态错乱。这不是 UI 渲染问题，而是音频上下文在后台被系统回收后重建导致的。

解决思路不是“保存播放时间”，而是“恢复播放上下文”：

• 每次调用 context.play() 前，先记录当前 src、currentTime、volume 到 uni.setStorageSync
• 在 onShow 或原生唤醒回调中，重新创建 uni.createInnerAudioContext()，再 context.src = savedSrc，再 context.seek(savedTime)，最后 context.play()
• 特别注意：iOS 上 seek() 必须在 canplay 事件后执行，否则无效；建议加 context.onCanPlay(() => { context.seek(...) })

真正的难点不在代码逻辑，而在于不同机型对后台音频资源的回收策略差异极大——有些 Android 机型锁屏 10 秒就 kill audio context，这时候光靠 JS 层保存状态根本来不及恢复。