移動端H5的一些基本知識點總結

標籤：功能   width   post   原創   java   ret   計算   log   hone   

移動端H5的一些基本知識點總結

來到這家公司之後,和曾經的工作發生了非常大的轉變.曾經我一直是做PC端頁面的.來到如今這家公司之後,主要是做手機移動端的頁面.

移動端的頁面在我這個做習慣了PC端頁面的人看來,應該是非常easy的一些事情.可是在上手的過程其中,還是發現,原來移動端儘管DOM結構要簡單得多,可是須要注意的細節,還是非常多的.原因非常easy,那就是,你必須考慮全部的手機上不同解析度的展示效果.

移動端的解析度有哪些呢?

以iphone為例,有下面解析度

iphone4 640*960
iphone5 640*1136
iphone6 750*1334
iphone6plus 1242*2208

安卓陣營的解析度曾經各式各樣,如今基本分為三個

720P 720*1280
1080P 1080*1920
2K 1440*2560

這是一個幻覺,事實上,在做手機H5的時候,解析度根本不時這個樣子的….愁死人了,他們在瀏覽器中的真實解析度是

以iphone為例,有下面解析度

iphone4 320*480
iphone5 320*568
iphone6 375*667
iphone6plus 414*736

安卓陣營的解析度曾經各式各樣,如今基本分為三個

720P 360*640
1080P 360*640
2K 360*640

看到這個你是不是暈了…原來,安卓比蘋果強多了…呵呵,還真是這個樣子

事實上,我們要做的是一個自適應的網頁,並且,這個自適應範圍的最低寬度為320px,也就是說,你的代碼必須保證在寬度320的時候是能夠瀏覽的,不能擠壓變形

移動端使用什麼單位?

在PC端製作網頁的時候,我們都習慣了的單位是px,那麼是不是在移動端我們也用這個單位呢?

我僅僅能說,你能夠這樣做.可是,最好不要.由於你不知道將來會發生什麼.

我們經過一些探討,和參考眼下國際上通行的方案,採用的單位是rem

那麼,什麼是rem?我們都知道em是相對父級的尺寸單位.那麼rem是root-em的縮寫,也就是說,是根相對單位,其相對的是html的font-size的單位.

好了,那麼html的font-size預設是多大呢?是16px.也就是說,你的全部的尺寸依靠,都是根據16px的相對運算的結果.

知道了這個之後,我們就開始了複雜的計算,比方,我要設定一個12px 的文字,須要用什麼百分比.會發現,這個計算真心是坑爹啊,我在一個項目的一期就是這樣做的.可是這個計算真心累.

於是,我們採用了變通的方法,我們給html改動預設的font-size.於是,我們是這樣寫的.

html {font-size: 10px;}

整個世界都安靜了,依照這種方法計算,真的特別方便,比方,我須要12px我就寫1.2rem 就能夠了.

可是,我迅速思考了一下這個問題,感覺我們在脫褲子放屁.

讓我們回到起點,我們為什麼要用rem而不用px呢?原因非常easy,我們是為了讓頁面不會由於一些裝置的特殊性而限定為px,是為了去適應各種裝置.

而我們給html加上了px為單位的,不是又返回原樣了嗎?

那到不如直接去使用px,我們還少寫兩個字元呢.

那麼,問題沒有解決辦法了嗎?還是繼續回到那反人類的計算其中去??

我迅速轉換了一下思維,把這段代碼改成了

html {font-size: 62.5%;}

改成了百分比之後,這個問題迅速得到瞭解決.那樣,瀏覽器在設定不同的預設文字大小的時候,我們的頁面都能夠尾隨改變,而不在限定死了.

在PC端chrome瀏覽器中,預設最小文字是 12px 當你設定為這樣之後利用開發人員工具進行調試的時候,會發現有一些詭異的地方.因此,須要將瀏覽器的最小文字設定為10或者6,一般都設定到6,這樣能夠解決在PC端調試的問題.在移動端是沒有這個限制的(有,但預設關閉)

移動端html5頁面 Meta設定

這個有專門的文章,能夠百度一下,在這裡我強調一點,須要加上下面的代碼.

<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no">

盒子寬度

有一些人,包含某些知名的前端架構,會給css中加上這樣一段代碼:

* {box-sizing:border-box;}

我個人強烈不推薦這樣做.由於這破壞了盒子模型,儘管加上了這個之後,你寫代碼是方便了,可是當你引入某些外置資源的時候,你會發現變形到你根本調不回來的節奏.原因非常easy,這一句代碼,會改變頁面全部的元素的盒子模型.

曾經由於這一句代碼,讓我們前端的人排查一個問題排查了兩天,始終無法解決.當我接手了項目之後,這個問題交給我,我一開始也莫名其妙.可是後來細緻檢查,才發現是這一句代碼惹的禍.

假設我們須要寫一個盒子,預設是百分百寬的,我們怎麼做呢?

答案是,我們什麼都不做,那麼它就是百分百了.

在做移動端頁面的時候,盡量不要設定寬度,讓它自然的佔領一行,這時候我們能夠根據須要設定外填充和內填充.

當然,並不是全部的東西都能夠這樣來做,總會遇到多欄版面配置的時候

這就須要注意了,不要給rem這種單位的寬度,而是要給50%或者33.3%的寬度.

在設定了這種寬度之後,不要給這個元素設定內填充和外填充.假設有須要的話,在這個元素裡面再寫一個元素,給這個元素加你所須要的填充.

另外,在布局上,要盡量少用浮動布局,適當在細節部分使用定位布局,並做好隱藏溢出等處理.以防止浮動布局可能出現的問題.關於定位問題,能夠參考我的另外一篇博文 Css 具體解讀定位屬性 position 以及參數;

邊框的處理

在PC端的網頁製作中,我們一般就使用邊框屬性border: 1px solid #ddd;可是在移動端,就須要特別注意了,由於邊框的寬度是計算在盒子模型其中的,所以,假設你使用不慎,可能造成你布局的困境.

因此,我們須要一些其它的參數來設定邊框,一般矩形的元素,我們能夠使用outline: 1px solid #ddd;來製作邊框,這個屬性是不會計算在盒子模型其中的.

另外,當你嘗試做一個兩列布局的列表的時候,使用這個參數,你會發現兩個元素之間的邊框好像是兩個像素.對的,你沒有看錯,確實是兩個像素.

怎麼解決問題呢?

普通情況下,你僅僅須要給元素加上背景就能夠解決問題.後面的元素的背景會遮住前面元素的outline發出來的邊框.

這是一個非常有用的技巧.

可是,假設元素不是矩形的怎麼辦呢?

事實上非常好解決.由於,在CSS中,不僅僅是outline能夠來類比邊框,另一個屬性,也是能夠類比邊框的,那就是CSS3的box-shadow外光暈屬性.

比如,我要給元素加上一個1px的實線邊框,你這樣寫,是不行的box-shadow:0 0 1px #ddd;你會發現,你類比出來的邊框會有點發虛.

正確的寫法是box-shadow:0 0 0 1px #ddd;看到這樣寫非常奇怪?去w3school看下就明確了.

當然,這兩種做法都是有弊端的,比方我就想設定一條左邊框的線條,而不時整個的都有邊框怎麼辦?

還是有辦法的,我們能夠藉助虛擬元素來實現類比,:before和:after;具體怎麼實現,這裡不做示範了.

這裡須要說明一下,網上有不少0.5px邊框的實現教程,這樣做的優點是,能夠做出比較細的線條,讓我們的H5看上去更像原生的APP.我個人的建議是,不要嘗試這樣做,由於非常麻煩,並且相容性都有問題,得不償失.那麼正確的做法是什麼呢?

非常easy——跟你的設計師說,盡量不要設計線條-_-|||反正我就是這樣跟我們團隊的設計說的.

使用jquery還是zepot?

為什麼使用zepot?

原因僅僅有一個,它小.還有其它的優點嗎?沒發現.

我個人的建議是使用jquery2.x的版本號碼,優點有例如以下

1. 擁有大量的外掛程式能夠使用
2. 功能比zepot強大太多
3. 效能比zepot強大
4. 習慣了jquery

很多其它內容,請參閱為什麼我們放棄了 Zepto

總結

在移動端製作網頁和在PC端有非常大的不同.在移動端的非常多經驗拿到移動端來是沒有作用的,可能還會起到反作用.當我們從PC端前端project師轉向到移動端前端project師的時候,須要耐心的解決一些問題,一個一個坑的去踩,才幹不斷的進步.

FungLeo原創,轉載請保留版本號碼申明,和首發地址http://blog.csdn.net/fungleo/article/details/50811739

移動端H5的一些基本知識點總結