关于前端:微信H5视频踩坑记录

背景：
最近开发了一个需要，要求是在进入微信 H5 页面后，主动开始播放视频，同时视频上有悬浮的跳转页面按钮，等视频播放完后则暗藏视频显示一个后果页。

艰难及计划：
需要看起来非常简单，也十分失常，没有任何刁钻的能力要求。但真实现起来坑就多了，次要还是因为微信自身有很多限度。

依据冀望的需要点，咱们来看看问题都在哪：
1.自动播放

需要冀望在进入页面后即主动开始播放视频，咱们理所应当的加上了 autoplay 属性，然而在微信里它的性能更在于减少代码可读性等。不过微信提供了一个 WeixinJSBridgeReady 事件，在这个事件中咱们能够通过 JS 让其开始播放

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

然而并没有那么简略，在安卓机中，至多在我的小米 8SE 中，视频仍然不能主动被播放。网上有人说是因为播放的时候视频还没加载，弄个计时器重复抢救就行了，可是我的手机始终处于抢救失败的处境。那么后果是什么呢？咱们的视频停留在了未播放的预览状态，两头则是一个播放按钮

这个时候其实有一些解决思路，比方做一张针对这种状况的 UI 图当预览，诱导用户去点击两头播放等，但不管怎么说，通用性的自动播放曾经流产了。所以在斗争后，咱们改成了刚进来的时候，全屏显示一个诱导用户点击的图片遮挡视频，点击后显示并开始播放视频，留神不是点击 video 后播放视频，而是点击任意咱们诱导用户点击的货色即可，因为只有存在用户交互，咱们就能够在事件中播放

// 点击诱导图开始播放
cover.addEventListener('touchstart', playVideo, true);

但这里须要留神，因为在这个计划中咱们采纳了先暗藏 video，播放时再显示的计划，仍然是在安卓环境下，如果有人和我一样发现有时候视频主动黑屏暂停，通过 video.currentTime 获取的工夫卡在 0.001，计时器抢救也有效，如果用户不点播放，就会始终卡在这里反射出用户的那张迷茫的大脸

那么大概率是违反了一个准则导致的，即视频在暗藏状态下播放会被进行，比方咱们没有放弃 WeixinJSBridgeReady 的自动播放能力，在视频暗藏阶段仍然尝试去播放了一下，或者咱们为了让视频第一工夫缓存，在刚进入页面就让视频先播放再暂停等，只有是这种在视频暗藏状态上来调用 play()，在安卓上就很可能进入这种状态

2.非全屏播放

需要冀望的是在指定区域播放视频，这自身并不是什么问题，微信默认行为也是部分播放的，但值得注意的是，安卓微信的部分 video 播放是采纳一个独立的悬浮 Native View 来实现的，并且这个 View 自身层级十分高，齐全在 webview 之上，也就意味着咱们的代码比方 z -index 什么的将齐全无奈对其产生任何影响或笼罩，当然如果你的需要并没有要求在视频上飘着什么的话，对其默认的款式格调也能承受的话，这样也没什么不好。网上传说的播放完后插广告的行为我倒是没有试出来，但因为咱们必须要那个悬浮按钮，故而就放弃了安卓的部分播放。

3.视频上悬浮 html 按钮

部分播放和悬浮按钮在安卓微信上是抵触的，不过网上其实是有一些案例啪啪啪在打我的脸，不过仔细观察会发现，那些打脸的视频地址根本都是腾讯本人的，故而我也抉择置信传说中的微信视频白名单，即针对白名单下的视频，安卓微信就不会再对其进行花式魔改，给予其保留纯朴性能的慈善。

如果不说白名单的话，那在安卓环境下，部分播放和悬浮按钮就是两个抵触的要求，必须斗争一个，咱们抉择了在安卓环境下全屏播放同时悬浮按钮。要开启视频全屏其实非常简单，外围的属性是 x5-video-player-type=”h5″，只有这个属性在就会开启全屏了，不过倡议也把 x5-video-player-fullscreen=”true” 加上确保兼容性。留神就算加上这些属性，在 iOS 下也仍然是部分播放的，但因为 iOS 没被魔改过，故而不必放心那些蛋疼的问题，最多就是两端体验不太统一。

另外退出全屏能够应用一种特定的形式

// 退出全屏
if (document.webkitExitFullscreen) {document.webkitExitFullscreen();
}

不过全屏也有全屏的问题，在有的机型，全屏后最上层会主动悬浮 <(退出)和···(更多)两个图标按钮，这两个按钮可是在视频的区域上的，很可能会和咱们本人的悬浮按钮叠到一块，故而可能须要针对安卓调整悬浮按钮的地位。

另外那三个点的按钮点开后，会有一个分享性能，这个分享不会被 KNB.configShare 预设，也没有找到能够设置的 API，通过它分享进来的链接尽管也能用，但将会十分间接，比方对于咱们这个我的项目来说就是

咱们是曾经讲过 KNB 调用微信的接口预设过的，在其余场景下分享也是规范的气泡模式，但在安卓全屏视频右上角那三个点的分享中，就变成了这个样子。曾经反馈给 KNB 的同学了，不过看样子没什么人在乎，目前还没有找到解决方案

4.暗藏管制条

管制条天然是能暗藏就暗藏的，咱们理所应当的删掉了 controls 属性，但事件并没有那么简略。在 iOS 微信中，不应用该属性是合乎预期的，但在安卓中(为什么又是安卓？)，将可能会导致视频无奈播放的问题，故而我采取的策略是，人造自带 controls 属性，当断定是 iOS 后删除该属性。其实还有另一种思路来解决，就是通过制作较长的视频，把管制条放在视线外藏起来，而后不让滚动就好，路子是野了点，但至多也是路子嘛

5.禁用全局滑动

页面自身能够高低滑动也是十分另人不爽的，网上说的禁用形式有很多，但不肯定都能见效，我应用的是

body {
  overflow: hidden;
  height: 100%;
  width: 100%;
  position: fixed;
  top: 0;
  bottom: 0;
  user-select: none;
  background-color: #FFF;
}

6.视频适配不同手机比例

视频长宽比是固定的，但手机屏幕比例不同，在咱们这种全屏视频的状况下这个问题更加显著。咱们采纳的思路是，视频宽度铺满屏幕宽度，而视频自身是较长 (高) 的，比方自身适配的是 iphoneX 的全屏播放高度，但视频下方其实是能够舍弃的局部，没有什么要害内容，就算有字幕等也不会在最底部，而是底部靠两头一点的地位，这个地位的要求是在小手机上仍然能够看失去残缺字幕

这样做的益处就是较长的手机上尽量不会呈现底部留白，而小手机上则不会缺失内容，再配合不容许高低滑动，一般来说就相当于全屏视屏播放了