FastClick 填坑及源码解析

最近产品妹子提出了一个体验issue —— 用 iOS 在手Q阅读书友交流区发表书评时,光标点击总是不好定位到正确的位置:

如上图,具体表现是较快点击时,光标总会跳到 textarea 内容的尾部。只有当点击停留时间较久一点(比如超过150ms)才能把光标正常定位到正确的位置。

一开始我以为是 iOS 原生的交互问题没太在意,但后来发现访问某些页面又是没有这种奇怪体验的。

然后怀疑是否 JS 注册了某些事件导致的问题,于是试着把业务模块移除了再跑一遍,发现问题照旧。

于是只好继续做排除法,把页面上的一些库一点点移掉再运行页面,结果发现捣乱的小鬼果然是嫌疑最大的 Fastclick。

然后呢,我试着按API所说,给 textarea 加上一个名为“needsclick”的类名,希望能绕过 fastclick 的处理直接走原生点击事件,结果讶异地发现屁用没有。。。

对此感谢后面我们小组的 kindeng 童鞋帮忙研究了下并提供了解决方案,不过我还想进一步研究到底是什么原因导致了这个坑、Fastclick 对我的页面做了神马~

所以昨晚花了点时间一口气把源码都蹂躏了一遍。

这会是一篇很长的文章,但会是注释非常详尽的剖析文。

文章带分析的源码我也挂在我的 github 仓库上了,有兴趣的童鞋可以去下载来看。

闲话不多说,咱们开始深入 FastClick 源码阵营。

我们知道,注册一个 FastClick 事件非常简单,它是这样的:

所以我们从这里着手,打开源码看下 FastClick .attach 方法:

这里返回了一个 FastClick 实例,所以咱们拉到前面看看 FastClick 构造函数:

在初始通过 FastClick.notNeeded 方法判断是否需要做后续的相关处理:

我们看下这个 FastClick.notNeeded 都做了哪些判断:

基本上都是一些能禁用 300ms 时延的浏览器嗅探,它们都没必要使用 Fastclick,所以会返回 true 回构造函数停止下一步执行。

由于安卓手Q的 ua 会被匹配到 /Chrome/([0-9]+)/,故带有 ‘user-scalable=no’ meta 标签的安卓手Q页会被 FastClick 视为无需处理页。

这也是为何在安卓手Q里没有开头提及问题的原因。

我们继续看构造函数,它直接给 layer(即body)添加了click、touchstart、touchmove、touchend、touchcancel(若是安卓还有 mouseover、mousedown、mouseup)事件监听:

注意在这段代码上面还利用了 bind 方法做了处理,这些事件回调中的 this 都会变成 Fastclick 实例上下文。

另外还得留意,onclick 事件以及安卓的额外处理部分都是走的捕获监听。

咱们分别看看这些事件回调分别都做了什么。

1. this.onTouchStart

顺道看下这里的 this.updateScrollParent:

另外要注意的是,在 onTouchStart 里被标记为 true 的 this.trackingClick 属性,都会在其它事件回调(比如 ontouchmove )的开头做检测,如果没被赋值过,则直接忽略:

当然在 ontouchend 事件里会把它重置为 false。

2. this.onTouchMove

这段代码量好少:

看下这里用到的 this.touchHasMoved 原型方法:

3. onTouchEnd

这段比较长,我们主要看这段:

其中 this.needsFocus 用于判断给定元素是否需要通过合成click事件来模拟聚焦:

另外这段说明了为何稍微久按一点(超过100ms)textarea ,我们是可以把光标定位在正确的地方(会绕过后面调用 this.focus 的方法)

接着咱们看看这两行很重要的代码:

所涉及的两个原型方法分别为:

⑴ this.focus

注意,我们点击 textarea 时调用了该方法,它通过 targetElement.setSelectionRange(length, length) 决定了光标的位置在内容的尾部(但注意,这时候还没聚焦!!!)。

⑵ this.sendClick

真正让 textarea 聚焦的是这个方法,它合成了一个 click 方法立刻在textarea元素上触发导致聚焦:

经过这么一折腾,咱们轻点 textarea 后,光标就自然定位到其内容尾部去了。但是这里有个问题——排在 touchend 后的 focus 事件为啥没被触发呢?

如果 focus 事件能被触发的话,那肯定能重新定位光标到正确的位置呀。

咱们看下面这段:

通过 preventDefault 的阻挡,textarea 自然再也无法拥抱其 focus 宝宝了~

于是乎,我们在这里做个改动就能修复这个问题:

或者:

这里要吐槽下的是,Fastclick 把 this.needsClick 放到了 ontouchEnd 末尾去执行,才导致前面说的加上了“needsclick”类名也无效的问题。

虽然问题原因找到也解决了,但咱们还是继续看剩下的部分吧。

4. onMouse 和 onClick

常规需要阻断点击事件的操作,我们在 touch 监听事件回调中已经做了处理,这里主要是针对那些 touch 过程(有些设备甚至可能并没有touch事件触发)没有禁用默认事件的 event 做进一步处理,从而决定是否触发原生的 click 事件(如果禁止是在 onMouse 方法里做的处理)。

小结

1. 在 fastclick 源码的 addEventListener 回调事件中有很多的 return false/true。它们其实主要用于绕过后面的脚本逻辑,并没有其它意义(它是不会阻止默认事件的)。

所以千万别把 jQuery 事件、或者 DOM0 级事件回调中的 return false 概念,跟 addEventListener 的混在一起了。

2. fastclick 的源码其实很简单,有很大部分不外乎对一些怪异行为做 hack,其核心理念不外乎是——捕获 target 事件,判断 target 是要解决点透问题的元素,就合成一个 click 事件在 target 上触发,同时通过 preventDefault 禁用默认事件。

3. fastclick 虽好,但也有一些坑,还是得按需求对其修改,那么了解其源码还是很有必要的。

2 2 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部