前端开发现在包含了跨浏览器，跨平台（不同操作系统）和跨设备（不同尺寸的设备）开发。

在移动开发的过程中，到底选取touch事件还是click事件？对了，请不要鄙视click，click在移动端开发用着也是不错的。

首先，我先说一下touch事件在开发中存在的两个问题：

1.touch事件在某些场景下存在点击穿透的问题。

2.touchstart事件时触摸屏幕就会触发，touchend事件是手指离开屏幕就会触发，而有时候，我们仅仅是只想滑动屏幕，却会触发这两个事件。

1问题的原因：移动端事件触发的事件顺序为touchstart-->touchend-->click。加入有两个元素A和B，B在A之上，当我们用touch事件中的回调函数让B元素隐藏，随后A元素触发了click事件。这是因为click事件有300ms的延迟，300ms之后，B元素隐藏了，浏览器触发了click事件，B元素隐藏了，该事件被派发到A 元素之上。

点击穿透的这个问题可以在touch事件中取消默认事件，e.preventDefault()来解决。

2问题却无法调和。

其次，click事件存在的问题：

1.click事件存在的问题，就是300ms的延迟问题。

很多开发者认为，在移动端开发崛起初期，用click事件是可以的，因为当时设备的反应却是仅就这300ms来说，是不易察觉的。但是，随着用户交互体验的要求越来越高，这300ms就变得无法忍受。

移动端300ms延迟的由来?

这要追溯至 2007 年初。苹果公司在发布首款 iPhone 前夕，遇到一个问题：当时的网站都是为大屏幕设备所设计的。于是苹果的工程师们做了一些约定，应对 iPhone 这种小屏幕浏览桌面端站点的问题。

这当中最出名的，当属双击缩放(double tap to zoom)，这也是会有上述 300 毫秒延迟的主要原因。

双击缩放，顾名思义，即用手指在屏幕上快速点击两次，iOS 自带的 Safari 浏览器会将网页缩放至原始比例。 那么这和 300 毫秒延迟有什么联系呢？ 假定这么一个场景。用户在 iOS Safari 里边点击了一个链接。由于用户可以进行双击缩放或者双击滚动的操作，当用户一次点击屏幕之后，浏览器并不能立刻判断用户是确实要打开这个链接，还是想要进行双击操作。因此，iOS Safari 就等待 300 毫秒，以判断用户是否再次点击了屏幕。 鉴于iPhone的成功，其他移动浏览器都复制了 iPhone Safari 浏览器的多数约定，包括双击缩放，几乎现在所有的移动端浏览器都有这个功能。之前人们刚刚接触移动端的页面，在欣喜的时候往往不会care这个300ms的延时问题，可是如今touch端界面如雨后春笋，用户对体验的要求也更高，这300ms带来的卡顿慢慢变得让人难以接受。

也就是说，浏览器会有一些默认的行为，如双击缩放，双击滚动等，这些行为主要是为桌面网站在移动着设备中浏览体验而设计的。而在用户进行操作的时候，移动浏览器会优先判断用户是否触发默认的行为。

浏览器开发商的解决方案：

1.禁用缩放。

当在html文档中包含如下标签：

<meta name="viewport" content="user-scalable=no"/>

<meta name="viewport" content="init-scale=1.0,maximum-scale=1.0" />

表明这个页面是不可以缩放的，那么双击缩放的功能就没有意义了，此时浏览器可以禁用默认的双击缩放行为并且去掉300ms的点击延迟。

这个方法的缺点是我们如果面对桌面应用的小字，放大看就不可能了。

这种方法完全禁用了缩放，而我们仅仅想禁用双击缩放行为。

2.改变默认的视口宽度

<meta name="viewport" content="width=device-width" />

一开始，为了让桌面站点能在移动浏览器正常显示，移动浏览器默认的视口宽度并不等于设备浏览器的视窗宽度，而是比设备视窗浏览器大，大约为980px.

我们通过上述标签设置移动浏览器的宽度等于设备的视窗宽度。随着响应式的普及，很多站点都已经对移动端做过适配了，这时候就不需要双击缩放了。如果能识别出一个网站是响应式网站，那么浏览器就可以认为已经对移动端做了优化和适配，那么久无需双击操作了。

这种方式比方法一的好处在于不用完全禁用缩放，而只是禁用了浏览器的双击缩放行为。

更多解决方案，查看这篇文章：http://www.jianshu.com/p/6e2b68a93c88

总而言之，在移动端开发的时候，如果页面比较简单，可以用touch事件，如果页面比较复杂，直接用click事件，同意用click的事件的好处是不应担心页面点击穿透的问题。

移动端开发用touch事件还是click事件