「北海 Kraken」是一款基于 Flutter 的 Web 渲染引擎，经过基于 W3C 标准来开发实现前端开发者经常使用的能力。 Kraken 团队也积极探索定义新的问题以及能力，指望经过参推进标准定制的方式让 Web 技术变得更好。 欢迎你们关注 「北海 Kraken」： http://openkraken.com/javascript
在过去，早期的 Web 更多用作内容展现的页面，最先从后端框架中直出，再配上各类 CSS 以及 JS 的交互内容，以完成最终对页面内容的展现，那时候的 Web 更多属于 【内容开发】，作内容的直出与展现。而现在现代 Web 开发体系已经有了翻天覆地的变化，早已超出了【内容开发】的范畴，在各个领域都有 JavaScript 的身影。一样，Web 也已经脱离了客户端以及浏览器的限制，各式各样基于 Web 标准或者私有标准的 Web runtime 层出不穷。【Web 应用开发】区别于传统的【内容开发】，它对开发者提出了更高的要求，也对 Web 的能力提出了更高的要求，不管是基于标准化方面的考量，仍是基于对易用性的考虑，咱们都指望 Web 开发者能够得到经过更高级的封装的标准的高性能的能力。前端
而手势能力就是其中的一块。java
目前在 Web 标准中，手势能力是属于缺失的一块能力，更多的开发者经过 hammer.js 来得到一个经过 JavaScript 模拟出来的手势事件来开发一个手势强交互的应用，或者是直接基于更底层的 Touch event来作进一步的封装。git
可是不管是类 hammer.js 的前端手势方案，仍是 Touch event的封装，都会致使一些问题，我将从易用性、性能、标准化的角度来作进一步的分析：github
- 易用性： 开发者必须手动去实现或者封装更高一级的手势能力，没法直接从 element 上得到某个高级手势的 event 事件。不管是开发成本，都须要额外加载或者执行额外的 CDN，都是对前端资源的一种损耗。
- 性能： 经过 JavaScript 实现的方案须要频繁地经过 Bridge 将手势的能力传递到前端，而后再去计算模拟相关的手势事件。频繁的传递数据增长了 Bridge 的消耗，不断执行的 JavaScript 会阻塞 UI 线程，若是须要更强大的手势能力支撑，咱们必须进一步封装【竞争场】等能力的实现来达到手势竞争的目的，而这部分能力本应下沉到渲染引擎自己，而不是在 JavaScript 中处理。
- 标准化： 各个开发者实现的标准不统一，判断的基准不一致，透出的 event 能力不对齐会致使各个平台甚至到各个页面的标准不统一。譬如说在同一个 iOS 设备上访问两个不一样开发者开发的页面，不统一的手势能力可能会给用户带来及其糟糕的体验。非标准化的手势能力在各个端上也显得格外突出，下面我介绍各端的手势能力时会介绍这些差别点。
连续手势与离散手势
首先我须要介绍一下连续手势与离散手势的概念，以便读者能够更好地区分这两种手势的不一样，以及了解实现不一样的手势能力对开发、性能、易用性等纬度的影响。小程序
首先，咱们须要知道，因为在端侧有各类各样的屏幕操做的设备，常见的好比说类 apple pencil 的电子笔设备（pen），手指直接触摸操做（touch），还有鼠标（mouse）等。因此在 W3C 标准中， 将全部的接触屏幕的物理设备抽象成了一个 pointer，不管上层是那种物理设备，对于屏幕只感知与抽象这一个触摸到的点，基于 type 区分具体的上层的物理设备。后端
一个完整的手势包含了手指开始接触屏幕（pointer down），而后手指在屏幕上进行偏移（pointer move），以及手指抬起离开屏幕（pointer up），暂时不讨论 cancel、out 等状况。固然，其中中间 pointer move 的过程是能够省略的，最多见的省略 pointer move 的手势譬如说 click 或者 long press 等（固然，若是点击设备不是一个鼠标而是一根手指，其实手指实际接触是确定会产生轻微移动状况的，譬如在 FLutter 中，容许这个细微的移动距离在 18 个像素点内，即视为不移动）。能够预见的是将来会有更多的物理设备操做屏（甚至不是屏），基于底层触摸点的 pointer 抽象有利于上层作更多的扩展。浏览器
了解了这些，接下来咱们来了解一下连续手势与离散手势的差别。app
- 连续手势：从 pointer down 到 pointer moves 到 pointer up，中间过程能够经过 state 状态来描述的手势，能够清楚地经过不一样的回调或者不一样的状态让开发者感知目前手势所处的状态的手势。常见连续手势：pan。
- 离散手势：完整手势触发完毕后才会经过回调来通知开发者，无中间状态的转换。常见离散手势：click。
连续手势会频繁经过回调或者状态来通知开发者目前手势所处的状态，咱们来看一种状况：框架
element.addEventLisenter('pan', (gestureEvent) => {
if (gestureEvent.state === 'up') {
// do something...
}
})
假设咱们须要在 Web 标准中实现 pan 这个手势，若是它是一个连续手势，而咱们的场景只须要用 up 这种状态，就须要不断地将当前的状态经过 Bridge 以及 JS engine 传递到 JavaScript 中，这频繁的传递开销是对设备性能的一种浪费。固然，也有框架方案经过更加细分的粒度去解决这个事情，譬如说拆分红 panstart、panupdate、panend等，当开发者不给这些方法注册回调时，能够在框架内部判断并作相应优化。然而细分的 API 抽象不够底层，对于开发者来讲也并不那么友好。
而对于离散手势，咱们则不须要考虑手势过程当中的状态传递，只须要把最终的结果返回给开发者便可，离散手势屏蔽了许多内部处理的细节，保证了开发者注册的回调只能完整的手势操做完之后才能被命中。有效地下降了连续手势数据的传递量。可是相较于连续手势，离散手势的缺点是开发者没法很好地感知中间状态。
接下来咱们来看一下各个端上实现的手势体系、优缺点以及差别性。
各端手势体系
hammer.js
- Pan Pan 的须要有一个最小距离以及方向，只要达到这个条件能够频繁触发。 详见：https://github.com/hammerjs/hammer.js/blob/master/src/recognizers/pan.js#L42
- Swipe 距离与速度达到必定阈值的滑动。 详见：https://github.com/hammerjs/hammer.js/blob/master/src/recognizers/swipe.js#L36
- Pinch （向外捏时放大，向内捏时缩小）
- Press （长按，默认时间在 250 ms 以上 ，替代了 long press） 详见：https://github.com/hammerjs/hammer.js/blob/master/src/recognizers/press.js#L78
hammer.js 做为一个前端实现的 gesture lib，经过注册 Touch 事件作封装来完成具体的操做的判断，在前端作手势的方案在前面已经提过，须要不断地经过 Bridge 以及 JS engine 传递到 JavaScript 中，而后才能最终在 JavaScript 中处理手势操做，只要有操做就会被抛到 JavaScript 中进行处理，频繁的传递耗费了许多没必要要的性能。咱们更但愿这部分能力能够下沉到渲染引擎自己，这样能够节省很是多没必要要的数据传递开销。
若是在基础手势判断之上想进一步引入更加复杂的【竞技场】等能力，这部分会使得 JavaScript 中的逻辑更加复杂，即使抛开“能不能”在前端作相关实现来讲，过多的 JavaScript 运行占用计算资源也是咱们并不想要的。
同时，须要单独引入一个 CDN 脚原本支持相关的功能，对于包体积以及首屏也增长了额外的成本。可是又考虑到自己浏览器并不自带这些功能，通常开发者也没法很好地将这套方案优化并下沉到浏览器中，因此在反而在大部分前端业务场景成为来较优的技术选型。
Flutter
- Tap
- Double tap
- Long press （500 ms 以上的长按）
- Vertical(Horizontal) drag 横（纵）滑 在 drag 上作了进一步封装，在 x 轴或者 y 轴偏移超过最小距离并达到阈值速度可触发。
- scale scale 会包含放大缩小以及旋转的手势，至关于其余端中的 Pinch + Rotation
- Pan Pan 内部实现，须要达到一个最小速度以及最小移动距离的 drag 才能触发 Pan，Pan 是基于 drag 之上的封装，增长了判断。Flutter 内置一个 pointer down + pointer moves + pointer up 只能触发一次手势，因此 Pan 只能触发一次（与 hammer 不一样，为有状态手势） 详见： https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/gestures/monodrag.dart#L579
Flutter 的手势体系除了 Long press 均为连续手势，无离散手势，Tap 也会经过 TapDown、TapUp 等状态来完成。每一个中间状态会经过不一样的回调函数来支持开发者处理逻辑，返回参数也根据中间状态的不一样而不一样。排除 Widget 的统一封装来看，跟安卓相似，回调过多，且返回参数不统一，不利于标准化。可是对于内部的手势回调来讲，细分的接口各司其职，传递所需的参数都是必须的，开发者能够直接获取具体的返回信息。
iOS
- Tap（离散手势，100 ms 左右的点击行为）
- Long Press (连续手势，500 ms 以上的点击行为)
- Pan （连续手势，平移，相似 drag，可是能够在移动过程当中不断变化方向）
- Swipe （离散手势）
- Pinch（连续手势，向外捏时放大，向内捏时缩小）
- Rotation（连续手势，旋转）
为了方便你们了解各个手势的区别，尤为是 Pan 跟 Swipe 的区别，特意放上了iOS 开发者文档的一些图片。
iOS 的手势能够带上多个 touch pointer，同时知足了几个手指操做的能力。好比三指滑动（三根手指的swipe）、双指点击（两根手指的 Tap）等。它提供了开发者对某一个手势处理成一个注册回调函数，经过 state 判断目前手势的状态。离散手势与连续手势共存。
Android
- View 上直接提供 click 以及 touch 的一些方法
- OnDragListener：拖动事件。
- OnLongClickListener：长按抬起时的事件。
- GestureDetector.OnGestureListener
- onDown：手势识别器的 down 事件。
- onFling： 相似 swipe。
- onLongPress： 长按。
- onScroll：scroll view 滚动时的事件。
- onShowPress：按下后没抬起，至关于（up、move、down 的中间 move 状态，只是没move）。
- onSingleTapUp： 点击抬起，对应 onDown。
- GestureDetector.OnDoubleTapListener： 双击。
- ScaleGestureDetector：旋转，捏，分 begin、onScale、end。
相对来讲，Android 的手势体系比较细分，大体上跟 FLutter 比较像，可是 Flutter 是不一样手势在不一样类中的，Flutter 基本上都是离散手势，安卓不少连续手势，可是更加细分。
标准
综上分析了 Flutter、iOS、Android 以及一个前端实现的 gesture lib（hammer.js），不难发现，每一个端实现的手势方案都大同小异。无非都实现了这几种方法： click（Tap）、swipe、Pan、Long Press （Press）、Pinch 与 Rotation（或者 Scale）。可是各个平台对每一个手势的实现仍是有些许的差别，不管是具体手势的代码逻辑判断仍是具体手势的拆分或者命名，均有不一样。
那在 Web 技术上，咱们应该使用怎么样一套手势规范，来兼顾易用性、性能以及标准化呢？就目前来看，基于 Web 技术体系发展来的 Web runtime 的已经很是多了，诸如 Web、React Native、小程序等体系已经在端侧带来了巨大的运行时碎片化。将来不止于移动端上，还有各类 IOT 设备出现，可能会有愈来愈多的 Web runtime 会出现。将来可能会有更多领域会有不同的终端设备，而折叠屏、柔性屏的到来也可能会让端侧的设备（手机、IOT、车载等）造成更多更复杂的的跨端场景，随之而来的也是更多的交互手势来与这些设备进行“沟通交流”。
很遗憾的是目前 W3C 上没有相应的手势规范，咱们更指望有一个统一的既定标准来规范，咱们也在 W3C 中文兴趣小组上发起了一个讨论，目前此讨论已经提到了 UIEvent。咱们指望经过易用性、性能以及标准化这几个纬度去讨论手势规范以及对应的手势标准化能力的必要性，以及最终推进规范创建的可行性，也欢迎更多的小伙伴加入该讨论。
此外，该标准提案目前已经在 北海 Kraken 上实现，开发者能够直接使用 加强的手势能力 来开发复杂的交互应用。后续 北海 Kraken 团队将会在复杂的业务场景上定义出更多问题以及通用能力，指望能够经过参与推进标准定制的方式让 Web 技术变得更好。