微信小程序播放器采坑总结
基本使用
获取全局播放器
1 | const audio = wx.getBackgroundAudioManager() |
基本属性介绍
src
(播放源)1
audio.src = 'https://xxx.mp3' // 设置播放源,设置后会自动播放,无法停止(除非手动停止)
startTime
(开始播放位置)1
audio.startTime = number // 对于播放记录非常有用,该属性必须在设置src后设置才生效
ps: 设置以后再切换章节时记的重置为 0,否则一直会从 number 出开始播放
property
(播放器信息属性)1
2
3
4
5audio.coverImgUrl = '资源封面'
audio.singer = '播音者'
audio.title = '章节名称'
audio.epname = '资源名称(书籍 或 节目)'
// 一般设置这4个属性就够了,这4个属性是给微信提供的系统播放器使用的
监听方法介绍
onCanplay
: 监听背景音频进入可播放状态事件。但不保证后面可以流畅播放1
2
3
4
5
6
7
8audio.onCanplay(() => {
const timer = setInterval(() => {
if (audio.duration !== undefined) {
// do someting
clearInterval(timer)
}
}, 100)
})onError
: 监听背景音频播放错误事件该事件在 Android 与 iOS 平台的触发略有差异,设置一个无效的地址后,iOS 端会立即触发错误事件,Android 端并不会立即触发,而是等待一段时间后才会触发,并自动返回
onStop
: 监听音频停止事件触发事件的场景:
(1)audio.stop()
(2) 系统播放器关闭按钮
(3) 开发工具模拟器音频关闭
(4) 切换音频时(坑点)需要注意的问题:
(1) 如果此时正在播放一个音频,点击切换另一个音频,此时会触发stop
事件,如想要在stop
时返回上一页 需要兼容此问题
播放器坑点介绍
store无法获取新值
现象:在播放器页设置监听事件后,播放器页出栈,此时的监听逻辑依然会执行,但是会有一些问题,例如 通过系统播放器 更新 store 状态,此时 store 会更新,但是监听逻辑获取不到更新后的值(原因不明)
应对: 目前的 hack 方法是在每一个页面都加上相应的监听事件,具体可以写在一个组件中,然后全局引用。(不是办法的办法)
监听事件覆盖问题(针对单一事件、不是全部覆盖)
现象: 播放器页监听 onCanplay
事件,播放器页出栈,到 A 页面,A 页面也监听 onCanplay
事件,此时只会触发 A 页面对应的监听逻辑,播放器页的监听被覆盖
应对: 此行为并非 bug, 做好兼容即可。
audio 与 系统播放器的 (恩怨情仇)
现象: 本次的小程序项目 播放器相关的疑难 bug 十有八九是跟系统播放器的行为有关,在系统播放器与小程序播放器页之间来回切换非常容易出现各种想不到的问题。
应对: 说实话这个没有什么好的推荐方法,后续如有好的设计,请多多分享。唯一可以说的就是在写逻辑的时候,一定要注意 类型判断、容错处理、兼容各种异常情况,保障变量值正常就已经成功了一大半了。
播放器设计
本次播放器设计是通过场景值来实现, 具体为
- 资源详情页进入 — 正常行为
- 我的页(收听记录)进入 — 从指定位置开始播放
- mini 播放器(暂停)进入 — 类似 2 但是需要保持暂停状态
- mini 播放器(正在播放)进入 — 继续播放
- 分享落地页进入 — 同 1
播放器页通过不同的 scene 值来实现不同的行为
本次播放器的不足
- 页面会有卡顿的现象(可能跟内容有关系,需要后续逐步优化)
- 播放器与详情页的页面栈设计不是很好,虽然基本功能已经实现,但是在一些非旗舰机使用上离 喜马拉雅 lite 还有差距。(需要更好的设计)
- 收听记录模式,本次的收听记录全部存在 storage 里,登录后才会同步一次。这种模式还有待商榷。顺便吐槽一句:存在 ID 相同的书籍和节目(简直没想到,后来唯一键改用 ID 与 type 两个来确定)。
- 总的来说还是可以的,但是改进的空间也是相当的大。