H5 audio 标签
目录
背景
没错,前端天才终于涉及了真正的前端h5页面!
需求是优化一个两年前别人写的播放器!
可是坑死我了···
audio
- 几个重要的方法
play
加载并播放音频或重新播放暂停的的音频pause
暂停处于播放状态的音频文件
- 几个重要的回调
waiting
无法直接播放,加载canplay
缓冲至目前可播放状态play
play()和autoplay播放时timeupdate
播放时间变化ended
播放结束
一个简单的播放器逻辑
-
一个友好的用户交互
- 监听 waiting 事件,展示 loading 弹窗
- 监听 canplay 事件,取消 loading 弹窗
- play 和 pause 事件就不用说了,控制播放和暂停
- 监听 timeupdate 事件,调整进度条进度
- 监听 ended 事件,播放下一首,重置一些你需要的状态值
-
坑一:如何自动播放
- 受限于
webview的设置
,不知道有没有什么 hack 的方式,但是 hack 的方式始终是不稳定的。如果 webview 不允许自动播放音频,那么我们进入当前页面是不会自动播放音乐的,autoplay 无效,自己调用 play() 方法也无效,不用质疑自己的代码是否有问题。
- 受限于
-
坑二:想做个缓存播放的功能
逻辑很简单,每次暂停被调用,或者页面退出事件,缓存播放进度进localstorage
,第一次进来的时候 load 一下缓存,问题却并不少···- 进度加载不了
- 播放进度读出来并且给
audio.currentTime
赋值,但是 currentTime 的值始终是0
,无法被改动。一开始,直接在 audio.play() 后面给 currentTime 赋值的,后来放到 canplay 回调里面正常了,也懒得看源码了,感觉肯定是哪个回调里面把 currentTime 重新赋值了,或者对象根本都不是同一个了???这个看看源码就很清晰了 - canplay 回调里面,load 进度赋值给 currentTime,iOS 一切正常。但是到了 android,
waiting和canplay两个回调疯狂互相调用
,配上我们在 waiting 和 canplay 两个回调里面,展示和隐藏弹窗,我们的界面就开始鬼畜了起来。同样,这个需要去看源码,为何会发生这种事情,而 iOS 就没有。当然,即使不知道源码流程,这个问题我们也可以修改的啊,加一个状态值
,load 只 load 一次,就 Ok 了。
- 播放进度读出来并且给
- 进度加载不了
开发前端的体验
总体来说开发起来感觉很简单,但是由于开发工具没搞好,想看源码难度也挺大,而且有很多语法看不懂,问了很多前端同事,他们也无法给我答案。
也反映了一些问题吧,因为前端过多的库,让前端工程师很少的去研究源码了
总之,我写的第一个H5终于上线啦!!!