摘要：早期版本的的就是如此處理的，自定義事件在中觸發(fā)，解決單擊延時的問題。給按鈕綁定事件事件執(zhí)行自定義事件觸發(fā)上的事件當(dāng)然實際中肯定要放在其他的事件回調(diào)中，不然沒辦法響應(yīng)用戶操作。

在移動設(shè)備上按下手指單擊，按先后順序，依次會發(fā)生touchstart->-touchmove（如果有的話）>touchend->mousedown->mousemove（如果有的話）->mouseup->click->dblckick（如果有的話，IOS上不支持dblclick事件，Android支持dblclick事件）。

在2007年蘋果發(fā)布的首款iphone時，其IOS系統(tǒng)的safari，為了將PC端頁面在手機(jī)顯示時避免文字太小，就使用了雙擊縮放。在屏幕上快速連續(xù)單擊兩次，safari的瀏覽器會將網(wǎng)頁放大或者縮小。而所謂click的“300mm”延時就出在這里，當(dāng)用戶按下一個手指單擊時，safari會捕獲這個click事件，但是并不會立馬響應(yīng)其處理函數(shù)，因為瀏覽器還不確定用戶按了這次是不是還要接著按下一次來個雙擊縮放頁面。如果是一個a超鏈接，單擊這個超鏈接，單擊了之后會在300毫秒之后才跳轉(zhuǎn)，300毫秒之內(nèi)又單擊了就認(rèn)定是個雙擊縮放頁面，而不會跳轉(zhuǎn)。

現(xiàn)在的IOS和Android的瀏覽器，還是存在這個特性，手指單擊之后，最先觸發(fā)touchstart，差不多300毫秒后click事件才發(fā)生。要解決這個延時的問題很簡單，并不需要借助zepto還是其他的庫。這個關(guān)鍵就在于，必需禁止移動瀏覽器自帶的雙擊縮放功能，只要禁止之后，這個click延時就不存在。

給文檔加這個頭禁止頁面縮放。對于IOS的safari必需要width=device-width屬性，否則IOS中click就會延時。Android中，user-scalable=no和width=device-width兩個中有一個就可以取消click延時，為了兼容性兩個都寫上。

通過標(biāo)簽取消了click 300毫秒延時之后，當(dāng)按下手指，最先觸發(fā)touchstart，然后再觸發(fā)click時，最短可以只有10毫秒，只要松手指松的足夠快，click就會足夠的塊的響應(yīng)，松的慢就響應(yīng)的慢。只有當(dāng)手指最終松開時click事件才會發(fā)生，但I(xiàn)OS和Android對click的這個處理還是有較大差異，在Android上手指按下去一直不放，差多過了八百毫秒之后，手指再放開后click就不會發(fā)生了。IOS上手指一直按住，按多長時間后再放開，click事件還會發(fā)生。

這就存在一種不確定性，如果用click關(guān)閉一個遮罩層，手指松的早就關(guān)的早，松的遲遮罩就關(guān)的遲，在IOS一直按住按了10秒再松開，click還被觸發(fā)讓遮罩關(guān)閉了，能夠按10秒基本都是要長按，都不是單擊了。

對于要實現(xiàn)tap這個事件，就需要兩個核心，第一個是規(guī)定一個時間，比如150毫秒之內(nèi)松開手指就觸發(fā)tap事件，松慢了tap就不會觸發(fā)而認(rèn)為這是要長按，第二點(diǎn)是tap必需在click事件的后面執(zhí)行，如果tap在click前面執(zhí)行就會產(chǎn)生“點(diǎn)透”的問題。

如果不設(shè)置標(biāo)簽放任瀏覽器的click延時，也可以解決單擊延時。所有諸如zepto.touch.js這類庫，自定義tap事件，它本質(zhì)上就是沒有使用click了，不管click延時不延時，它就是在使用touched來單擊，把用戶定義的單擊操作放到了touchend中進(jìn)行，不管有沒有meta，touched不會有延時。

早期版本的zepto的tap就是如此處理的，tap自定義事件在touchend中觸發(fā)，解決單擊延時的問題。zeopto解決了延時，但是又由于touched會在click之前觸發(fā)，這就又存在“點(diǎn)透”的問題。最新的1.2版zepto.touch.js試圖去解決tap點(diǎn)透的問題，于是在touchend中加了一個setTimeout(callback,0)的異步事件。

但是它不見得好用，第一個問題是，如果沒有設(shè)置meta禁止頁面縮放讓click保持在300毫秒后觸發(fā)，那么設(shè)置不設(shè)置這個setTimeout()異步?jīng)]有區(qū)別，touchend觸發(fā)時候，用戶定義的tap事件也就觸發(fā)了，300毫秒后click又接著觸發(fā)，還是會產(chǎn)生點(diǎn)透。zepto的tap的這個前提，就要求你必需設(shè)置meta讓click盡快觸發(fā)，但是即便設(shè)置了meta，zepto.touch.js還是有個bug會導(dǎo)致點(diǎn)透。在它的源碼中，就像上面那樣，給setTimeout()設(shè)置了0的延時，0延時的異步在PC上沒有問題，在手機(jī)上就有問題，tap會有時會在click前面執(zhí)行有時又會在click后面執(zhí)行導(dǎo)致有時會點(diǎn)透。

tap可以借助touched解決單擊延時，但是本質(zhì)上沒有辦法解決點(diǎn)透，除非瀏覽器允許取消后面要跟隨觸發(fā)的click。要解決點(diǎn)透，只能設(shè)置讓click盡快響應(yīng)，然后再利用setTimout(callback,30)的異步回調(diào)讓用戶自定義tap在click觸發(fā)之后再執(zhí)行，這樣才可以真正避免點(diǎn)透。

同時touched也是在手指最終松開時才觸發(fā)，這會同樣就會產(chǎn)生不確定性，因此也需要一個時間限制，超過了這個時間tap就不再觸發(fā)。zepto.touch.js做了這個處理，但好像是疏忽寫錯了導(dǎo)致這個時間判斷有問題。

“點(diǎn)透”的問題主要存在于一個元素覆蓋在另外一個元素上面時，最常見的就是遮罩層。給上面的遮罩層綁定touchstart之類的事件，在按下手指后，這類touchstart還是touchend都會在click之前發(fā)生，就會產(chǎn)生所謂點(diǎn)透。

在上圖的單擊按鈕上面，通過touchstart在按下手指后立即關(guān)閉遮罩，沒有延時關(guān)閉迅速，但是在手指按下的地方又接著發(fā)生了click事件，而此時遮罩層都已經(jīng)關(guān)閉了又還發(fā)生了click事件，導(dǎo)致click事件被點(diǎn)在button按鈕上，按鈕的click事件處理函數(shù)就被觸發(fā)了，如果這里不是button，而是個input，會導(dǎo)致點(diǎn)這里關(guān)閉了遮罩而下面的input輸入框被聚焦彈出了輸入鍵盤，這就是“點(diǎn)透”。在單頁應(yīng)用，也會一個頁面都切換了，click被點(diǎn)了新的頁面上。

對于自定義DOM事件通過btn.addEventListener("tap",callback,false)，使用瀏覽器原生addEventListener()綁定，這要通過CustomEvent()類來實現(xiàn)。

    var btn=document.getElementById("btn");
    //給button按鈕綁定tap事件
    btn.addEventListener("tap",function(){
        alert("tap事件執(zhí)行");
    },false)
    
    //自定義tap DOM事件
    var event=new CustomEvent("tap",{
        bubbles: true,
        cancelable: true
    });
    
    //觸發(fā)btn上的tap事件
    btn.dispatchEvent(event); 
    

當(dāng)然實際中btn.dispatchEvent(event)肯定要放在其他的事件回調(diào)中，不然沒辦法響應(yīng)用戶操作。

如果只是為了要tap，這段代碼可以取代引入zepto、zeopo.touch還是其他的這類文件。當(dāng)然由于也是借助touched，因此前提也必需設(shè)置禁止頁面縮放才能避免點(diǎn)透。其中給setTimeout()設(shè)置了30毫秒的延時，實際上手機(jī)瀏覽器計時并不準(zhǔn)確，延時定短了tap有可能就在click前面執(zhí)行了。雖然松開手指時touchend和click會一前一后觸發(fā)，但之間的間隔并不是每次都一樣，少的時候只有幾毫米，多的時候有二三十毫秒，因此tap需要延時在30毫秒之后，保證它在click之后執(zhí)行。

如果要在pc上也兼容可以再通過mousedown、mouseup、mousemove來處理，原理一樣，只是做個pc與移動判斷。如果要實現(xiàn)其他的諸如，手指左滑動右滑動事件還是長按等等之類自定義事件，原理基本差不多。