記得剛開始接觸移動端web的時候,書和網上的資料都很少,查起來很費勁,如今比之前要好不少了,但是仍是會有一些剛接觸移動端的朋友會問我一些我最初會遇到的問題,或許是書本寫的並不那麼重,也或許是這些知識寫的太散,以致於大多數人並無很好的注意到。css
其實作移動web前端,大多數和pc端的web前端基本同樣,只是有一些東西須要注意一下,不然帶來的麻煩就不是一星半點了。前端
1、viewportcss3
若是看過移動端web代碼的應該都會看到相似於這一句<meta name="viewport" content="width=device-width">。web
其中,在w3c中對<meta>的解釋是「可提供有關頁面的元信息(meta-information),好比針對搜索引擎和更新頻度的描述和關鍵詞」,我我的的理解就是提供一些頁面的屬性信息,供給給瀏覽器和服務器請求,以便其返回適當的值。而viewprt是其元信息中key-value中的key,意思是虛擬窗口。然後面跟的content是其value,可指定虛擬窗口的寬高。上面那句中「width=device-width」是說虛擬窗口寬度與設備寬度等寬。通俗點說,viewport就是指的相似於咱們PC上瀏覽器的大小,而不是電腦顯示屏的大小。(由於移動端瀏覽器都是全屏的,因此viewport也間接的等於了顯示屏的大小,但這只是個...怎麼說呢,「巧合」吧,哈哈)。
chrome
說到這裏就根本停不下來了,由於還要解釋下虛擬像素和物理像素概念。bootstrap
之前咱們在PC上1像素,2像素都還算比較標準(固然,Mac推出的Retina屏那都是後來的事了),直到iPhone4推出高密度顯示屏,一切就發生了變化。iPhone4物理像素寬是640,可是返回的設備寬度倒是320,也就是說,iPhone4的device-width的值是320px。瀏覽器
可是,注意,通常提到「可是」都是要出事的節奏——可是當咱們不設置viewport的時候,iPhone默認設定的寬度就是980px,好比,咱們作了個320px寬的頁面,不設置viewport,放在iPhone4的Safari瀏覽器裏就會變成下面的樣子服務器
若是咱們設置width=device-width, 或者width=320,再把剛纔的頁面放進去,就會是下面的樣子。dom
也就是說,若是width=device-width了之後,頁面若是超過320px的寬,就會變成下面的樣子了。移動端web
爲何咱們要用iPhone4來舉例呢,那個手機已通過氣了,我上次拿去賣,人家纔給300塊錢收= =...主要是這些最初都是有這個手機引發的,「創世紀」的東西都經典。扯遠了,回來——是否是說頁面寬度設成320就萬事大吉了呢,不是,畢竟市場上設備繁雜,什麼尺寸都有,320只是一部分手機的,Android機的像素比更復雜——對了,像素比!若是用chrome的模擬工具應該都見過這個參數,其實就是物理像素與虛擬像素的比值。
有人可能會問,爲何要搞這麼複雜,這應該是蘋果公司爲了開發人員思考起來不復雜,因此纔會返回這麼個虛擬像素值。可是製做網頁的時候,會有這種考慮——若是要在iPhone4這樣的手機上作一張貫穿左右的圖片,這個圖片是作320的合適,仍是作640的合適?答案是儘可能作640的,由於2倍像素比的手機,顯示1個虛擬像素,要用4個物理像素(田字格,橫2倍,豎2倍),即便圖片等比壓縮,圖片越精細,顯示效果越好,相反,若是320的,也只能適用於320,由於還沒考慮橫屏呢。。。,可是作移動web確定要在不一樣尺寸的設備來顯示,要衡量最大與最小的尺寸,這個就是優化站點的一個內容了,這個之後會說起。
2、頁面的自適應
如今PC端用響應式的主要是國外的一些網站,這一點,他們老是走在前頭。在移動端,響應式通常用於橫屏和豎屏之間的轉換,爲了提高用戶體驗來使用,也就是說,對於瀏覽器,須要多重分界點來判斷,對於移動端,只須要一個分界判斷就行了。
上面說的判斷,主要是指媒體查詢,@media出現比較早,可是用的彷佛並非很普遍,這幾年纔開始用的愈來愈多,並且早期主要是嵌在樣式引入標籤裏,好比:
<link rel="stylesheet" media="only screen and (max-width:320px)" href="style.css" />
可是這麼作,在dom加載的時候,引入的css也是會被下載的,只是不使用而已。並且這還會增長http請求,對於這麼珍貴的請求,這簡直是暴殄呀,固然,這也是一個優化的內容,之後詳述。總之,如今愈來愈多的用在css文件中,採用區塊的方式寫入,等待用戶觸發,具體@media如何來用,外面的資料一大把,去看吧。
還有一種就是「百分比理論」,它也廣泛存在,常常會有人困惑與此,我也不例外,到底採用哪種更適合開發移動站。
百分比理論其實有點和bootstrap的流式柵格化相似,按照百分比來設定web頁面內的元素尺寸,這樣,在什麼樣的設備均可以有一個比較「和諧」的展現,可是「放縱」終歸是會露尾巴的,尺寸一但誇張一點就會看起來很是彆扭,因此,按照實際項目本身忖度這個使用度,用好了,可讓用戶感受不到響應的縫隙,結合起來去作,仍是頗有意思的。
3、px、em與rem
w3c裏面對css的尺寸單位定義的不少,可是經常使用的只有兩個,px和em,rem是css3新增的,其實本質也是em,只不過是root em => rem。曾有一段時間em火了,後來又滅了,rem又火了,爲何呢,這個問題要從這些單位的區別來講起。
px:像素 ,計算機屏幕上的一個點(引用自w3school);em:相對尺寸,相對於上一級元素尺寸的倍數,值能夠是浮點數;rem,如上述,相對於根節點字體大小的倍數。
最初的時候,瀏覽器只有改變字體大小的能力,em是相對大小,因此佈局起來更給力,後來瀏覽器能力強了,不僅是字體,能夠全局改變,再加上em根據上級改變的特性,讓其修改的時候很是難掌控,容易出現牽一髮動全身,而我只是想撓撓頭而已的尷尬局面,因此人們又開始青睞簡單的px。不過好在css3推出了rem,這個根據根節點來改變大小的特性,使得人們對他的愛愈來愈多。
瀏覽器默認字體大小通常16px,也就是1em,也就是100%,爲了使開發者用起來更直觀,能夠設定全局字體尺寸爲62.5%,也就是說全局大小爲16*62.5%=10px,這樣,12px=1.2rem了,可以和px互相轉換,可讓咱們對字體大小值有個比較清晰該概念。
這個不止在移動端,在PC端一樣適用,這個時候,改全局就只須要改root的尺寸就行了。
再囉嗦一句,62.5%怎麼來的呢?1em分紅16份,1px = 0.0625em,10px = 0.625em = 62.5%,這樣,假設我想設定一個18px大小的rem,那就是18/10 = 1.8rem.