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终于上线啦！！！