1.讲个故事 主角不是我
你收到一个video播放的各种统计需求,播放开始打点...播放结束打点...你心理暗自发笑?这是事吗?用不了一泡尿的功夫就搞定了,紧接着你打开了谷歌
html5 video 事件
看!这篇文章真不错各种事件,什么都有,ended 搞定 加上不就完了😕
于是你兴冲冲写下
let dom = document
let videoDom = dom.querySelector('#video-player')
videoDom.play()
videoDom.addEventListener('ended', function(event) {
alert('报!')
})
满怀期待 等着浏览器报的时候 你傻了 我特么报呢???那么大一个‘报’字呢!!怎么没有蹦出来!!!视频都特么播了360遍了!耍流氓吗!!
于是你回到那篇文章,非常愤怒💢的评了一句:cao!垃圾!根本不好使!骗子!
别急少年!🐔你特么肯定是没看过标准!!!人家原话咋说的?
https://www.w3.org/TR/2011/WD-html5-20110405/video.html#video
讲的多明白,你检查检查哪错了??
😯是不是带上loop了??
2.我就要Loop我还要End
通过标准定义我们知道,ended指的是播放结束,这个结束指的是视频死的透透的,此时的你可能想,好吧,既然这样那我就要么模拟loop要么模拟end手动触发呗。
等等少年!别冲动!不再仔细读读吗,看看其他事件呗,万一可以偷懒呢?
标准列表在这里 通过阅读事件我们发现有三个在标准描述下有点意思,拎出来说一下挑选挑选
playing 事件,这哥们当你播放开始、播放暂停后开始、拖拽进度条再播放(其实本质都在标准描述里)就会触发 所以它……不行🙅
canplaythrough 事件,通过谷歌翻译……哦不……通过我英语四级的翻译,它的意思是浏览器掐指一算,good 这个视频可以不缓冲的再次重播,什么时候算?当你拖拽进度条以及视频自己切换播放状态的时候(记得阅读标准本质,这里只是说明行为),所以当没有进度条给用户用的时候,它倒是可行的🤔
waiting 事件,这哥们是当下一帧无法播放时触发,为什么这一帧无法播放,可能是播放结束了,也可能是播放报错了。如果你的视频不大,几乎不会因为报错而无法播放,那这个事件也是可行的🤔 ps:这里有个特殊情况 就是快进播放 也会造成下一帧还没缓冲而无法播放 注意
用户无法控制播放进度,视频低码率不大,遇错情况少,在这种情景下,偷懒能扯的看来只有canplaythrough和waiting
这时我们需要再检查下 这两个事件 在各种user-agent下 都能触发不……
标准坑完--实现坑--标准坑完--实现坑--标准坑完--实现坑
你打开那篇被你喷完垃圾的文章,虽然没发现对waiting和canplaythrough的描述,但是通过模拟loop和模拟end的方式被pass了(或者你分平台处理,ios兼容总是比android好一些🤷♂️)……
我们只能通过实机去监测了,这里要说一下waiting在开始时就会触发一次,所以建议对waiting做一个计数,除第一次外再上报就好了。
===========
我去做个测试先 测完了回来补 坑
===========
手头的测试机 完美……等qa反馈其他的型号✌️