摘要:博主之前已經(jīng)推薦了一款神器下面,就總結(jié)一下移動端遇見的坑。解決原理虛擬鍵盤彈出時將元素設置為,虛擬鍵盤消失時候設置回來。解決方案由于虛擬鍵盤出現(xiàn)并未拋出事件,而檢測或者事件,皆會有一定延遲,會出現(xiàn)閃爍現(xiàn)象。
做過很多移動端的項目,在開發(fā)調(diào)試過程中,一款好的調(diào)試工具會讓效率大大提高。博主之前已經(jīng)推薦了一款神器:http://web.jobbole.com/87587/
下面,就總結(jié)一下移動端遇見的坑。
1.input ? placeholder問題在chrome 模擬移動端調(diào)試時[上圖],顯示的非常正常,但是在真機上[下圖],placeholder里面的內(nèi)容明顯靠上,非常的不美觀
? ??
在國外網(wǎng)站,對這個屬性的兼容性處理,那就是不要設計input的line-height或者設置line-height為normal即可,
試了一下,雖然在谷歌模擬調(diào)試里稍微偏上,但是在“真機上”正常垂直居中~
2.line-h(huán)eightline-height經(jīng)常用于文字居中,不同手機顯示效果不一樣。什么鬼~
在chrome模擬器上又是顯示得非常完美,但是!Android和IOS又各自‘偏移’了。如果把line-height加1px,iPhone文字就會稍微‘正常顯示’,由于我們app的ios用戶居多,并且android機型太多,不同機型也會顯示不同,所以只能退而求其次了。line-height的兼容問題不太好解決,容器高度越小,顯示效果的差距越明顯。
解決方案:稍微大一點的高度,最好把line-height設置為高度+1px,兩個平臺顯示都不會太‘奇怪’。
3.使用rem ?(兼容性:ie9+)原理:瀏覽器的默認字體高都是16px,未經(jīng)調(diào)整的瀏覽器在顯示1em=16px。
rem則是只相對于根元素的font-size,即只需要設置根元素的font-size,其它元素使用rem單位設置成相應的百分比即可;
一般使用:
設置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; }4.實現(xiàn)自定義原生控件的樣式
由于select移動端原生樣式很丑,但是原生彈出樣式是符合我們設計的原則
解決方法:將原本select 設置為透明,z-index設置高~再用一個比較好看的樣式‘假裝’在表面
5.移動端使用innerHtml繪制使用innerHTML繪制大段,之后想獲取HTML的ID節(jié)點,事實上是獲取不到的,這種問題在動態(tài)創(chuàng)建DOM會經(jīng)常發(fā)生
這也是一個神器的問題,博主自己寫了一個移動端輪播插件,在chrome上瀏覽非常正常,但到了真機上卻顯示空白,各種百度,最后才發(fā)現(xiàn)這么坑的地方…
解決方案:嘗試了很多方法之后,老老實實在頁面直接用html結(jié)構,如果有更好的方法,也請告訴我。
6.300ms延遲方案一:禁用縮放
在HTML文檔頭部包含如下meta標簽時:
缺點——就是必須通過完全禁用縮放來達到去掉點擊延遲的目的,然而完全禁用縮放并不是我們的初衷,我們只是想禁掉默認的雙擊縮放行為,這樣就不用等待300ms來判斷當前操作是否是雙擊。
方案二:更改默認的視口寬度
如果設置了上述meta標簽,那瀏覽器就可以認為該網(wǎng)站已經(jīng)對移動端做過了適配和優(yōu)化,就無需雙擊縮放操作了。
這個方案相比方案一的好處在于,它沒有完全禁用縮放,而只是禁用了瀏覽器默認的雙擊縮放行為,但用戶仍然可以通過雙指縮放操作來縮放頁面。
兼容性問題:
對于方案一和方案二,Chrome是率先支持的,F(xiàn)irefox緊隨其后,然而令Safari頭疼的是,它除了雙擊縮放還有雙擊滾動操作,如果采用這種兩種方案,那勢必連雙擊滾動也要一起禁用。
7.點擊穿透問題常見發(fā)生場景: 假如頁面上有兩個元素A和B。B元素在A元素之上。我們在B元素的touchstart事件上注冊了一個回調(diào)函數(shù),該回調(diào)函數(shù)的作用是隱藏B元素。我們發(fā)現(xiàn),當我們點擊B元素,B元素被隱藏了,隨后,A元素觸發(fā)了click事件。
這是因為在移動端瀏覽器,事件執(zhí)行的順序是touchstart > touchend > click。
而click事件有300ms的延遲,當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標簽的href也是click,需要換成js的跳轉(zhuǎn)。
2.改動最小——350ms后再隱藏B元素
8. 虛擬鍵盤導致?fixed?元素錯位fixed元素一定會伴隨虛擬鍵盤的出現(xiàn),但是虛擬鍵盤只是“貼”在了viewport上,表面上不會對dom產(chǎn)生“任何”影響,但是這個時候fixed元素表現(xiàn)卻變得怪異起來,會錯位。
解決原理:虛擬鍵盤彈出時將fixed元素設置為static,虛擬鍵盤消失時候設置回來。
解決方案:由于虛擬鍵盤出現(xiàn)并未拋出事件,而檢測scroll或者resize事件,皆會有一定延遲,會出現(xiàn)閃爍現(xiàn)象。則當前獲取焦點元素為文本元素,就將fixed元素設置為static。
9.移動端手勢手指放在屏幕上:ontouchstart ? ??手指在屏幕上滑動:ontouchmove ? ? ?手指離開屏幕:ontouchend
原理:
1.在touchstart事件觸發(fā)時, ?記錄手指按下的時間startTime,本次滑動的初始位置initialPos。
2.在touchmove事件觸發(fā)時, 記錄當前位置nowPosition(實時移動元素),滑動距離movePosition(當前位置nowPosition與初始位置initialPos的差值),判斷正負數(shù)再決定是左還是右移動。
3.在touchend事件觸發(fā)時, ? 記錄手指離開屏幕的時間endTime,獲得手指在屏幕上停留的時間(endTime-startTime),滑動距離movePosition
判斷是否滑動:
如果停留時間少于300ms,則認為是快速滑動,無論滑動距離是多少,都到下一頁
滑動距離與‘容器’ ?大小進行比較,若超過‘容器’大小的1/3,則到下一頁
10.iphone動態(tài)生成html元素click失效這個也是神奇的坑,找了很久資料,也沒有很原理的解釋。
解決方法: ?為綁定click的元素增加css樣式 ? cursor:pointer;
轉(zhuǎn)載自:http://web.jobbole.com
文章版權歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/111534.html
摘要:移動端布局總結(jié)移動端全兼容的移動端知識涵蓋偽類等全移動端不得不講的頭標簽移動端自適應方案移動端適配總結(jié)布局新舊混合寫法詳解兼容微信使用實現(xiàn)手淘頁面的終端適配淘寶彈性布局方案實踐理解所需的知識產(chǎn)生的小數(shù)像素問題高性能動畫動畫的性能優(yōu)化處理和動 移動端rem布局總結(jié) 移動端全兼容的flexbox 移動端知識(涵蓋、css、偽類等)【全】 移動端不得不講的頭標簽 移動端自適應方案 移動端適...
摘要:背景最近我們微信讀書將寫想法換成了基于的富文本編輯器,遇到了不少問題,這里我將簡單的介紹一下我們在開發(fā)過程中踩到的坑。 背景 最近我們微信讀書將寫想法換成了基于webview的富文本編輯器,遇到了不少問題,這里我將簡單的介紹一下我們在開發(fā)過程中踩到的坑。 實現(xiàn)富文本編輯器有兩個基本思路: 基于native實現(xiàn):比如coretext或者textkit 基于uiwebview實現(xiàn) 第一...
閱讀 965·2023-04-25 23:54
閱讀 3049·2021-11-08 13:21
閱讀 3776·2021-09-27 13:35
閱讀 3395·2021-07-26 23:41
閱讀 1059·2019-08-30 15:52
閱讀 3444·2019-08-30 11:27
閱讀 2100·2019-08-29 18:37
閱讀 543·2019-08-29 17:24