fastclick从接触到丢弃
fastclick简介
fastclick是一款为了解决移动端300ms点击延迟而诞生的插件。
在移动端，如果对页面没有做任何处理，点击一个元素，触发的事件流程可简单理解为：touch -> 经过300ms延迟 -> click。
fastclick的原理大致如下：
- 监听
touchend事件，在touchend时调用event.preventDefault()禁用300ms后触发默认的click事件； - 通过
document.createEvent手动创建一个鼠标事件对象; - 再通过
eventTarget.dispatchEvent将click事件手动派发到当前目标DOM元素上。
细数fastclick的多宗罪
实际上fastclick目前存在非常多的bug，距离上一次更新已经是五年前了。
但是每周在npm仍然有数以万计的人在下载并使用它。
就目前而言，我使用fastclick遇到的问题如下：
- 移动端点击input不灵敏，需要点击很多次才有反应
- 调起手机原生软键盘卡、慢
- 点击穿透
- 点击错位（点了A，触发了B）
移动端300ms延迟的前世今生
“移动端点击，触发click事件存在300ms延迟”，这句话在前端圈广为流传，似乎大家都默认了这一现象确实存在，在注重移动端用户体验的今天，300ms的延迟变得不可接受，要解决这个问题，靠啥？靠插件呗。网上一搜，大家都用fastclick。所以，你也不管三七二十一，用上了fastclick。
让我们回到300ms延迟本身，探究一下300ms延迟为何会存在。
在2007年，首款iPhone发布之前，遇到了这样一个问题，通过iPhone上网，浏览的网页基本是这样的：
在十几年前，当时的网页基本上都是为PC设备所设计的，没有什么移动端适配的概念，导致字体看起来非常小，阅读困难。
为了处理这种情况，苹果的工程师们想了各种应对方案，其中最为出名的，当属双击缩放（double tap to zoom）。通过双击，在放大比例和原始比例之间进行切换。
如果判断用户是点击还是双击呢？苹果的逻辑如下：
在用户点击完此处第一次后，如果300ms内没有在此处进行第二次点击，就认为是一个纯点击操作。
这就是300ms延迟的来源，浏览器通过300ms的时间间隔猜测你的行为意图，试图分辨你是想单击还是双击。
如何解决
既然浏览器对于单击还是双击存在一个判断逻辑，那么我们只需要告诉浏览器：“不用猜了，我只是想单击而已，压根我就没想进行什么双击缩放”，那么浏览器自然就会乖乖地把这个无谓的行为监测时间间隔给移除。
好了，如何告知呢？我们直接引用fastclick在npm官方地址中的一句话
其意为：在chrome32+（2014年发行）的浏览器版本中，如果viewport meta标签设置了布局视口的宽度等于理想视口的宽度，那么，就相当等于告知浏览器：“我这个网页是专门针对移动端做过适配的，不是那种字跟蚂蚁一样大小的网页，所以，我不需要双击缩放这种操作，赶紧把300ms延迟给我关了”。
如果我们设置user-scalable=no,相当等于斩钉截铁地告诉浏览器：“我这网页已经完全没有缩放可言”，浏览器收到指示，不止在chrome32+的版本，在所有的版本中都会移除300ms延迟。
除了chrome32+，其他诸如firefox,IE/Edge等等主流浏览器均在2014年-2015年年做了跟进，相继修复了这个问题。
而作为始作俑者的iOS,在2016年3月发布的iOS9.3中，也修复了这个问题。
不过要注意⚠️，现在的webview开发(确切来说是iOS8以后)，绝大部分iOS的WebView版本都会选用WKWebView，在WKWebView中，300ms延迟的问题已经得到解决，但是之前的老式UIWebView中这个问题仍然存在。实际上，UIWebView不仅存在不少bug，官方也放弃对其进行维护，并强烈推荐开发者使用WKWebView进行开发。
