移動端開發用touch事件仍是click事件

前端開發如今包含了跨瀏覽器，跨平臺（不一樣操做系統）和跨設備（不一樣尺寸的設備）開發。

在移動開發的過程當中，到底選取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的事件的好處是不該擔憂頁面點擊穿透的問題。