chimee 移动端插件开发

chimee 对外正式开源后,就有小伙伴开始咨询,chimee 什么时候可以支持移动端。在 PC 端较为稳定之后,我们就开始着手做移动端的开发了。

开发之前首先要考虑一个事情,chimee 在移动端能够支持哪些格式:

chimee 在 PC 端主要支持三种格式的视频播放: MP4、HLS、Flv。PC 浏览器本身并不支持 HLS 和 Flv 的播放(sarifi 支持 HLS)。我们通过 Media Source Extensions 实现对这两种格式视频的编解码,达到播放的目的。

但是看看 MSE(Media Source Extensions) 的兼容性:

MSE 在移动端的兼容性太差了,移动端主流浏览器基本都不支持这个 api,好在移动端支持 HLS 比较好, Flv 不论 PC 还是移动端都不支持

那么在移动端,chimee 能够播放 MP4, HLS,不需要任何编解码器,直接使用原生的就好了,参考如下配置:

new Chimee({
  // ...
  box: 'native'
})

播放格式搞定!现在开始跟大家分享我在移动端插件开发中遇到的坑。

思考: 需要哪些插件,是否可以直接使用已有的插件?

已有的插件分为两种:

展示类插件只要略微修改样式即可在移动端直接使用。

操作类插件都是基于 mouse 事件来实现,如果直接在移动端使用,会出现以下问题:

1. click 300ms 延迟问题。

2. mousemove 只会在手指移开屏幕的时候触发,而不是在滑动中触发。

3. 没能触发 mouseenter、 mouseleave 等事件,目前也没有 touchenter、touchleave 事件可以用,解决方案是,将其替换为其他事件,或者删除对这些事件的监听。

替换为 touch 事件后,又暴露了新的问题:

1. 透传

思考这么多,终于开始写插件了。在移动端往往要判断用户进行了什么手势操作,而这些操作得通过 touchstart, touchmove, touchend, touchcancel 这四个事件的来一起判断。

可以看下从 hammer.js 学习来的一些手势规则

// tap
TapRecognizer.prototype.defaults = {
  event: 'tap',
  pointers: 1, // 触点
  interval: 300, // 双击操作的最小间隔时间
  time: 250, // 手指在屏幕上的最长时间
  threshold: 9 // 最大移动距离
};

总结: tap 操作规则:

// press
PressRecognizer.prototype.defaults = {
  event: 'press',   
  pointers: 1,
  time: 251, // 手指在屏幕上的最短时间
  threshold: 9 // 最大移动距离
};

总结: press 操作规则:

// pan
PanRecognizer.prototype.defaults = {
  event: 'pan',
  pointers: 1,
  threshold: 10// 最短移动距离
};

总结: pan 操作规则:


// swipe
SwipeRecognizer.prototype.defaults = {
  event: 'swipe',
  pointers: 1
  threshold: 10, // 最大移动距离
  velocity: 0.3 // 最小速度
};

总结: swipe 操作规则:

对于插件,我们可以引用 hammer.js 或者 AlloyFinger 手势库,在 create 方法里对 video,container, warper,以及插件自身 dom 进行事件代理。这样书写的话, 会把 create 方法写的比较乱。我们有更好的方式:对 chimee 的 events 对象进行一层处扩展,将事件全部放在 events 中。

(说了这么多, 最想说这一句)为了更好的服务开发者,我们决定提供一个中间插件来暴露这些手势操作出来,duang~~~ chimee-plugin-gesture 横空出世了~~, 这个插件只是将播放器需要的手势就进行了封装,体积也会比其他手势库小很多。

具体使用方式,查看 readme.md

目前提供的手势操作有 tap、press、panstart、panmove、panend、swipe

手势操作问题处理好了,就可以开发上层逻辑了。

将 PC 端的控制条迁移到移动端: 1. click 替换为 tap 事件 2. pan 替换进度条滑动操作 3. 删除使用率不高的 volume 组件

内联播放和同层播放的问题

先介绍几个概念:

内联播放:通过设置 playslinewebkit-playsline 这两个属性达到在页面内播放的目的,这样在点击播放的时候不会自动去全屏播放。

同层播放:微信提出的概念,主要解决安卓端微信视频播放器的高层级和全屏问题,可以先看下同层播放的一些 API,再谈谈我的理解及可以做哪些事情😂

1. x5-video-player-type="h5" 启用 h5 同层播放器

2. x5-video-player-fullscreen="true" 启用全屏

3. x5-video-orientation 控制横竖屏

4. 事件

以上是微信的一些概念,我在魅族 pro 6s的微信中进行了一些测试。

我的结论是,确实解决了高层级的问题,video 层上可以放一些组件了。但在播放的时候还是默认全屏的,不论我是否设置 x5-video-player-fullscreen="true",按照微信这个解决方案,其实还是没有解决所有问题,不过对于全屏带来的问题,也有几种不同的解决方案:

1. 不使用自己的播放器 UI,而是使用系统默认的 UI, 就是将微信的 H5 同层播放去掉,这样可以在页面内正常播放,但是这样就不可以在 video 元素上放置组件。

2. 特定布局下, 比如:

其他坑

移动端的坑还是比较多的:

1. 坑一: autoplay 属性

2. 坑二: preload

3. 小问题:

4. 还有一些已知问题,还没有答案的那种(有人知道答案可以分享下)

如何调试移动端

如何调试,有几个比较好的工具推荐

1. vconsole, 不用 USB 连接,引入一个 js 文件就可以获得控制微型控制台,可以看到 log / 网络请求 / html 结构等,就是输入代码的时候太麻烦了一些 2. TBS Studio 用来调试安卓下的微信 3. 使用 Mac safari 调 iOS safari。 使用方式 4. chrome 调 chrome 内核浏览器。 使用方式

最后

chimee 移动端可以用了,欢迎大家使用和提 issue。

参考

H5同层播放器接入规范

Muted Autoplay on Mobile: Say Goodbye to Canvas Hacks and Animated GIFs! New Policies for iOS

hammer.js

iOS 10 Safari 视频播放新政策

Touch Events