移動端300ms相容問題(移動端經典問題)

2022-06-23 19:57:11 字數 1617 閱讀 9629

2007 年初。蘋果公司在釋出首款 iphone 前夕,遇到一個問題:當時的**都是為大螢幕裝置所設計的。於是蘋果的工程師們做了一些約定,應對 iphone 這種小螢幕瀏覽桌面端站點的問題。

雙擊縮放(double tap to zoom),這也是會有上述 300 毫秒延遲的主要原因。雙擊縮放,即用手指在螢幕上快速點選兩次,ios 自帶的 safari 瀏覽器會將網頁縮放至原始比例。

假定這麼一個場景。使用者在 ios safari 裡邊點選了一個連結。由於使用者可以進行雙擊縮放或者單擊跳轉的操作,當使用者一次點選螢幕之後,瀏覽器並不能立刻判斷使用者是確實要開啟這個連結,還是想要進行雙擊操作。因此,ios safari 就等待 300 毫秒,以判斷使用者是否再次點選了螢幕。

鑑於iphone的成功,其他移動瀏覽器都複製了 iphone safari 瀏覽器的多數約定,包括雙擊縮放,幾乎現在所有的移動端瀏覽器都有這個功能。

1. faskclick 

2.禁用遊覽器縮放

表明這個頁面是不可縮放的,那雙擊縮放的功能就沒有意義了,此時瀏覽器可以禁用預設的雙擊縮放行為並且去掉300ms的點選延遲。

這個方案有一個缺點,就是必須通過完全禁用縮放來達到去掉點選延遲的目的,然而完全禁用縮放並不是我們的初衷,我們只是想禁掉預設的雙擊縮放行為,這樣就不用等待300ms來判斷當前操作是否是雙擊。但是通常情況下,我們還是希望頁面能通過雙指縮放來進行縮放操作,比如放大一張,放大一段很小的文字。

3.更改預設的視口寬度

一開始,因為雙擊縮放主要是用來改善桌面站點在移動端瀏覽體驗的。 隨著發展現在都是專門為移動開發專門的站點,這個時候就不需要雙擊縮放了,所以移動端瀏覽器就可以自動禁掉預設的雙擊縮放行為並且去掉300ms的點選延遲。如果設定了上述meta標籤,那瀏覽器就可以認為該**已經對移動端做過了適配和優化,就無需雙擊縮放操作了。

這個方案相比方案一的好處在於,它沒有完全禁用縮放,而只是禁用了瀏覽器預設的雙擊縮放行為,但使用者仍然可以通過雙指縮放操作來縮放頁面。

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延時現象。