2、爲何存在這個問題git
這要追溯至 2007 年初。蘋果公司在發佈首款 iPhone 前夕，遇到一個問題 —— 當時的網站都是爲大屏幕設備所設計的。因而蘋果的工程師們作了一些約定，應對 iPhone 這種小屏幕瀏覽PC端站點的問題。這當中最出名的，當屬雙擊縮放(double tap to zoom)。github
雙擊縮放，顧名思義，即用手指在屏幕上快速點擊兩次，iOS 自帶的 Safari 瀏覽器會將網頁縮放至原始比例。web
那麼問題來了，假設用戶在 iOS Safari 裏邊點擊了一個連接，當用戶一次點擊屏幕以後，瀏覽器並不能馬上判斷用戶是確實要打開這個連接，仍是想要進行雙擊操做。api
所以，iOS Safari 就等待 300 毫秒，以判斷用戶是否再次點擊了屏幕。瀏覽器
3、這是一個問題嗎app
上文的假設場景看起來沒毛病，那麼，這是一個問題嗎？webapp
回答：是。iphone
現在是個移動端開發的 web 應用性能能夠同原生應用匹敵的時代，全部的單擊事件都有 300 毫秒延遲，必然是不可接受的。
4、驗證問題
雖然說各類資料均代表ios移動端頁面click事件有300ms延時，然而我仍是想看一下到底有多少延時，雖然感受是慢了點，可是，用數聽說話更加可信。代碼以下：
而後在iphone裏面打開測試頁面：
點擊按鈕，顯示延時，發現延時分佈在370ms左右，比傳說的300ms要大，這和設備有關。
5、如何解決問題
問題真實存在，那麼就須要解決問題。
一、移動端通常都用了類jq的庫——zepto，zepto封裝了一系列的觸摸事件，其中的tap事件就是click事件去掉300ms延時的事件，然而，zepto的tap事件有一個點透的問題，故該方案不可行。
二、使用fastclick庫。
6、fastclick
我比較懶，簡介扣了人家的自我介紹：
兼容性也很好：
用法也很簡單，這裏我就不說了，只須要注意一點：使用FastClick的時候，在須要使用的層上，實例化它。咱們使用document.body是由於但願全部的按鈕和連接都得到快速點擊。
來個使用後的效果圖：
7、思考
一、爲何zepto的tap事件會點透，而fastclick的click事件不會點透？
咱們先來了解下什麼叫點透問題。假如你在列表頁面上建立一個彈出層，彈出層有個關閉的按鈕（綁定了tap事件），你點了這個按鈕關閉彈出層後，這個按鈕正下方的內容也會執行點擊事件（或打開連接）。這個就是一個「點透」現象。
點透出現的緣由是：延遲300ms的click事件觸發了。
zepto的touch模塊中，沒有對這個延遲300ms的click事件取消，或者取消不了。而fastClick中，會對這個延遲300ms的click事件取消，也就是這個click事件不會觸發。
因此zepto的tap事件（經過touchstart和touchend模擬出來的）有點透問題，而fastClick的click事件（經過touchstart和touchend模擬出來的）沒有。
深刻到zepto的touch.js和fastClick的源碼，咱們能夠得知：zepto的tap事件和fastClick的click事件，源碼差很少。爲何基本相同的代碼，zepto會點透而fastclick不會呢？緣由是zepto的代碼裏面有個settimeout，在settimeout裏面執行e.preventDefault()不會生效，所以zepto中的延遲300ms的click事件會觸發，而fastClick不會。
二、爲何不能用touchend代替click來解決延時問題？
一種解決辦法是，用touchend替代click，而後preventDefault來阻止默認行爲click。
聽起來簡單易行，然而功能複雜的時候就會出問題，好比滑動加選擇，會由於滑動觸發touchend，從而觸發選擇行爲。因此若是原本應該綁定在click上的事件所有綁定到touchend事件上，就會出現問題。
8、參考資料
一、http://developer.telerik.com/featured/300-ms-click-delay-ios-8/
二、https://www.sitepoint.com/5-ways-prevent-300ms-click-delay-mobile-devices/
三、http://www.linovo.me/front/webapp-300ms.html
四、https://github.com/ftlabs/fastclick
五、https://github.com/filamentgroup/tappy/
六、http://labs.ft.com/2011/08/fastclick-native-like-tapping-for-touch-apps/