您好,登錄后才能下訂單哦!
小編給大家分享一下移動端頁面布局應該怎么弄,希望大家閱讀完這篇文章后大所收獲,下面讓我們一起去探討吧!
什么是viewport
簡單來講,viewport就是瀏覽器上,用來顯示網頁的那一部分區域了,也就是說,瀏覽器的實際寬度,是和我們手機的寬度不一樣的,無論你的手機寬度是320px,還是640px,在手機瀏覽器內部的寬度,始終會是瀏覽器本身的viewport。如今的瀏覽器,都會給自己的本身提供一個viewport的默認值,可能是980px,或者是其他值。就以手機來說吧,目前,新版本的手機瀏覽器,絕大部分是以980px作為默認的viewport值的。我這里對新版本的不同平臺下的瀏覽器做了測試,經過測試,iphone下的默認viewport為980px,安卓下的瀏覽器,目前主流的最新瀏覽器(比如chrome,還有很多國產的像qq,uc)的viewport也是980px了。
viewport是用來干什么的
viewport的默認值,一般來說是大于手機屏幕的。這樣就可以做到當我們在瀏覽桌面端網頁的時候,可以讓桌面端端網頁正常顯示(我們普通頁面設計的時候,一般頁面的主區域是以960px來做的,所以980px這個值,可以做到桌面端網頁的正常顯示)。但是,其實我們手機的屏幕寬度是沒有960px的,因此瀏覽器會出現橫向滾動條。同時,即使是基于980的viewport,我們在移動端瀏覽我們的桌面頁面的體驗其實也并不好,所以,一般的,我們會專門給瀏覽器設計一個移動端的頁面。
對viewport的控制
如今可以絕大部分瀏覽器里(即主流的安卓瀏覽器和ios),都支持對viewport的一個控制了。一般的,我們會這么寫。
viewport默認有6個屬性
我們把這個標簽是在head里面,像這樣
<meta name="viewport" content="initial-scale=1">
這樣就可以做到對viewport的控制了
width: 設置viewport的寬度(即之前所提及到的,瀏覽器的寬度詳),這里可以為一個整數,又或者是字符串"width-device"
initial-scale: 頁面初始的縮放值,為數字,可以是小數
minimum-scale: 允許用戶的最小縮放值,為數字,可以是小數
maximum-scale: 允許用戶的最大縮放值,為數字,可以是小數
height: 設置viewport的高度(我們一般而言并不能用到)
user-scalable: 是否允許用戶進行縮放,'no'為不允許,'yes'為允許
三個需要了解的概念:
PPI: 可以理解為屏幕的顯示密度
DPR: 設備物理像素和邏輯像素的對應關系,即物理像素/邏輯像素
Resolution: 就是我們常說的分辨率
物理像素與邏輯像素
看了我們上面內容一的第一點之后,或許有些人會有些疑問,我的安卓手機,或者iphone6plus(目前應該僅限于這一款機型吧),買回來的是1920x1080的或者其他更高的,比我之前所謂的那個viewport默認的980px要大。
這樣的問題,也就是我之前所說的物理像素與邏輯像素的關系了(即DPR)。以1920x1080為例,1080為物理像素,而我們在viewport中,獲取到的,比如"width-device",是邏輯像素。所以之前viewport的默認值,所比對的大小,其實是邏輯像素的大小,而非物理像素的大小。
以iphone6為例,在不做任何縮放的條件下,iphone6的獲取到的'width-device'為375px,為屏幕的邏輯像素。而購買時我們所知的750px,則為屏幕的物理像素。
CSS的問題
有了上面第二點的一些基礎,還是以iphone6為例,我們可以知道,其實我們所寫的1px,在iphone6上為2px的物理像素。所以,最后的,給出一個結論。就是我們寫的1px,在移動端,是邏輯像素的1px,而非物理像素的1px。
簡單說下rem
rem是根據頁面的根元素的font-size的一個相對的單位,即
html{ font-size: 16px; }
比如當我們在一個div中,如此寫
div{ width: 2rem; }
那么我們的width,是16*2 = 32px
rem做到適配不同分辨率
這個是現在手機淘寶的移動端的解決方案,即使用rem的特性,來對頁面進行布局。
下面舉一個例子
假定設計稿的大小為750,那么我們則將整個圖分成100份來看(下面的題外話會說明為什么會分成100份來看)
那么,我們現在就讓根部元素的font-size為75px
html{ font-size: 75px; }
那么,我們現在就可以比對設計稿,比如設計稿中,有一個div元素,寬度,高度都為75px,那么我們這樣寫即可
div{ height: 1rem; width: 1rem; }
可能看到這里,一些人還是不明白怎么用rem做到適配不同的分辨率,那么我們再來
現在,我們換設備了,不用這個設備是一個width為640的手機
那么這個時候,我們的rem單位就起到作用了。
我們的rem全是根據html的font-size來改變的,所以說,這個時候,我們只需要把html下的font-size改成64px。那么,我們之前的div,因為是根據html下的font-size動態變化的,那么。此時也就變成了寬度和高度都為64px的東西了。這樣,就可以做到適配不同的屏幕分辨率了。(其實就是個等比縮放)
總結一下,我們的解決方案,其實就是 設計稿的像素/html的font-size = 用來代替px的rem。
這一個步驟,我們需要通過JS來進行操作。
對于js的操作在下面會提到。
DPR的問題
視覺姐姐給了我們設計稿,并交由我們實現,那么,我們應該去認真的實現:-)(試想你做了一張圖,而前端很多地方并沒有按照你所想的,你所給的去做,而是私自改變了很多東西,你肯定會不高興的)
那么1px會出現什么問題呢。
還記得我們第二大點講的,我們的設備,是有物理像素和邏輯像素的。而假設我們的設計稿是750的,同時還是以iphone6為例,此時如果我們的viewport是這樣的
<meta name="viewport" content="initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no">
之前說過,在不做任何縮放的條件下,iphone6獲取到的viewport為375px。
然后我們的頁面中有個div,他有一個邊框值,如下
div{ height: 5rem; widht:5rem; border: 1px solid #000 }
此時我們寫的1px,實際上是邏輯像素,而我們在iphone6上看到的是物理像素,于是這個時候,我們眼睛所看到的其實是2px(參考第二點第三個問題)
所以此時我們需要在viewport上做文章了,此時先明確,如果要獲取到真正的1px,那么我們需要這么做,將viewport改為
<meta name="viewport" content="initial-scale=0.5, maximum-scale=0.5, minimum-scale=0.5, user-scalable=no">
即對屏幕做0.5倍的縮放。這樣,我們就能得到實際的1px。
所以到這里,我們還要明確一點,viewport的meta標簽,我們這里也只能通過js來動態生成。
同時,這樣寫,據說還可以避免比如inline的SVG等元素按照邏輯像素的渲染。避免了整個頁面清晰度的打折(其實我并不能看出來)
文字適配問題
最近深深糾結與rem與px做字體單位的問題,還是先分別談下二者吧。
rem與px的特點:
字體大小引發的系列問題:
文字適配的解決方案:
上面說了這么多,我們總要有一套解決方案吧
對于一些標題性的文字,我們依然可以用rem。讓他隨著屏幕來進行縮放,因為標題性文字一般較大,而較大的文字,點陣對其影響就越小。這樣,即使出現奇怪的尺寸,也能夠讓字體得到很好的渲染。
對于一些正文內容的文字(即站在使用者的角度,你不希望他進行縮放的文字)。我們采用px來進行處理。
倘若一個字體,只提供了12px,14px,16px的點陣。那么當你寫13px,15px,17px的時候。就并沒有其字體大小所對應的點陣。那么這樣就造成了一個問題。他們會使用其相鄰的點陣,比如對應使用了12px,14px,16px的點陣,而導致一個問題,文字占用的大小確實改變,但點陣卻并沒有改變。
字體大小:我們平時也看過,很多網站,是不以奇數作為字體大小的。我稍微查了些東西,在知乎上的現在網頁設計中的為什么少有人用 11px、13px、15px 等奇數的字體?問題下,有一些比較好的解答,我就不再多說(我也并不能比這個問題說的更多),總的來說,其實就是偶數寬度的字體能夠顯得均衡,以及一個點陣的問題。不過因為要談及點陣,所以我拿上面回答中的一個內容舉例。
以rem作為字體單位:我們可以讓頁面整體的文字,也跟隨著html的font-size來進行改變,這樣,在不同的屏幕下,可以做到文字相對屏幕的比例是一樣的。
以px作為字體單位: 這個是目前很多網站還是依然采用的方法。因為以上面所寫的,以rem作為字體單位。無論在任何屏幕下面,我們的文字都會根據屏幕做一個適應。試想這樣一個場景。你買了一個大屏手機(5.7寸的),而別人用的是4寸的手機。以rem作為字體單位的話,那大屏手機看到的文字多少和小屏手機確實一樣的了。這樣來做,其實并不符合我們買大屏手機的期待。同時,以rem作為字體單位,可能會導致出現很多奇怪的字體大小(畢竟是根據html的font-size動態變化的嘛),同時這其中還涉及到了一個點陣尺寸的概念,這個在下面來講。
在 三.使用rem布局 里面,我們給出了各種情況的解決方案,并且,在我舉例的時候,熱衷于使用iphone來舉例,但其實,上面的所有問題,不是僅僅iphone會出現的問題,安卓也是一樣。但是,如果你已經看完了上面,那么這里,才是真正給出我們解決方案的地方,并且,這個解決方案并不完善。
談談iphone的r屏與安卓的各種屏
rem布局也好,用viewport進行縮放也罷,文字的適配問題也是,都是基于我們想對各個不同的設備所進行的匹配。這套方案很好,然而也有其兼顧不到的地方。即安卓和ios的屏幕的一些問題,當然,細的東西我們不談,我們只談dpr。
安卓并沒有對自己的屏幕叫做r屏,但是其原理和iphone的r屏可以說是一樣。r屏做的是什么,把兩個(三個)物理像素,丟到了一個邏輯像素里面,讓屏幕展現的更清晰(當然,這是我片面的理解,不過我覺得大體來說并沒有錯,我們也不用去深入探討r屏還有什么東西,我也并不懂)。而安卓也是一樣,他也同樣把n個物理像素丟到了一個邏輯像素里面。而這里的n,也就是dpr值(所以當我看到好多人問安卓為什么不采用r屏的時候,我真的也是……醉了?)。而安卓的dpr值,并不像iphone那樣,就只有兩個值。安卓的dpr是千奇百怪的,可能是1.5,2,3,4,2.5等等的都有。(甚至我還看到了1.7之類的,安卓的各個設備商,玩的真尼瑪high啊。怎么高興怎么來。)
所以,對安卓的屏幕的dpr的處理,其實是很頭疼的,因為,他和我們對字體的處理,有了很大的沖突。這個在下面提及
其實iphone為開發者考慮到了很多東西,為了讓開發者便于開發,在6plus出現之前,iphone的dpr始終也就是2(即前面所談的物理像素/邏輯像素=2),即使是6plus出現了,iphone到底其實也就只有2,3這兩個dpr。我們很容易對其做到兼顧。
先談iphone
再談安卓
首先看看手淘的解決方案
rem布局
用js獲取到頁面的寬度,然后對其進行寬度/10的處理,再將其寫到html的font-size中。手淘的flexible.js里面的這一部分,并為了方便看懂做了些改寫。大體就是這樣的
function refreshRem(){ var docEl = window.document.documentElement; var width = docEl.documentElement.getBoundingClientRect().width; var rootSize = width/10; docEl.style.fontSize = rootSize + 'px'; }
dpr的配置
首先,在引入flexible.js之前,我們可以對dpr進行手動的配置,即使用自定義的meta標簽來配置dpr(看清楚是flexible,而非viewport)
<meta name="flexible" content="initial-dpr=2,maximum-dpr=3" />
iniital-dpr是把dpr強制設定為給定的值,而maximum-dpr則是給出一個最大的dpr限制,然后對其和系統的dpr做一個比較。
然后依然為了方便閱讀我把flexble.js這一部分的代碼抽象出來,
var doc = window.document var metaEl = doc.querySelector('meta[name="viewport"]'); var flexibleEl = doc.querySelector('meta[name="flexible"]'); var dpr = 0; var scale = 0; //縮放比例 //在meta標簽中,已經有了viewport,則使用已有的viewport,并根據meta標簽,對dpr進行設置 if (metaEl) { console.warn('將根據已有的meta標簽來設置縮放比例'); var match = metaEl.getAttribute('content').match(/initial\-scale=([\d\.]+)/); if (match) { scale = parseFloat(match[1]); dpr = parseInt(1 / scale); } //如果在meta標簽中,我們手動配置了flexible,則使用里面的內容 } else if (flexibleEl) { var content = flexibleEl.getAttribute('content'); if (content) { var initialDpr = content.match(/initial\-dpr=([\d\.]+)/); var maximumDpr = content.match(/maximum\-dpr=([\d\.]+)/); if (initialDpr) { dpr = parseFloat(initialDpr[1]); scale = parseFloat((1 / dpr).toFixed(2)); }
if (maximumDpr) {
dpr = parseFloat(maximumDpr[1]);
scale = parseFloat((1 / dpr).toFixed(2));
}
}
}
這樣,我們通過flexible的分析與獲取,對dpr進行了書寫。不過其實這里,是有個問題的。即在書寫maximum的的情況下,其實根本沒有像文檔中給我們的說法一樣,做一個比較,而是做了和initialDpr一樣的一個處理。不過這里也不對其做一個探討了。
然后,這套解決方案,然后當我們在meta標簽里面并沒有對viewport以及flexible兩個的任意一個進行書寫的時候,他也是會自動獲取一個dpr值的
if (!dpr && !scale) { var isAndroid = window.navigator.appVersion.match(/android/gi); var isIPhone = window.navigator.appVersion.match(/iphone/gi);、 //devicePixelRatio這個屬性是可以獲取到設備的dpr的 var devicePixelRatio = win.devicePixelRatio; if (isIPhone) { // iOS下,對于2和3的屏,用2倍的方案,其余的用1倍方案 if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) { dpr = 3; } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){ dpr = 2; } else { dpr = 1; } } else { // 其他設備下,仍舊使用1倍的方案 dpr = 1; } scale = 1 / dpr; }
這里我們可以看到,手機淘寶并沒有對安卓的dpr進行一個適配,原因之后再講。
然后到了這里,我們獲取到了我們需要的dpr值,并根據dpr值獲取到了我們所需要的縮放值(即scale)
然后我們要做的,就是在并沒有viewport的meta標簽對情況下自己動態將這個標簽寫進我們的header,形式是這樣的
<meta name="viewport" content="initial-scale=scale, maximum-scale=scale, minimum-scale=scale, user-scalable=no">
這樣,dpr的配置,也就完成了,當然,安卓設備并沒有對dpr進行一個配置(上面的動態生成就不給出js了)
文字的解決方案
由于手淘暫時并沒有對安卓做一個處理,所以,這里,只是對iphone做了一個處理
即在html上,加入了一個自定義屬性,data-dpr。
<html data-dpr='dpr'></html>
還是以750的設計稿為例(即iphone6)
假如設計稿上某a標簽是32px,那么,我們要這么寫
a{ font-size: 16px } /*iphone6*/ [data-dpr='2'] a{ font-size: 32px } /*iphone6plus*/ [data-dpr='3'] a{ font-size: 32px }
現在的一些問題
正如我們看到的,手淘目前的方案里面,是沒有考慮到安卓dpr的問題的。即,這套方案,只對于iphone的r屏做了一個處理,而對于安卓,并沒有做dpr的處理。我們來分析下原因吧(個人拙見)。
我們希望字體能夠以px來展現,同時,我們也希望我們的東西能對dpr做一個適配。對于ios,這自然是可行的,即采用了data-dpr的自定義屬性來調整文字。4到6寫一套字體大小,6p寫一套字體大小,然后在對dpr為1的屏幕寫一套字體大小。其實這種寫法還是很惡心,不過基于對dpr的適配,這樣寫也算是個解決方案了。
不過同樣的解決方案到安卓就不行了,安卓的dpr有時候會很亂(比如現在在goole的手機測試里面可以看到,安卓的dpr,lg的某些設備還采用了1.7那樣的奇怪dpr)。而當1.7dpr這種不規范的數字出現的時候,我們就不能采用之前的解決方案了,比如
[data-dpr='1.7'] a{ font-size: 25px }
這樣的東西是不可能去寫的,那萬一還有2.25,2.5之類的呢?我們都要拿去匹配么?
其實現在,因為我們通過devicePixelRatio可以獲取到安卓的dpr值,即可以做到對安卓設備的dpr一個匹配。但是,文字如果采用px的話,確實是很難做到匹配的。
即總結一下,就是說,對于安卓的dpr匹配,目前來說,是沒有什么問題的,但是,對于dpr匹配之后的字體,那肯定是有問題的。
常見的dpr下的字體,我們依然可以解決,但是不常見的dpr,我們確實很難做到對dpr的解決。那如何解決這些問題呢。目前以我本人這個不太靈光的腦袋,確實也不曉得該如何進行一個處理了,起碼做不到很好的解決。
不過,還是丟上些個人的觀點吧。
在之前的對dpr的判斷中,是根據了設備進行判斷,即安卓不對dpr進行改變,僅對ios的設備進行改變。那么,我們其實可不可以以dpr的值來做一個處理呢?即像這樣寫
if (!dpr && !scale) { //devicePixelRatio這個屬性是可以獲取到設備的dpr的 var devicePixelRatio = win.devicePixelRatio; //判斷dpr是否為整數 var isRegularDpr = devicePixelRatio.toString().match(/^[1-9]\d*$/g) if (isRegularDpr) { // 對于是整數的dpr,對dpr進行操作 if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) { dpr = 3; } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){ dpr = 2; } else { dpr = 1; } } else { // 對于其他的dpr,人采用dpr為1的方案 dpr = 1; } scale = 1 / dpr; }
我們對這里做了一點點修改,即來判斷dpr是否是規則的,也就是是否是我們常見的1,2,3等,然后,我們只對規則的dpr,來進行一個字體的處理。這樣,iphone依然還是用之前的匹配方案。而其實目前安卓,很多的設備還是比較常見的dpr了,所以我們這里,將之前對設備的判斷,轉變成對dpr是否是整數的一個判斷。其他地方不變,可以解決對安卓dpr的部分匹配。
同樣,開發的時候,如果并不在乎字體的問題的話,大可以直接使用rem。那樣是可以做到dpr和文字都適配的問題。不過正如我們講到字體的時候所說的,使用rem是很多用戶不希望的(大屏機還是和小屏機看到一樣多的內容),同時,還有點陣的問題。
好,東西寫到這里,也將近到了尾聲。第一次寫這么長的東西,感覺好累啊=_=。嗯還有篇2000字的檢討要寫,默默匿了去寫檢討了。
手機淘寶的flexible設計與實現
iphone6plus很有趣的地方
iphone6plus照理來說的,其實際dpr是2.87左右的,不過,為了方便開發者來開發,iphone6plus對其做了一個調整,將dpr調整為3,然后在對屏幕進行了一個縮放。這樣做,自然是方便了開發者前去開發,然而,這樣做,也有了一些性能上的損失。(iphone為開發者考慮的還是挺周全的,看看隔壁安卓,dpr怎么爽怎么來,都特么自己玩自己的)
有意思的vh和vw
vh,vw目前還存在很大程度的兼容性問題,所以還并沒有采用。
vh,vw有什么特點呢
這兩個元素分別會把屏幕上的可視高度(說通俗點就是你手機屏幕那個框框頭裝起的東西),寬度,分成100份來看,比如先前我們用rem來處理的地方,我們需要在html元素下寫上font-size: 75px,然后再在div下寫上width:1rem。而有了vh,vw之后,我們如此處理html的font-size就好。
html { font-size: 10vw; }
這樣寫,省去了一部js操作的步驟。
看完了這篇文章,相信你對移動端頁面布局應該怎么弄有了一定的了解,想了解更多相關知識,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。