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反馈其他的型号✌️
网友评论