摘要：博主之前已經(jīng)推薦了一款神器下面，就總結(jié)一下移動端遇見的坑。解決原理虛擬鍵盤彈出時將元素設(shè)置為，虛擬鍵盤消失時候設(shè)置回來。解決方案由于虛擬鍵盤出現(xiàn)并未拋出事件，而檢測或者事件，皆會有一定延遲，會出現(xiàn)閃爍現(xiàn)象。

做過很多移動端的項目，在開發(fā)調(diào)試過程中，一款好的調(diào)試工具會讓效率大大提高。博主之前已經(jīng)推薦了一款神器：http://web.jobbole.com/87587/

下面，就總結(jié)一下移動端遇見的坑。

在chrome 模擬移動端調(diào)試時［上圖］，顯示的非常正常，但是在真機(jī)上［下圖］，placeholder里面的內(nèi)容明顯靠上，非常的不美觀

? ??

在國外網(wǎng)站，對這個屬性的兼容性處理，那就是不要設(shè)計input的line-height或者設(shè)置line-height為normal即可，

試了一下，雖然在谷歌模擬調(diào)試?yán)锷晕⑵?，但是在“真機(jī)上”正常垂直居中～

line-height經(jīng)常用于文字居中，不同手機(jī)顯示效果不一樣。什么鬼～

在chrome模擬器上又是顯示得非常完美，但是！Android和IOS又各自‘偏移’了。如果把line-height加1px，iPhone文字就會稍微‘正常顯示’，由于我們app的ios用戶居多，并且android機(jī)型太多，不同機(jī)型也會顯示不同，所以只能退而求其次了。line-height的兼容問題不太好解決，容器高度越小，顯示效果的差距越明顯。

解決方案：稍微大一點的高度，最好把line-height設(shè)置為高度+1px，兩個平臺顯示都不會太‘奇怪’。

原理：瀏覽器的默認(rèn)字體高都是16px，未經(jīng)調(diào)整的瀏覽器在顯示1em=16px。

rem則是只相對于根元素的font-size，即只需要設(shè)置根元素的font-size，其它元素使用rem單位設(shè)置成相應(yīng)的百分比即可；

一般使用：

設(shè)置html的font-size為62.5%

html {????
    font-size: 62.5%;
}
body {????
    font-size: 12px;????
    font-size: 1.2rem;
}
p {????
    font-size: 14px;????
    font-size: 1.4rem;
}

由于select移動端原生樣式很丑，但是原生彈出樣式是符合我們設(shè)計的原則

解決方法：將原本select 設(shè)置為透明，z-index設(shè)置高～再用一個比較好看的樣式‘假裝’在表面

使用innerHTML繪制大段，之后想獲取HTML的ID節(jié)點，事實上是獲取不到的，這種問題在動態(tài)創(chuàng)建DOM會經(jīng)常發(fā)生

這也是一個神器的問題，博主自己寫了一個移動端輪播插件，在chrome上瀏覽非常正常，但到了真機(jī)上卻顯示空白，各種百度，最后才發(fā)現(xiàn)這么坑的地方…

解決方案：嘗試了很多方法之后，老老實實在頁面直接用html結(jié)構(gòu)，如果有更好的方法，也請告訴我。

方案一：禁用縮放

在HTML文檔頭部包含如下meta標(biāo)簽時：

缺點——就是必須通過完全禁用縮放來達(dá)到去掉點擊延遲的目的，然而完全禁用縮放并不是我們的初衷，我們只是想禁掉默認(rèn)的雙擊縮放行為，這樣就不用等待300ms來判斷當(dāng)前操作是否是雙擊。

方案二：更改默認(rèn)的視口寬度

如果設(shè)置了上述meta標(biāo)簽，那瀏覽器就可以認(rèn)為該網(wǎng)站已經(jīng)對移動端做過了適配和優(yōu)化，就無需雙擊縮放操作了。
這個方案相比方案一的好處在于，它沒有完全禁用縮放，而只是禁用了瀏覽器默認(rèn)的雙擊縮放行為，但用戶仍然可以通過雙指縮放操作來縮放頁面。

兼容性問題：

對于方案一和方案二，Chrome是率先支持的，F(xiàn)irefox緊隨其后，然而令Safari頭疼的是，它除了雙擊縮放還有雙擊滾動操作，如果采用這種兩種方案，那勢必連雙擊滾動也要一起禁用。

問題常見發(fā)生場景： 假如頁面上有兩個元素A和B。B元素在A元素之上。我們在B元素的touchstart事件上注冊了一個回調(diào)函數(shù)，該回調(diào)函數(shù)的作用是隱藏B元素。我們發(fā)現(xiàn)，當(dāng)我們點擊B元素，B元素被隱藏了，隨后，A元素觸發(fā)了click事件。

這是因為在移動端瀏覽器，事件執(zhí)行的順序是touchstart > touchend > click。

而click事件有300ms的延遲，當(dāng)touchstart事件把B元素隱藏之后，隔了300ms，瀏覽器觸發(fā)了click事件，但是此時B元素不見了，所以該事件被派發(fā)到了A元素身上。

如果A元素是一個鏈接，那此時頁面就會意外地跳轉(zhuǎn)。

解決思路：

1.不要混用touch和click

2.消耗掉touch之后的click

解決方法：

1.只用touch ??把頁面內(nèi)所有click全部換成touch事件（?touchstart?、’touchend’、’tap’），注意：a標(biāo)簽的href也是click，需要換成js的跳轉(zhuǎn)。

2.改動最小——350ms后再隱藏B元素

fixed元素一定會伴隨虛擬鍵盤的出現(xiàn)，但是虛擬鍵盤只是“貼”在了viewport上，表面上不會對dom產(chǎn)生“任何”影響，但是這個時候fixed元素表現(xiàn)卻變得怪異起來，會錯位。

解決原理：虛擬鍵盤彈出時將fixed元素設(shè)置為static，虛擬鍵盤消失時候設(shè)置回來。

解決方案：由于虛擬鍵盤出現(xiàn)并未拋出事件，而檢測scroll或者resize事件，皆會有一定延遲，會出現(xiàn)閃爍現(xiàn)象。則當(dāng)前獲取焦點元素為文本元素，就將fixed元素設(shè)置為static。

手指放在屏幕上：ontouchstart ? ??手指在屏幕上滑動：ontouchmove ? ? ?手指離開屏幕：ontouchend

原理：

1.在touchstart事件觸發(fā)時， ?記錄手指按下的時間startTime，本次滑動的初始位置initialPos。

2.在touchmove事件觸發(fā)時， 記錄當(dāng)前位置nowPosition（實時移動元素），滑動距離movePosition（當(dāng)前位置nowPosition與初始位置initialPos的差值），判斷正負(fù)數(shù)再決定是左還是右移動。

3.在touchend事件觸發(fā)時， ? 記錄手指離開屏幕的時間endTime，獲得手指在屏幕上停留的時間（endTime－startTime），滑動距離movePosition

判斷是否滑動：

如果停留時間少于300ms，則認(rèn)為是快速滑動，無論滑動距離是多少，都到下一頁

滑動距離與‘容器’ ?大小進(jìn)行比較，若超過‘容器’大小的1/3，則到下一頁

這個也是神奇的坑，找了很久資料，也沒有很原理的解釋。

解決方法： ?為綁定click的元素增加css樣式 ? cursor：pointer；

轉(zhuǎn)載自：http://web.jobbole.com