移动端300ms延迟
1. 300ms延迟的产生缘由
移动端浏览器的默认显示宽度是980px
(不同机型各异,但相差不大),而不是屏幕的宽度(320px
或其他)。为了对早期普通网页更好的体验,iphone
设计了双击放大显示的功能--这就是300ms
延迟的来源:如果用户一次点击后300ms
内没有其他操作,则认为是个单击行为;否则为双击放大行为。
2. 点透行为
假设有两个层级,A
和B
;A
在上面,B
在下面。 如果A
监听touch
事件(zepto
的tap
事件),而且B
上有个链接(或者监听click
事件),那么当touch A
后,先后触发了touchStart
和touchEnd
事件,touchEnd
后A
层隐藏,而此刻会触发在document
最前面B
的click
事件;这就是点透行为。
3. 解决方法
- 设置不能缩放:
user-scalable=no
。 不能缩放就不会有双击缩放操作,因此click
事件也就没了300ms
延迟,这个是Chrome
首先在Android
中提出的。 - 设置显示宽度:
width=device-width
。Chrome
开发团队不久前宣布,在Chrome 32
这一版中,他们将在包含 width=device-width 或者置为比 viewport 值更小的页面上禁用双击缩放。当然,没有双击缩放就没有300
毫秒点击延迟。 IE
的指针事件 (Pointer Events
):设置touch-action:none
,根据规范,touch-action
属性决定 “是否触摸操作会触发用户代理的默认行为。这包括但不限于双指缩放等行为”。
从实际应用的角度来看,touch-action
决定了用户在点击了目标元素之后,是否能够进行双指缩放或者双击缩放。因此,这也相当完美地解决了300
毫秒点击延迟的问题。
鉴于上述的3
种解决方案,现在较为通用的meta
设置为:
<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no">
4. 现在的流行解决方案:
上述的3
种解决方案可以解决Chrome Android
和IE10+
下的300ms
问题,但是对其他浏览器还需要特定的解决方案。
- 指针事件的
polyfill
指针事件的polyfill
比较多,以下列出比较流行的几个。Google
的 Polymer,微软的 HandJS和@Rich-Harris 的 Points - FastClick
FastClick 是 FT Labs 专门为解决移动端浏览器300
毫秒点击延迟问题所开发的一个轻量级的库。简而言之,FastClick
在检测到touchend
事件的时候,会通过 DOM 自定义事件立即触发一个模拟click
事件,并把浏览器在300
毫秒之后真正触发的click
事件阻止掉。
5. FastClick
现阶段FastClick
被更多使用,借助它通过监听click
事件,即可消除300ms
的问题。
通过阅读源码可知:
FastClick
通过判断浏览器类型决定其是不是需要执行,下面几种场景下不会执行FastClick
逻辑:
- 不支持
ontouchstart
事件的浏览器 Android Chrome
或者firefox27
以上 设置了user-scalable="no"
- 满足特定要求的
IE10+
浏览器 - 部分黑莓浏览器
- 注册了
touchStart
、touchEnd
等事件,监听touchStart
决定事件对象的target
、时间、位置等信息;通过touchEnd
得到touch
的结束时间。如果touch
时长大于700ms
,则是长按事件;如果连续两次touchEnd
的时间间隔小于200ms
,那么认定为快速点击,特殊对待;排除上面两种情况,就通过clickEvent = document.createEvent('MouseEvents'); initMouseEvent; dispatchEvent
手动触发click
事件。
多抽出1分钟来学习,让你的生命更加精彩!