video标签移动端的坑

场景一：自动播放

autoPlay 布尔属性；指定后，视频会马上自动开始播放，不会停下来等着数据载入结束。

视频自动播放可以在页面打开且资源加载足够的情况下让视频自动播放，减少一次用户点击的交互，同时可以应用在动效背景、H5仿视频通话的功能。不过由于各种原因，自动播放无论在PC端还是移动端都有不同程度的限制。

移动端
IOS

早期必须要有用户手势（user gesture）video标签才可以播放； 从版本10开始修改了video的规则，苹果放宽了inline和autoplay，策略如下（仅适用于Safari浏览器）：

安卓
早期同样需要用户手势才可以播放； 安卓的 ****chrome 53 后放宽了自动播放策略，策略不同于IOS的Safari，需要同时对 video 设置 autoplay 和 muted（是否禁音），才允许自动播放； 安卓的 FireFox 和 UC 浏览器支持任何情况下的自动播放； 安卓的其他浏览器暂时不清楚情况；

PC端
早期是支持自动播放，但近来 Safari、Chrome 陆续修改了自动播放的策略……

Safari 浏览器
Safari 10 后带音频的视频和音频默认禁止自动播放，更多信息可以参考这篇文章（https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/）；

Chrome 浏览器

禁音的视频依旧可以播放，�带声音的视频会根据媒体参与指数来决定能否自动播放，那什么是媒体参与指数？官方给了解释和相关的维度：

MEI 是一个评估用户对于当前站点的媒体参与程度的指数，它取决于下面几个维度:

用户在媒体上停留时间超过了 7秒以上
音频必须是展示出来，并且没有静音
与 video 之间有过交互
媒体的尺寸不小于 200×140.

检测能否自动播放？
好在无论是 Safari 还是 Chrome，在限制了自动播放的同时，提供了检测视频是否能自动播放的机制，以便于开发者在发现无法自动播放时有备选方案：

var promise = document.querySelector('video').play();if (promise !== undefined) {    promise.catch(error => {        // Auto-play was prevented        // Show a UI element to let the user manually start playback    }).then(() => {        // Auto-play started    });}

为什么早期禁止视频自动播放？
because it can be disruptive, data-hungry and many users don’t like it. (因为它是破坏性的、需要大量流量同时很多用户不喜欢它)

为什么又允许自动播放？
有些开发者使用其他方式如 canvas、gif 等来实现视频自动播放的效果，但是性能上、流量消耗上都远不如视频播放；

现在流量便宜了、手机硬件越来越好了；

用户可以通过设置来禁止自动播放（开启省流量模式等）；
为什么 IOS 下微信和钉钉可以自动播放带声音的视频？
确实发现在微信经常能看到自动播放的H5，但是作者自己写的设置了 autoplay、playsInline 的视频播放样例，在微信上依旧无法自动播放，而在钉钉上却可以自动播放

通过查询资料，IOS WebAPP 开发都是基于 IOS 提供的浏览器内核进行开发的，所以在 WebAPP 的 webview 中可以修改自动播放的表现，钉钉明显是支持自动播放，微信则是禁止自动播放，但是提供了内置事件来支持自动播放：

微信下通过 WeixinJSBridgeReady 事件进行自动播放：

document.addEventListener(  'WeixinJSBridgeReady',  function() {    video.play();  },  false);

场景二：全屏处理

在移动端浏览器， video 在用户点击播放或者通过API video.play() 触发播放时，会强制以全屏置顶的形式进行播放，设计的初衷可能是因为全屏能提供更好的用户体验，但有时候开发者希望能自己控制是否全屏从而实现其他需求。

playsinline 取消全屏
如果想实现不全屏播放，只需在video标签加个 playsinline 属性即可，这个属性在基于webkit内核的移动端浏览器基本没问题，实在不行就再加个 webkit-playsinline ：

<video    src={videoUrl}    webkit-playsinline="true"    playsinline="true"  />

那么对于其他内核的浏览器要怎么处理呢？这个时候要了解下目前市场上存在的浏览器有哪些。

playsinline 兼容性
首先要知道全球目前四个浏览器内核：

微软IE的Trident

网景最初研发后卖给Mozilla基金会并演化成火狐的Gecko

KDE的开源内核Webkit

Opera的Presto

其中：

Trident在移动端主要为WP7系统内置浏览器

Presto 在所有联网设备上都使用，移动终端上主要为 Opera Mobile、OperaMini、欧朋浏览器以及欧朋HD Beta版

Webkit内核的适用范围则较为广泛，Android原生浏览器、苹果的Safari、谷歌的Chrome(Android4.0使用)都是基于Webkit开源内核开发的。

而国内常见的PC浏览器如UC浏览器、QQ浏览器、百度手机浏览器、360安全浏览器、谷歌浏览器、搜狗手机浏览器、猎豹浏览器以及移动端的UC、QQ、百度等手机浏览器都是根据Webkit修改过来的内核，本质上我们可以认为市场上移动端用户使用的基本上都是webkit内核或者基于 webkit 内核做修改的浏览器，所以 playsinline 的兼容性非常好！

场景三：播放控制

video 元素有提供多个行为事件供开发者控制视频播放，兼容性比较好的有 onended 、 ontimeupdate、onplay、onplaying 等，有些事件在不同浏览器不同设备上的的表现情况并不一致，

例如：ios 下监听’canplay‘（是否已缓冲了足够的数据可以流畅播放）,当加载时是不会触发的，即使__preload=”auto” __也没用，但在 pc 的 Chrome 调试器下，是会在加载阶段就触发。ios 需要播放后才会触发。

场景四：隐藏播放控件
controls 加上这个属性，Gecko 会提供用户控制，允许用户控制视频的播放，包括音量，跨帧，暂停/恢复播放。

controls 属性规定浏览器应该为视频提供播放控件，反之则隐藏播放控件，那么开发者可以自定义自己的播放控件。隐藏播放控件在 PC 端和 IOS 移动端兼容性良好，而在安卓移动端并不支持隐藏控件，不过还是可以通过一些方法来实现。

黑科技法
比较黑科技的方法是放大视频，把控件条移到视野之外，从而达到隐藏的效果！其实就是让视频元素比父容器还大，这样底部的控制条就会在父容器外面，然后父容器设置为：overflow:hidden, 实现隐藏播放控件的方法！ 缺点是视频会被放大，需要提前留好空白供放大用。微信浏览器

腾讯的android团队的x5内核团队放开了视频播放的限制，视频不一定调用它们那个备受诟病的视频播放器了，利用x5-video-player-type=”h5″ **属性隐藏控件元素，同时视频不再置顶，允许其他元素浮动在顶层**。

总结
了解了视频播放的通用场景及常见的坑后，我们只要针对不同的场景提供对应的兜底方案就能增强用户体验效果。例如移动端自动播放的H5 页面，可以通过引导用户进行点击或者滑动来间接触发视频播放是最保守的做法，no bug！更好的方案是默认自动播放并捕捉禁止播放的情况，再引导用户进行交互实现视频播放。

使用 video 进行视频播放早期因为涉及到性能消耗大、流量消耗多以及处于用户体验等的考虑，在移动端被限制得很严重，但是随着手机性能的提升、流量时代的到来、更强地场景需求，逐步放宽了限制，而PC端则逐渐从“宽松世代”走向“紧缩世代”，两者都有出于让用户有更好地体验的目的而不断更新自己的策略，未来也许会走向一统，开发者就可以从底层兼容适配中释放出来，从而有更多地精力来做更上层的工作。

转载自 ： https://www.jianshu.com/p/fb9eb1c587cb