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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于自定義DOM事件通過(guò)btn.addEventListener("tap",callback,false)，使用瀏覽器原生addEventListener()綁定，這要通過(guò)CustomEvent()類來(lái)實(shí)現(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)然實(shí)際中btn.dispatchEvent(event)肯定要放在其他的事件回調(diào)中，不然沒(méi)辦法響應(yīng)用戶操作。

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

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