2007 年初。蘋果公司在發布首款 iphone 前夕，遇到乙個問題：當時的**都是為大螢幕裝置所設計的。於是蘋果的工程師們做了一些約定，應對 iphone 這種小螢幕瀏覽桌面端站點的問題。
雙擊縮放(double tap to zoom)，這也是會有上述 300 毫秒延遲的主要原因。雙擊縮放，即用手指在螢幕上快速點選兩次，ios 自帶的 safari 瀏覽器會將網頁縮放至原始比例。
假定這麼乙個場景。使用者在 ios safari 裡邊點選了乙個鏈結。由於使用者可以進行雙擊縮放或者單擊跳轉的操作，當使用者一次點選螢幕之後，瀏覽器並不能立刻判斷使用者是確實要開啟這個鏈結，還是想要進行雙擊操作。因此，ios safari 就等待 300 毫秒，以判斷使用者是否再次點選了螢幕。
鑑於iphone的成功，其他移動瀏覽器都複製了 iphone safari 瀏覽器的多數約定，包括雙擊縮放，幾乎現在所有的移動端瀏覽器都有這個功能。
1. faskclick
2.禁用遊覽器縮放
這個方案有乙個缺點，就是必須通過完全禁用縮放來達到去掉點選延遲的目的，然而完全禁用縮放並不是我們的初衷，我們只是想禁掉預設的雙擊縮放行為，這樣就不用等待300ms來判斷當前操作是否是雙擊。但是通常情況下，我們還是希望頁面能通過雙指縮放來進行縮放操作，比如放大一張，放大一段很小的文字。
3.更改預設的視口寬度
這個方案相比方案一的好處在於，它沒有完全禁用縮放，而只是禁用了瀏覽器預設的雙擊縮放行為，但使用者仍然可以通過雙指縮放操作來縮放頁面。
4.通過 touchstart 和 touchend模擬實現
能不能直接用touchstart代替click呢，
答案是不能，使用touchstart去代替click事件有兩個不好的地方。
第一：touchstart是手指觸控螢幕就觸發，有時候使用者只是想滑動螢幕，卻觸發了touchstart事件，這不是我們想要的結果；
第二：使用touchstart事件在某些場景下可能會出現點選穿透的現象。
什麼是點選穿透？
假如頁面上有兩個元素a和b。b元素在a元素之上。我們在b元素的touchstart事件上註冊了乙個**函式，該**函式的作用是隱藏b元素。我們發現，當我們點選b元素，b元素被隱藏了，隨後，a元素觸發了click事件。
這是因為在移動端瀏覽器，事件執行的順序是touchstart > touchend > click。而click事件有300ms的延遲，當touchstart事件把b元素隱藏之後，隔了300ms，瀏覽器觸發了click事件，但是此時b元素不見了，所以該事件被派發到了a元素身上。如果a元素是乙個鏈結，那此時頁面就會意外地跳轉。
說明：手機端瀏覽器基本已經沒有300ms延時現象。
移動端click事件300ms延遲
一般情況下，如果沒有經過特殊處理，移動端瀏覽器在派發點選事件的時候，通常會出現300ms左右的延遲。也就是說，當我們點選頁面的時候移動端瀏覽器並不是立即作出反應，而是會等上一小會兒才會出現點選的效果。在移動web興起的初期，使用者對300ms的延遲感覺不明顯。但是，隨著使用者對互動體驗的要求越來越高...
移動端300ms與點透總結
為啥會出現300ms延遲現象 下列情況不會出現300ms延遲 發生情況 a,b兩個層上下重疊在z軸中 繫結touchstart touchend事件，使上層的a點選後消失 b預設有click事件或b繫結了click事件 為什麼會產生點透 移動端事件執行順序 touchstart touchend c...
移動端相容問題
1.移動端檔名不要用game等，以防被合作伺服器劫持插入廣告，從而影響專案執行 2.紅公尺手機，ua返回iphone，需要結合platform判斷，但是還不準確，導致需要ios和android區別對待的時候就坑了。3.是fixed的問題。這個解決辦法是盡量不要用，不過ios7及以下才會出現這個問題。...