移動端高清、多屏適配方案

來源:互聯網
上載者:User

標籤:border   win   dea   cti   相容   依賴   iphone6   rds   select   

背景
  1. 開發移動端H5頁面
  2. 面對不同解析度的手機
  3. 面對不同螢幕尺寸的手機
視覺稿

在前端開發之前,視覺MM會給我們一個psd檔案,稱之為視覺稿

對於移動端開發而言,為了做到頁面高清的效果,視覺稿的規範往往會遵循以下兩點:

  1. 首先,選取一款手機的螢幕寬高作為基準(以前是iphone4的320×480,現在更多的是iphone6的375×667)。
  2. 對於retina螢幕(如: dpr=2),為了達到高清效果,視覺稿的畫布大小會是基準2倍,也就是說像素點個數是原來的4倍(對iphone6而言:原先的375×667,就會變成750×1334)。

問題:

  1. 對於dpr=2的手機,為什麼畫布大小×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為例:

  1. 裝置寬高為375×667,可以理解為裝置獨立像素(或css像素)。
  2. dpr為2,根據上面的計算公式,其物理像素就應該×2,為750×1334

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

中可以看出,對於這樣的css樣式:

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,就近取色,色值介於紅白之間,偏重,圖片看上去有色差,缺少銳利度(可以理解為圖片擠壓)。

愛字圖,可以通過看文字"愛"來區分圖片模糊還是清晰。

(ps:如果看上去不明顯,可以用手機掃碼網頁(內網地址)或者點擊原圖看會更直觀點。

幾個問題

這裡說一下,移動端H5開發,在不同解析度,不同螢幕手機下會遇到的幾個經典問題。

retina下,圖片高清問題

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

如:圖片大小,400×600;

1.img標籤

width: 200px;height: 300px;

2.背景圖片

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

這樣的缺點,很明顯,普通螢幕下:

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

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

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

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

我想,做的好的公司,都會有這麼一個圖片伺服器,通過url擷取參數,然後可以控製圖片品質,也可以將圖片裁剪成不同的尺寸。

所以我們只需上傳大圖(2x),其餘小圖都交給圖片伺服器處理,我們只要負責拼接url即可。

如,這樣一張原圖:

https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg // 原圖

可以類似這樣,進行圖片裁剪:

// 200×200https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg_200x200.jpg// 100×100https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg_100x100.jpg

(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):

.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):

<meta name="viewport" content="width=640,initial-scale=0.5,maximum-scale=0.5, minimum-scale=0.5,user-scalable=no">

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

有人擔心頁面scale後會影響效能,@妙淨同學做過效能測試,見這裡(內網地址)。

看一下實現後的對比(右圖為最佳化過的):

(ps: 圖片被壓縮過,可能看上去並不明顯,可以用手機掃碼或者點擊這裡(內網地址)對比看看)

然而,頁面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:

html{font-size: 32px;}// iphone 6 @media (min-device-width : 375px) {   html{font-size: 64px;}}// iphone6 plus @media (min-device-width : 414px) {    html{font-size: 75px;}}

缺點:通過裝置寬度範圍區間這樣的媒體查詢來動態改變rem基準值,其實不夠精確,比如:寬度為360px 和 寬度為320px的手機,因為屏寬在同一範圍區間內(<375px),所以會被同等對待(rem基準值相同),而事實上他們的螢幕寬度並不相等,它們的布局也應該有所不同。最終,結論就是:這樣的做法,沒有做到足夠的精確,但是夠用。

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

var dpr, rem, scale;var docEl = document.documentElement;var fontEl = document.createElement(‘style‘);var metaEl = document.querySelector(‘meta[name="viewport"]‘);dpr = window.devicePixelRatio || 1;rem = docEl.clientWidth * dpr / 10;scale = 1 / dpr;// 設定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,像這樣:

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

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

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

轉換成html,就是這樣:

width: 10rem; // -> 750pxheight: 4rem; // -> 300px

最後因為dpr為2,頁面scale了0.5,所以在手機螢幕上顯示的真實寬高應該是375×150px,就剛剛好。

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

.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不同),會做如下處理:

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

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

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

.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,這裡做了統一相容~

用的時候,就像這樣:

.px2px(font-size, 32);

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

.px2px(padding, 20);.px2px(right, 8);
最後

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

參考文章
  1. http://www.smashingmagazine.com/2012/08/20/towards-retina-web/
  2. http://www.paintcodeapp.com/news/iphone-6-screens-demystified
  3. http://www.inserthtml.com/2012/09/designing-retina-devices/
  4. http://iconmoon.com/blog2/iphone-6-plus-screen-size/
  5. http://dieulot.net/css-retina-hairline

移動端高清、多屏適配方案

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.