本篇涉及到的几个坑（以下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()事件内跳转到上次暂停的时间点