1、手机页面缩放和300ms延迟问题的由来

在智能手机还没有普及时候，在手机上看到的页面其实都是web页面，因为手机的屏幕宽度不到400像素，而web页面的宽度通常都在960像素左右，所以当在手机上查看web页面的时候只能看到部分内容，如果想看手机屏幕以外的内容就需要不停地滑动屏幕。

苹果的工程师为此想出了解决方案。那就是完全缩放页面，把宽度为1000像素左右的web页完全平铺在宽度不到400像素的手机屏幕上，这样虽然能够看到完整的web页面，但是里面的内容也相应地变小了许多，读起来很不方便。苹果的工程师给出来的解决策略是：双击屏幕缩放页面大小。哪个地方读起来太小，那就在那个地方双击，屏幕就会放大那个地方。

这个方案虽然解决了在手机阅读不方便的问题，却也造成了另一个问题，那就是浏览器并不知道在用户在双击放大的时候，第一次点击屏幕究竟是想放大页面还是想直接点击链接。于是，300ms延迟就诞生了。

300ms延迟的逻辑是，当用户第一次点击屏幕的时候，浏览器就等着，等300ms了如果还没有收到第二次点击，浏览器就判定用户是想打开链接，如果在300ms以内收到了第二次点击，那就是放大页面。

这便是300ms问题的由来。

但是，随着移动页面的不断发展和响应式的诞生，开发者逐渐专门给手机适配了页面，这样的话用户无需缩放就可以正常查看手机页面了，300ms延迟也就没啥必要了，在响应式页面下，如果还存在双击放大和300ms延迟就会给用户体验带来不少问题，因为每次点击都要300ms的时间来检测，这样就会有些“卡”了，不仅浪费时间也完全没有必要。

为此，为了解决掉已经存在的300ms延迟和缩放问题，各个平台都拿出了自己的方案。

2、不同的解决方案

在head的meta标签里添加如下代码：

<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">

这其实是两个方案合在一起的代码，它可以分成以下两个部分：

<meta name="viewport" content="user-scalable=no, initial-scale=1,maximum-scale=1,minimum-scale=1.0">

这段代码的意思是，禁止缩放。完全禁止了双击缩放的功能，自然也就不存在什么300ms延迟的问题了。

但是它有个问题，那就是用户有时也会想放大部分内容，而这段代码完全禁止了缩放，甚至是双指缩放都禁止了。于是就有了下面的补充方案。

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

这段写在head里面的代码，意思就是告诉浏览器我已经是响应式了，浏览器就会去掉双击缩放和300ms延迟，它还有一个优点，不像上面那个方案那样完全禁止了缩放功能，这个方案它保留了双指缩放，只是去除了双击缩放和300ms延迟。

这两段代码我们通常写到一起，就像开头的那样。

除了这两个方案以外，还有CSS的touch-action,如果元素被设置成touch-action:none;那么浏览器就不会有任何默认操作，自然也不会有双击缩放和300ms延迟了。

当然，JS也给出了相应的方案，最典型的就是fastclick.js这个库了。这个库的基本逻辑就是，当用记第一次点按屏幕的时候，直接将它改成click事件，同时禁止300ms以后的浏览器可能出现的状态。这样，就可以做到一次点按了。

3、来自苹果的奇异方案

苹果没有采用上述在head里添加meta标签的办法，从IOS 8 开始它使用了另一套方案。这套方案的核心是在用户手指在屏幕上的停留时间做文章。如果用户在点按屏幕的时候，在屏幕上停留时间小于125ms左右的话，则判定是fast tabs,那么双击缩放和300ms延迟依然保留。如果停留在屏幕上的时间大于125ms的话，则判定是slow tabs，那就是click，就没有双击缩放和300ms延迟。

4、touch事件举例

• touchstart
  表示开始触摸
• touchend
  手指离开屏幕
• touchmove
  在屏幕上滑动，这个事件会不断地生成e
• touchcancel
  由于特殊的原因导致触摸焦点不见，触摸取消