偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

解惑好文:移動端H5頁面高清多屏適配方案

移動開發(fā)
我們應(yīng)該怎么做,才能在開發(fā)移動端H5頁面時(shí),適配不同分辨率不同屏幕尺寸的手機(jī)。

  背景

  • 開發(fā)移動端H5頁面
  • 面對不同分辨率的手機(jī)
  • 面對不同屏幕尺寸的手機(jī)

視覺稿

在前端開發(fā)之前,視覺MM會給我們一個psd文件,稱之為視覺稿。

對于移動端開發(fā)而言,為了做到頁面高清的效果,視覺稿的規(guī)范往往會遵循以下兩點(diǎn):

  1. 首先,選取一款手機(jī)的屏幕寬高作為基準(zhǔn)(以前是iPhone4的320×480,現(xiàn)在更多的是iphone6的375×667)。
  2. 對于retina屏幕(如: dpr=2),為了達(dá)到高清效果,視覺稿的畫布大小會是基準(zhǔn)的2倍,也就是說像素點(diǎn)個數(shù)是原來的4倍(對iphone6而言:原先的375×667,就會變成750×1334)。

問題:

對于dpr=2的手機(jī),為什么畫布大小×2,就可以解決高清問題?

對于2倍大小的視覺稿,在具體的css編碼中如何還原每一個區(qū)塊的真實(shí)寬高(也就是布局問題)?

帶著問題,往下看…

一些概念

在進(jìn)行具體的分析之前,首先得知道下面這些關(guān)鍵性基本概念(術(shù)語)。

物理像素(physical pixel)

一個物理像素是顯示器(手機(jī)屏幕)上最小的物理顯示單元,在操作系統(tǒng)的調(diào)度下,每一個設(shè)備像素都有自己的顏色值和亮度值。

設(shè)備獨(dú)立像素(density-independent pixel)

設(shè)備獨(dú)立像素(也叫密度無關(guān)像素),可以認(rèn)為是計(jì)算機(jī)坐標(biāo)系統(tǒng)中得一個點(diǎn),這個點(diǎn)代表一個可以由程序使用的虛擬像素(比如: css像素),然后由相關(guān)系統(tǒng)轉(zhuǎn)換為物理像素。

所以說,物理像素和設(shè)備獨(dú)立像素之間存在著一定的對應(yīng)關(guān)系,這就是接下來要說的設(shè)備像素比。

設(shè)備像素比(device pixel ratio)

設(shè)備像素比(簡稱dpr)定義了物理像素和設(shè)備獨(dú)立像素的對應(yīng)關(guān)系,它的值可以按如下的公式的得到:

     設(shè)備像素比 = 物理像素 / 設(shè)備獨(dú)立像素 // 在某一方向上,x方向或者y方向

在css中,可以通過-webkit-device-pixel-ratio,-webkit-min-device-pixel-ratio和 -webkit-max-device-pixel-ratio進(jìn)行媒體查詢,對不同dpr的設(shè)備,做一些樣式適配(這里只針對webkit內(nèi)核的瀏覽器和webview)。在javascript中,可以通過window.devicePixelRatio獲取到當(dāng)前設(shè)備的dpr。

綜合上面幾個概念,一起舉例說明下——以iphone6為例:

設(shè)備寬高為375×667,可以理解為設(shè)備獨(dú)立像素(或css像素)。

dpr為2,根據(jù)上面的計(jì)算公式,其物理像素就應(yīng)該×2,為750×1334。

用一張圖來表現(xiàn),就是這樣(原諒我的盜圖):

TB1uWfJIpXXXXaoXXXXXXXXXXXX.jpg

上圖中可以看出,對于這樣的css樣式:

  1. width: 2px; 
  2. height: 2px; 

在不同的屏幕上(普通屏幕 vs retina屏幕),css像素所呈現(xiàn)的大小(物理尺寸)是一致的,不同的是1個css像素所對應(yīng)的物理像素個數(shù)是不一致的。

在普通屏幕下,1個css像素 對應(yīng) 1個物理像素(1:1)。 在retina 屏幕下,1個css像素對應(yīng) 4個物理像素(1:4)。

位圖像素

一個位圖像素是柵格圖像(如:png, jpg, gif等)最小的數(shù)據(jù)單元。每一個位圖像素都包含著一些自身的顯示信息(如:顯示位置,顏色值,透明度等)。

談到這里,就得說一下,retina下圖片的展示情況?

理論上,1個位圖像素對應(yīng)于1個物理像素,圖片才能得到完美清晰的展示。

在普通屏幕下是沒有問題的,但是在retina屏幕下就會出現(xiàn)位圖像素點(diǎn)不夠,從而導(dǎo)致圖片模糊的情況。

用一張圖來表示:

TB12ALnIpXXXXb1XVXXXXXXXXXX.jpg

如上圖:對于dpr=2的retina屏幕而言,1個位圖像素對應(yīng)于4個物理像素,由于單個位圖像素不可以再進(jìn)一步分割,所以只能就近取色,從而導(dǎo)致圖片模糊(注意上述的幾個顏色值)。

所以,對于圖片高清問題,比較好的方案就是兩倍圖片(@2x)。

如:200×300(css pixel)img標(biāo)簽,就需要提供400×600的圖片。

如此一來,位圖像素點(diǎn)個數(shù)就是原來的4倍,在retina屏幕下,位圖像素點(diǎn)個數(shù)就可以跟物理像素點(diǎn)個數(shù)形成 1 : 1的比例,圖片自然就清晰了(這也解釋了之前留下的一個問題,為啥視覺稿的畫布大小要×2?)。

這里就還有另一個問題,如果普通屏幕下,也用了兩倍圖片,會怎樣呢?

很明顯,在普通屏幕下,200×300(css pixel)img標(biāo)簽,所對應(yīng)的物理像素個數(shù)就是200×300個,而兩倍圖片的位圖像素個數(shù)則是200×300*4,所以就出現(xiàn)一個物理像素點(diǎn)對應(yīng)4個位圖像素點(diǎn),所以它的取色也只能通過一定的算法(顯示結(jié)果就是一張只有原圖像素總數(shù)四分之一,我們稱這個過程叫做downsampling),肉眼看上去雖然圖片不會模糊,但是會覺得圖片缺少一些銳利度,或者是有點(diǎn)色差(但還是可以接受的)。

用一張圖片來表示:

TB1kFHnIpXXXXclXVXXXXXXXXXX.jpg

針對上面的兩個問題,我做了一個demo。

TB11KbzIpXXXXXcXFXXXXXXXXXX.jpg

demo中,100×100的圖片,分別放在100×100,50×50,25×25的img容器中,在retina屏幕下的顯示效果。

條形圖,通過放大鏡其實(shí)可以看出邊界像素點(diǎn)取值的不同:

  • 圖1,就近取色,色值介于紅白之間,偏淡,圖片看上去會模糊(可以理解為圖片拉伸)。
  • 圖2,沒有就近取色,色值要么是紅,要么是白,圖片看上去很清晰。
  • 圖3,就近取色,色值介于紅白之間,偏重,圖片看上去有色差,缺少銳利度(可以理解為圖片擠壓)。

愛字圖,可以通過看文字”愛”來區(qū)分圖片模糊還是清晰(如果看上去不明顯,請下載原圖)。

#p#

幾個問題

這里說一下,移動端H5開發(fā),在不同分辨率,不同屏幕手機(jī)下會遇到的幾個經(jīng)典問題。

retina下,圖片高清問題

這個問題上面已經(jīng)介紹過解決方案了:兩倍圖片(@2x),然后圖片容器縮小50%。

如:圖片大小,400×600;

1.img標(biāo)簽

  1. width: 200px; 
  2. height: 300px; 

2.背景圖片

  1. width: 200px; 
  2. height: 300px; 
  3. background-image: url(image@2x.jpg); 
  4. background-size: 200px 300px; // 或者: background-size: contain; 

這樣的缺點(diǎn),很明顯,普通屏幕下:

  1. 同樣下載了@2x的圖片,造成資源浪費(fèi)。
  2. 圖片由于downsampling,會失去了一些銳利度(或是色差)。

所以最好的解決辦法是:不同的dpr下,加載不同的尺寸的圖片。

不管是通過css媒體查詢,還是通過javascript條件判斷都是可以的。

那么問題來了,這樣的話,不就是要準(zhǔn)備兩套圖片了嘛?(@1x 和@2x)

我想,做的好的公司,都會有這么一個圖片服務(wù)器,通過url獲取參數(shù),然后可以控制圖片質(zhì)量,也可以將圖片裁剪成不同的尺寸。

所以我們只需上傳大圖(@2x),其余小圖都交給圖片服務(wù)器處理,我們只要負(fù)責(zé)拼接url即可。

如,這樣一張?jiān)瓐D,可以類似這樣,進(jìn)行圖片裁剪:

// 200×200

[[140456]]

// 100×100

[[140457]]

(ps: 當(dāng)然裁剪只是對原圖的等比裁剪,得保證圖片的清晰嘛~)

retina下,border: 1px問題

這大概是設(shè)計(jì)師最敏感,最關(guān)心的問題了。

首先得說一下,為什么存在retina下,border: 1px這一說?

我們正常的寫css,像這樣border: 1px;,在retina屏幕下,會有什么問題嗎?

先來,來看看下面的圖:

TB15IQgIpXXXXa3XFXXXXXXXXXX.jpg

上面兩張圖分別是在iPhone3gs(dpr=1)和iPhone5(dpr=2)下面的測試效果,對比來看,對于1px的border的展示,它們是一致的,并無區(qū)別。

那么retina顯示屏的優(yōu)勢在哪里,設(shè)計(jì)師為何覺得高清屏下(右圖)這個線條粗呢?明明和左右一樣的~

還是通過一張圖來解釋(原諒我再次盜圖):

TB1OPkfIpXXXXXWaXXXXXXXXXXX.jpg_q90.jpg

上圖中,對于一條1px寬的直線,它們在屏幕上的物理尺寸(灰色區(qū)域)的確是相同的,不同的其實(shí)是屏幕上最小的物理顯示單元,即物理像素,所以對于一條直線,iphone5它能顯示的最小寬度其實(shí)是圖中的紅線圈出來的灰色區(qū)域,用css來表示,理論上說是0.5px。

所以,設(shè)計(jì)師想要的retina下border: 1px;,其實(shí)就是1物理像素寬,對于css而言,可以認(rèn)為是border: 0.5px;,這是retina下(dpr=2)下能顯示的最小單位。

然而,無奈并不是所有手機(jī)瀏覽器都能識別border: 0.5px;,ios7以下,android等其他系統(tǒng)里,0.5px會被當(dāng)成為0px處理,那么如何實(shí)現(xiàn)這0.5px呢?

最簡單的一個做法就是這樣(元素scale):

 
  1. .scale{ 
  2.     position: relative; 
  3. .scale:after{ 
  4.     content:""
  5.     position: absolute; 
  6.     bottom:0px; 
  7.     left:0px; 
  8.     right:0px; 
  9.     border-bottom:1px solid #ddd; 
  10.     -webkit-transform:scaleY(.5); 
  11.     -webkit-transform-origin:0 0

我們照常寫border-bottom: 1px solid #ddd;,然后通過transform: scaleY(.5)縮小0.5倍來達(dá)到0.5px的效果,但是這樣hack實(shí)在是不夠通用(如:圓角等),寫起來也麻煩。

當(dāng)然還有其他好多hack方法,網(wǎng)上都可以搜索到,但是各有利弊,這里比較推薦的還是頁面scale的方案,是比較通用的,幾乎滿足所有場景。

對于iphone5(dpr=2),添加如下的meta標(biāo)簽,設(shè)置viewport(scale 0.5):

1436862713886600.png

這樣,頁面中的所有的border: 1px都將縮小0.5,從而達(dá)到border: 0.5px;的效果。

看一下實(shí)現(xiàn)后的效果圖對比(右圖為優(yōu)化過的):

TB1HPQwIpXXXXXgXXXXXXXXXXXX.jpg

然而,頁面scale,必然會帶來一些問題:

  1. 字體大小會被縮放
  2. 頁面布局會被縮放(如: div的寬高等)

這兩個問題后面講到…

#p#

多屏適配布局問題

移動端布局,為了適配各種大屏手機(jī),目前最好用的方案莫過于使用相對單位rem。

基于rem的原理,我們要做的就是: 針對不同手機(jī)屏幕尺寸和dpr動態(tài)的改變根節(jié)點(diǎn)html的font-size大小(基準(zhǔn)值)。

這里我們提取了一個公式(rem表示基準(zhǔn)值)

rem = document.documentElement.clientWidth * dpr / 10

乘以dpr,是因?yàn)轫撁嬗锌赡転榱藢?shí)現(xiàn)1px border頁面會縮放(scale) 1/dpr 倍(如果沒有,dpr=1)。說明:

  1. 除以10,是為了取整,方便計(jì)算(理論上可以是任何值)

所以就像下面這樣,html的font-size可能會:

iPhone3gs: 320px / 10 = 32px

iPhone4/5: 320px * 2 / 10 = 64px

iPhone6: 375px * 2 / 10 = 75px

對于動態(tài)改變根節(jié)點(diǎn)html的font-size,我們可以通過css做,也可以通過javascript做。

css方式,可以通過設(shè)備寬度來媒體查詢來改變html的font-size:

QQ截圖20150714163632.png

缺點(diǎn):通過設(shè)備寬度范圍區(qū)間這樣的媒體查詢來動態(tài)改變r(jià)em基準(zhǔn)值,其實(shí)不夠精確,比如:寬度為360px 和 寬度為320px的手機(jī),因?yàn)槠翆捲谕环秶鷧^(qū)間內(nèi)(<375px),所以會被同等對待(rem基準(zhǔn)值相同),而事實(shí)上他們的屏幕寬度并不相等,它們的布局也應(yīng)該有所不同。最終,結(jié)論就是:這樣的做法,沒有做到足夠的精確,但是夠用。

javascript方式,通過上面的公式,計(jì)算出基準(zhǔn)值rem,然后寫入樣式,大概如下(代碼參考自kimi的m-base模塊)

  1. var dpr, rem, scale; 
  2. var docEl = document.documentElement; 
  3. var fontEl = document.createElement('style'); 
  4. var metaEl = document.querySelector('meta[name="viewport"]'); 
  5. scale = 1 / dpr; 
  6. dpr = win.devicePixelRatio || 1
  7. rem = docEl.clientWidth * dpr / 10
  8. // 設(shè)置viewport,進(jìn)行縮放,達(dá)到高清效果 
  9. metaEl.setAttribute('content''width=' + dpr * docEl.clientWidth + ', 
  10.                      initial-scale=' + scale + ',maximum-scale=' + scale + '
  11.                      minimum-scale=' + scale + ',user-scalable=no'); 
  12. // 設(shè)置data-dpr屬性,留作的css hack之用 
  13. docEl.setAttribute('data-dpr', dpr); 
  14. // 動態(tài)寫入樣式 
  15. docEl.firstElementChild.appendChild(fontEl); 
  16. fontEl.innerHTML = 'html{font-size:' + rem + 'px!important;}'
  17. // 給js調(diào)用的,某一dpr下rem和px之間的轉(zhuǎn)換函數(shù) 
  18. window.rem2px = function(v) { 
  19.     v = parseFloat(v); 
  20.     return v * rem; 
  21. }; 
  22. window.px2rem: function(v) { 
  23.     v = parseFloat(v); 
  24.     return v / rem; 
  25. }; 
  26. window.dpr = dpr; 
  27. window.rem = rem; 

這種方式,可以精確地算出不同屏幕所應(yīng)有的rem基準(zhǔn)值,缺點(diǎn)就是要加載這么一段js代碼,但個人覺得是這是目前最好的方案了。

因?yàn)檫@個方案同時(shí)解決了三個問題:

  1. border: 1px問題
  2. 圖片高清問題
  3. 屏幕適配布局問題

說到布局,自然就得回答一下最初的留下的那個問題:如何在css編碼中還原視覺稿的真實(shí)寬高?

前提條件:

  1. 拿到的是一個針對iPhone6的高清視覺稿 750×1334
  2. 采用上述的高清方案(js代碼)。

如果有一個區(qū)塊,在psd文件中量出:寬高750×300px的div,那么如何轉(zhuǎn)換成rem單位呢?

公式如下:

rem = px / 基準(zhǔn)值;

對于一個iPhone6的視覺稿,它的基準(zhǔn)值就是75(之前有提到);

所以,在確定了視覺稿(即確定了基準(zhǔn)值)后,通常我們會用less寫一個mixin,像這樣:

  1. // 例如: .px2rem(height, 80); 
  2. .px2rem(@name@px){ 
  3.     @{name}: @px / 75 * 1rem; 

所以,對于寬高750×300px的div,我們用less就這樣寫:

  1. .px2rem(width, 750); 
  2. .px2rem(height, 300); 

轉(zhuǎn)換成html,就是這樣:

  1. width: 10rem; // -> 750px 
  2. height: 4rem; // -> 300px 

最后因?yàn)閐pr為2,頁面scale了0.5,所以在手機(jī)屏幕上顯示的真實(shí)寬高應(yīng)該是375×150px,就剛剛好。

倘若頁面并沒有scale 0.5,我們的代碼就得這樣:

  1. .px2rem(width, 375); 
  2. .px2rem(height, 150); 

這樣的寬高,我們往往是這樣得來的:

  1. 將750×1334的視覺稿轉(zhuǎn)成375×667的大小后,再去量這個區(qū)塊的大小(感覺好傻)。
  2. 在750×1334量得區(qū)塊寬高是750×300px后,再口算除以2(感覺好麻煩)。

最后給出一張沒有布局適配(上圖)和用rem布局適配(下圖)的對比圖:

TB1hR.png

(上面的手機(jī)分別是:iPhone3gs, iPhone5, iPhone6)

很明顯可以看出,rem適配的各個區(qū)塊的寬高都會隨著手機(jī)屏寬而改變,最最明顯的可以看一下圖片列表那部分,最后一張圖視覺稿要求只出現(xiàn)一點(diǎn)點(diǎn),rem布局在任何屏幕下都顯示的很好。

字體大小問題

既然上面的方案會使得頁面縮放(scale),對于頁面區(qū)塊的寬高,我們可以依賴高清視覺稿,因?yàn)橐曈X稿本來就×2了,我們直接量就可以了,那么對于字體該如何處理呢?

對于字體縮放問題,設(shè)計(jì)師原本的要求是這樣的:任何手機(jī)屏幕上字體大小都要統(tǒng)一,所以我們針對不同的分辨率(dpr不同),會做如下處理:

 
  1. font-size: 16px; 
  2. [data-dpr="2"] input { 
  3.   font-size: 32px; 

(注意,字體不可以用rem,誤差太大了,且不能滿足任何屏幕下字體大小相同)

為了方便,我們也會用less寫一個mixin:

  1. .px2px(@name@px){ 
  2.     @{name}: round(@px / 2) * 1px; 
  3.     [data-dpr="2"] & { 
  4.         @{name}: @px * 1px; 
  5.     } 
  6.     // for mx3 
  7.     [data-dpr="2.5"] & { 
  8.         @{name}: round(@px * 2.5 / 2) * 1px; 
  9.     } 
  10.     // for 小米note 
  11.     [data-dpr="2.75"] & { 
  12.         @{name}: round(@px * 2.75 / 2) * 1px; 
  13.     } 
  14.     [data-dpr="3"] & { 
  15.         @{name}: round(@px / 2 * 3) * 1px 
  16.     } 
  17.     // for 三星note4 
  18.     [data-dpr="4"] & { 
  19.         @{name}: @px * 2px; 
  20.     } 

(注意:html的data-dpr屬性就是之前js方案里面有提到的,這里就有用處了)

根據(jù)經(jīng)驗(yàn)和測試,還是會出現(xiàn)這些奇奇葩葩的dpr,這里做了統(tǒng)一兼容~

用的時(shí)候,就像這樣:

 

  1. .px2px(font-size, 32); 

當(dāng)然對于其他css屬性,如果也要求不同dpr下都保持一致的話,也可以這樣操作,如:

  1. .px2px(padding, 20); 
  2. .px2px(right, 8); 

最后

上面對移動端H5高清和多屏適配的一些方案總結(jié),和知識講解,不對的地方,還請指出來。

責(zé)任編輯:倪明 來源: 前端亂燉
相關(guān)推薦

2015-07-15 14:38:54

H5移動適配

2022-05-12 10:36:10

移動方案

2021-06-08 05:53:31

H5 頁面項(xiàng)目劉海屏適配

2024-04-16 13:56:09

移動端安全區(qū)域iOS

2017-08-16 10:57:25

H5HTML開發(fā)

2022-10-26 09:01:55

H5移動端調(diào)試

2020-12-13 12:14:45

H5開發(fā)H5-Dooring

2022-04-28 15:38:42

WebViewJavaUI

2017-05-10 07:33:41

AndroidWebView視頻

2021-06-23 06:30:14

H5 移動端前端開發(fā)

2022-04-15 11:05:28

移動端自適應(yīng)高清

2025-03-28 08:55:00

H5頁面APPiOS

2020-06-04 16:57:07

移動開發(fā)互聯(lián)網(wǎng)實(shí)踐

2017-11-13 16:35:36

iPhone X全面屏APP

2023-08-15 08:34:28

頁面制作工具GitHub

2018-02-06 16:21:13

H5首屏探討

2015-12-16 12:40:32

H5緩存機(jī)制移動

2020-03-24 09:34:00

移動端H5軟鍵盤

2019-07-18 10:32:32

focusouIOS前端

2015-12-03 15:27:46

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號