前端開發現在包含了跨瀏覽器，跨平臺（不同操作系統）和跨設備（不同尺寸的設備）開發。

在移動開發的過程中，到底選取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事件