移動端適配方案以及rem和px之間的轉換

背景

• 開發移動端H5頁面

• 面對不一樣分辨率的手機

• 面對不一樣屏幕尺寸的手機

視覺稿

在前端開發以前，視覺MM會給咱們一個psd文件，稱之爲視覺稿。

對於移動端開發而言，爲了作到頁面高清的效果，視覺稿的規範每每會遵循如下兩點：

1）首先，選取一款手機的屏幕寬高做爲基準(之前是iPhone4的320×480，如今更多的是iphone6的375×667)。

2）對於retina屏幕(如: dpr=2)，爲了達到高清效果，視覺稿的畫布大小會是基準的2倍，也就是說像素點個數是原來的4倍（對iphone6而言：原先的375×667，就會變成750×1334）。

問題：

對於dpr=2的手機，爲何畫布大小×2，就能夠解決高清問題？

對於2倍大小的視覺稿，在具體的css編碼中如何還原每個區塊的真實寬高(也就是佈局問題)?

帶着問題，往下看

一些概念

在進行具體的分析以前，首先得知道下面這些關鍵性基本概念(術語)。

物理像素(physical pixel)

一個物理像素是顯示器(手機屏幕)上最小的物理顯示單元，在操做系統的調度下，每個設備像素都有本身的顏色值和亮度值。

設備獨立像素(density-independent pixel)

設備獨立像素(也叫密度無關像素)，能夠認爲是計算機座標系統中得一個點，這個點表明一個能夠由程序使用的虛擬像素(好比: css像素)，而後由相關係統轉換爲物理像素。

因此說，物理像素和設備獨立像素之間存在着必定的對應關係，這就是接下來要說的設備像素比。

設備像素比(device pixel ratio)

設備像素比(簡稱dpr)定義了物理像素和設備獨立像素的對應關係，它的值能夠按以下的公式的獲得：

設備像素比 = 物理像素 / 設備獨立像素 // 在某一方向上，x方向或者y方向

在javascript中，能夠經過window.devicePixelRatio獲取到當前設備的dpr。

在css中，能夠經過-webkit-device-pixel-ratio，-webkit-min-device-pixel-ratio和 -webkit-max-device-pixel-ratio進行媒體查詢，對不一樣dpr的設備，作一些樣式適配(這裏只針對webkit內核的瀏覽器和webview)。

綜合上面幾個概念，一塊兒舉例說明下——以iphone6爲例：

設備寬高爲375×667，能夠理解爲設備獨立像素(或css像素)。

dpr爲2，根據上面的計算公式，其物理像素就應該×2，爲750×1334。

用一張圖來表現，就是這樣(原諒個人盜圖)：

上圖中能夠看出，對於這樣的css樣式：

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

在不一樣的屏幕上(普通屏幕 vs retina屏幕)，css像素所呈現的大小(物理尺寸)是一致的，不一樣的是1個css像素所對應的物理像素個數是不一致的。

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

位圖像素

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

談到這裏，就得說一下，retina下圖片的展現狀況？

理論上，1個位圖像素對應於1個物理像素，圖片才能獲得完美清晰的展現。

在普通屏幕下是沒有問題的，可是在retina屏幕下就會出現位圖像素點不夠，從而致使圖片模糊的狀況。

用一張圖來表示：

如上圖：對於dpr=2的retina屏幕而言，1個位圖像素對應於4個物理像素，因爲單個位圖像素不能夠再進一步分割，因此只能就近取色，從而致使圖片模糊(注意上述的幾個顏色值)。

因此，對於圖片高清問題，比較好的方案就是兩倍圖片(@2x)。

如：200×300(css pixel)img標籤，就須要提供400×600的圖片。

如此一來，位圖像素點個數就是原來的4倍，在retina屏幕下，位圖像素點個數就能夠跟物理像素點個數造成 1 : 1的比例，圖片天然就清晰了(這也解釋了以前留下的一個問題，爲啥視覺稿的畫布大小要×2？)。

這裏就還有另外一個問題，若是普通屏幕下，也用了兩倍圖片，會怎樣呢？

很明顯，在普通屏幕下，200×300(css pixel)img標籤，所對應的物理像素個數就是200×300個，而兩倍圖片的位圖像素個數則是200×300*4，因此就出現一個物理像素點對應4個位圖像素點，因此它的取色也只能經過必定的算法(顯示結果就是一張只有原圖像素總數四分之一，咱們稱這個過程叫作downsampling)，肉眼看上去雖然圖片不會模糊，可是會以爲圖片缺乏一些銳利度，或者是有點色差(但仍是能夠接受的)。

用一張圖片來表示：

針對上面的兩個問題，我作了一個demo。

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

條形圖，經過放大鏡其實能夠看出邊界像素點取值的不一樣：

• 圖1，就近取色，色值介於紅白之間，偏淡，圖片看上去會模糊(能夠理解爲圖片拉伸)。

• 圖2，沒有就近取色，色值要麼是紅，要麼是白，圖片看上去很清晰。

• 圖3，就近取色，色值介於紅白之間，偏重，圖片看上去有色差，缺乏銳利度(能夠理解爲圖片擠壓)。

愛字圖，能夠經過看文字」愛」來區分圖片模糊仍是清晰（若是看上去不明顯，請下載原圖）。

 

幾個問題

這裏說一下，移動端H5開發，在不一樣分辨率，不一樣屏幕手機下會遇到的幾個經典問題。

retina下，圖片高清問題

這個問題上面已經介紹過解決方案了：兩倍圖片(@2x)，而後圖片容器縮小50%。

如：圖片大小，400×600;

1.img標籤

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

2.背景圖片

1 2 3 4

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

這樣的缺點，很明顯，普通屏幕下：

1）一樣下載了@2x的圖片，形成資源浪費。

2）圖片因爲downsampling，會失去了一些銳利度（或是色差）。

因此最好的解決辦法是：不一樣的dpr下，加載不一樣的尺寸的圖片。

不論是經過css媒體查詢，仍是經過javascript條件判斷都是能夠的。

那麼問題來了，這樣的話，不就是要準備兩套圖片了嘛？(@1x 和@2x)

我想，作的好的公司，都會有這麼一個圖片服務器，經過url獲取參數，而後能夠控制圖片質量，也能夠將圖片裁剪成不一樣的尺寸。

因此咱們只需上傳大圖(@2x)，其他小圖都交給圖片服務器處理，咱們只要負責拼接url便可。

如，這樣一張原圖（點擊預覽），能夠相似這樣，進行圖片裁剪：

// 200×200

// 100×100

(ps: 固然裁剪只是對原圖的等比裁剪，得保證圖片的清晰嘛~)

retina下，border: 1px問題

這大概是設計師最敏感，最關心的問題了。

首先得說一下，爲何存在retina下，border: 1px這一說？

咱們正常的寫css，像這樣border: 1px;，在retina屏幕下，會有什麼問題嗎？

先來，來看看下面的圖：

上面兩張圖分別是在iPhone3gs(dpr=1)和iPhone5(dpr=2)下面的測試效果，對比來看，對於1px的border的展現，它們是一致的，並沒有區別。

那麼retina顯示屏的優點在哪裏，設計師爲什麼以爲高清屏下(右圖)這個線條粗呢？明明和左右同樣的~

仍是經過一張圖來解釋(原諒我再次盜圖)：

上圖中，對於一條1px寬的直線，它們在屏幕上的物理尺寸(灰色區域)的確是相同的，不一樣的實際上是屏幕上最小的物理顯示單元，即物理像素，因此對於一條直線，iphone5它能顯示的最小寬度實際上是圖中的紅線圈出來的灰色區域，用css來表示，理論上說是0.5px。

因此，設計師想要的retina下border: 1px;，其實就是1物理像素寬，對於css而言，能夠認爲是border: 0.5px;，這是retina下(dpr=2)下能顯示的最小單位。

然而，無奈並非全部手機瀏覽器都能識別border: 0.5px;，ios7如下，android等其餘系統裏，0.5px會被當成爲0px處理，那麼如何實現這0.5px呢？

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

1 2 3 4 5 6 7 8 9 10 11 12 13

.scale{      position: relative; } .scale:after{      content: "" ;      position: absolute;      bottom:0px;      left:0px;      right:0px;      border-bottom:1px solid  #ddd;      -webkit-transform:scaleY(.5);      -webkit-transform-origin:0 0; }

咱們照常寫border-bottom: 1px solid #ddd;，而後經過transform: scaleY(.5)縮小0.5倍來達到0.5px的效果，可是這樣hack實在是不夠通用(如：圓角等)，寫起來也麻煩。

固然還有其餘好多hack方法，網上均可以搜索到，可是各有利弊，這裏比較推薦的仍是頁面scale的方案，是比較通用的，幾乎知足全部場景。

對於iphone5(dpr=2)，添加以下的meta標籤，設置viewport(scale 0.5)：

這樣，頁面中的全部的border: 1px都將縮小0.5，從而達到border: 0.5px;的效果。

看一下實現後的效果圖對比(右圖爲優化過的)：

然而，頁面scale，必然會帶來一些問題：

1）字體大小會被縮放

2）頁面佈局會被縮放(如: div的寬高等)

這兩個問題後面講到…

多屏適配佈局問題

移動端佈局，爲了適配各類大屏手機，目前最好用的方案莫過於使用相對單位rem。

基於rem的原理，咱們要作的就是: 針對不一樣手機屏幕尺寸和dpr動態的改變根節點html的font-size大小(基準值)。

這裏咱們提取了一個公式(rem表示基準值)

rem = document.documentElement.clientWidth * dpr / 10

說明：

1）乘以dpr，是由於頁面有可能爲了實現1px border頁面會縮放(scale) 1/dpr 倍(若是沒有，dpr=1)。

2）除以10，是爲了取整，方便計算(理論上能夠是任何值)

因此就像下面這樣，html的font-size可能會：

iPhone3gs: 320px / 10 = 32px

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

iPhone6: 375px * 2 / 10 = 75px

對於動態改變根節點html的font-size，咱們能夠經過css作，也能夠經過javascript作。

css方式，能夠經過設備寬度來媒體查詢來改變html的font-size：

缺點：經過設備寬度範圍區間這樣的媒體查詢來動態改變rem基準值，其實不夠精確，好比：寬度爲360px 和 寬度爲320px的手機，由於屏寬在同一範圍區間內(<375px)，因此會被同等對待(rem基準值相同)，而事實上他們的屏幕寬度並不相等，它們的佈局也應該有所不一樣。最終，結論就是：這樣的作法，沒有作到足夠的精確，可是夠用。

javascript方式，經過上面的公式，計算出基準值rem，而後寫入樣式，大概以下(代碼參考自kimi的m-base模塊)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

var  dpr, rem, scale; var  docEl = document.documentElement; var  fontEl = document.createElement( 'style' ); var  metaEl = document.querySelector( 'meta[name="viewport"]' ); scale = 1 / dpr; dpr = win.devicePixelRatio || 1; rem = docEl.clientWidth * dpr / 10; // 設置viewport，進行縮放，達到高清效果 metaEl.setAttribute( 'content' ,  'width='  + dpr * docEl.clientWidth + ',                       initial-scale= ' + scale + ' ,maximum-scale= ' + scale + ' ,                       minimum-scale= ' + scale + ' ,user-scalable=no'); // 設置data-dpr屬性，留做的css hack之用 docEl.setAttribute( 'data-dpr' , dpr); // 動態寫入樣式 docEl.firstElementChild.appendChild(fontEl); fontEl.innerHTML =  'html{font-size:'  + rem +  'px!important;}' ; // 給js調用的，某一dpr下rem和px之間的轉換函數 window.rem2px =  function (v) {      v = parseFloat(v);      return  v * rem; }; window.px2rem:  function (v) {      v = parseFloat(v);      return  v / rem; }; window.dpr = dpr; window.rem = rem;

這種方式，能夠精確地算出不一樣屏幕所應有的rem基準值，缺點就是要加載這麼一段js代碼，但我的以爲是這是目前最好的方案了。

由於這個方案同時解決了三個問題：

1）border: 1px問題

2）圖片高清問題

3）屏幕適配佈局問題

說到佈局，天然就得回答一下最初的留下的那個問題：如何在css編碼中還原視覺稿的真實寬高？

前提條件：

1）拿到的是一個針對iPhone6的高清視覺稿 750×1334

2）採用上述的高清方案(js代碼)。

若是有一個區塊，在psd文件中量出：寬高750×300px的div，那麼如何轉換成rem單位呢？

公式以下：

rem = px / 基準值;

對於一個iPhone6的視覺稿，它的基準值就是75(以前有提到)；

因此，在肯定了視覺稿(即肯定了基準值)後，一般咱們會用less寫一個mixin，像這樣：

1 2 3 4

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

因此，對於寬高750×300px的div，咱們用less就這樣寫：

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

轉換成html，就是這樣：

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

最後由於dpr爲2，頁面scale了0.5，因此在手機屏幕上顯示的真實寬高應該是375×150px，就剛恰好。

假若頁面並無scale 0.5，咱們的代碼就得這樣：

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

這樣的寬高，咱們每每是這樣得來的：

1）將750×1334的視覺稿轉成375×667的大小後，再去量這個區塊的大小(感受好傻)。

2）在750×1334量得區塊寬高是750×300px後，再口算除以2(感受好麻煩)。

最後給出一張沒有佈局適配(上圖)和用rem佈局適配(下圖)的對比圖：

(上面的手機分別是：iPhone3gs, iPhone5, iPhone6)

很明顯能夠看出，rem適配的各個區塊的寬高都會隨着手機屏寬而改變，最最明顯的能夠看一下圖片列表那部分，最後一張圖視覺稿要求只出現一點點，rem佈局在任何屏幕下都顯示的很好。

字體大小問題

既然上面的方案會使得頁面縮放(scale)，對於頁面區塊的寬高，咱們能夠依賴高清視覺稿，由於視覺稿原本就×2了，咱們直接量就能夠了，那麼對於字體該如何處理呢？

對於字體縮放問題，設計師本來的要求是這樣的：任何手機屏幕上字體大小都要統一，因此咱們針對不一樣的分辨率(dpr不一樣)，會作以下處理：

1 2 3 4

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

(注意，字體不能夠用rem，偏差太大了，且不能知足任何屏幕下字體大小相同)

爲了方便，咱們也會用less寫一個mixin：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

.px2px(@name, @px){      @{name}: round(@px / 2) * 1px;      [data-dpr= "2" ] & {          @{name}: @px * 1px;      }      // for mx3      [data-dpr= "2.5" ] & {          @{name}: round(@px * 2.5 / 2) * 1px;      }      // for 小米note      [data-dpr= "2.75" ] & {          @{name}: round(@px * 2.75 / 2) * 1px;      }      [data-dpr= "3" ] & {          @{name}: round(@px / 2 * 3) * 1px      }      // for 三星note4      [data-dpr= "4" ] & {          @{name}: @px * 2px;      } }

(注意：html的data-dpr屬性就是以前js方案裏面有提到的，這裏就有用處了)

根據經驗和測試，仍是會出現這些奇奇葩葩的dpr，這裏作了統一兼容~

用的時候，就像這樣：

1	.px2px(font-size, 32);

固然對於其餘css屬性，若是也要求不一樣dpr下都保持一致的話，也能夠這樣操做，如：

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