详解小程序BackgroundAudioManager踩坑之旅

由于贵公司业务发展需要，切图仔开始写起了小程序啦（兴奋地搓小手手）

贵公司是知识付费平台，需要音频播放课程，同时希望用户在退出小程序后依然可以听课。在这种情况下，小程序的API——BackgroundAudioManager就派得上用场啦。

在看完官方文档，信心满满地写完提测后，测试小姐姐找出的bug比我的工资还多！！（😭😭😭）因此有了本篇文章。

本篇涉及到的几个坑（以下BAM为BackgroundAudioManager的缩写）

• 一个误区
• BAM.onStop() 与 BAM.onEnded() 的坑
• BAM.seek() 与 BAM.onSeeked() 的坑
• BAM.onTimeUpdate() 的坑
• 在音频页退出小程序暂停音频后返回小程序的坑

一个误区

• BAM.onCanplay()是监听背景音频进入可播放状态事件，并不代表在该事件中，音频就为播放状态。
  

BAM.onStop() 与 BAM.onEnded() 的坑

在BAM.onStop() 与 BAM.onEnded()的回调事件中，audio.src为空

BAM.onStop()： 当再次播放音频时，将data数据中音频的src赋值给BAM，然后在onTimeUpdate()事件内跳转到上次暂停的时间点（记得本地缓存音频播放时间哦～）

BAM.onEnded()：在BAM.onEnded()回调函数中，将data数据中音频的src赋值给BAM，然后在onTimeUpdate()事件内暂停音频

BAM.seek() 与 BAM.onSeeked() 的坑

• 设置src后立即seek()失效

seek操作最好放在BAM.onTimeUpdate事件中。 类似HTML的Audio元素的ontimeupdate方法，建议将currentTime的改变都在该方法中进行。

• 暂停状态下跳转到指定位置，在onSeeked()回调中，Android的currentTime是跳转前的时间，而IOS是跳转后的时间

虽然在onSeeked()回调函数中，Android获取currentTime为跳转前的时间，但若开始播放，还是从指定位置开始播放。所以若有暂停连续跳转并需要获取currentTime的需求，可在onSeeked()回调函数中判断若为Android并且为暂停状态时播放。

• 开发者工具不走onSeeked()回调

如果在onSeeked()回调里面有特殊操作，记得区分是否是开发者工具～

BAM.onTimeUpdate() 的坑

在退出小程序后，Android与IOS均不走onTimeUpdate()事件

因此若在onTimeUpdate()事件内实时缓存音频的播放时长会导致在退出小程序暂停后返回拿到的音频缓存时间是退出前的时间。可以在onPause()与onEnded()事件中记录暂停时的音频播放时长。（在onTimeUpdate()事件内所做的操作可根据实际情况考虑节流哦～）

在音频页退出小程序暂停音频后返回小程序的坑

IOS：BAM.src为空

Android：BAM.src不为空，但play()失败

这点与第二点的处理方式相同。当在音频页退出小程序暂停音频后返回，进入onShow()事件时，将data数据中音频的src赋值给BAM，然后在onTimeUpdate()事件内跳转到上次暂停的时间点

原本以为可以写的会有很多，最后写下来也就几个点，表达的不也是很清晰，就当学习日记吧