摘要：設(shè)備像素比縮寫簡(jiǎn)稱，也就是我們經(jīng)常在谷歌控制臺(tái)移動(dòng)端調(diào)試頂端會(huì)看到的一個(gè)值。在移動(dòng)端，默認(rèn)的情況下，布局視口的寬度是要遠(yuǎn)遠(yuǎn)大于瀏覽器的寬度的。手淘團(tuán)隊(duì)布局現(xiàn)今，適配手機(jī)端

做過(guò)移動(dòng)端適配的小伙伴一定有遇到過(guò)這行代碼：

但是，很多小伙伴只是感性的認(rèn)識(shí)：噢，我加了這行代碼，然后頁(yè)面的寬度就會(huì)跟我的設(shè)備寬度一致。然而，這種理解是很片面的。那么，這句話的本質(zhì)到底是什么呢？

不急，我們先往下面看，這里先留個(gè)懸念。

這里，我們先來(lái)辨析一下在適配的時(shí)候經(jīng)常會(huì)遇到的一些名詞、數(shù)值單位。

首先，先來(lái)看一下物理像素。

以iphone6為例，可知道：

分辨率：1334pt x 750pt
指的是屏幕上垂直有1334個(gè)物理像素，水平有750個(gè)物理像素。

屏幕尺寸：4.7in
注意英寸是長(zhǎng)度單位，不是面積單位。4.7英寸指的是屏幕對(duì)角線的長(zhǎng)度，1英寸等于2.54cm。

屏幕像素密度：326ppi
指的是每英寸屏幕所擁有的像素?cái)?shù)，在顯示器中，dpi=ppi。dpi強(qiáng)調(diào)的是每英寸多少點(diǎn)。同時(shí)，屏幕像素密度=分辨率/屏幕尺寸

接著，我們來(lái)看一下其他的單位。

設(shè)備獨(dú)立像素：設(shè)備獨(dú)立像素，不同于設(shè)備像素（物理像素），它是虛擬化的。比如說(shuō)css像素，我們常說(shuō)的10px其實(shí)指的就是它。需要注意的是，物理像素開發(fā)者是無(wú)法獲取的，它是自然存在的一種東西，該是多少就是多少。

設(shè)備像素比：縮寫簡(jiǎn)稱dpr，也就是我們經(jīng)常在谷歌控制臺(tái)移動(dòng)端調(diào)試頂端會(huì)看到的一個(gè)值。設(shè)備像素比 = 設(shè)備像素 / css像素（垂直方向或水平方向）。可以通過(guò)JS來(lái)獲取：window.devicePixelRatio

注：以下涉及的像素均為CSS像素。并且默認(rèn)不考慮縮放。

布局視口

寫過(guò)css的小伙伴應(yīng)該知道，我們?cè)?b>html、body設(shè)置width:100%;height:100%;的時(shí)候，它并不是無(wú)效的。我們都知道100%這種百分?jǐn)?shù)應(yīng)該是繼承父元素而來(lái)的。那在這里是繼承哪里的呢？

在PC瀏覽器中，有一個(gè)用來(lái)約束CSS布局視口的東西，又叫做初始包含塊。這也就是所有寬高繼承的由來(lái)。除去margin、padding，布局視口和瀏覽器可視窗口寬度是一致的，同時(shí)也和瀏覽器本身的寬度一致。

但是在移動(dòng)端，就大不一樣了。

以下的例子是在不加meta標(biāo)簽的前提下進(jìn)行演示的。

假如我們現(xiàn)在做一個(gè)二八分的左右布局，那么如果在PC端上面的話，顯示的效果非常完美，這沒(méi)什么好說(shuō)的。

那如果是在手機(jī)端呢，這里以iphone6為例子來(lái)講解：

圖例如下：

代碼如下：

* {
    margin: 0;
    padding: 0;
}

html,
body {
    height: 100%;
    width: 100%;
}

.left {
    float: left;
    width: 20%;
    height: 100%;
    background: red;
}

.right {
    float: right;
    width: 80%;
    height: 100%;
    background: green;
}
----

    

    

這里我們會(huì)看到，為什么body的寬度是980px，而瀏覽器的寬度只有375px，那么這個(gè)980px到底是從哪里來(lái)的呢？

其實(shí)，這里的980px就是移動(dòng)端所謂的布局視口了。

在移動(dòng)端，默認(rèn)的情況下，布局視口的寬度是要遠(yuǎn)遠(yuǎn)大于瀏覽器的寬度的。這兩個(gè)視口不同于PC端，是相互獨(dú)立存在的。為什么呢？試想一下，如果一個(gè)網(wǎng)頁(yè)不對(duì)移動(dòng)端進(jìn)行適配，用戶進(jìn)行閱讀的時(shí)候，如果默認(rèn)情況下布局視口的寬度等于瀏覽器寬度，那是不是展示起來(lái)更加的不友好。也就是說(shuō)，如果一個(gè)div的寬度為20%，那么它在布局視口寬度為980px的時(shí)候，展示給用戶的像素還有196px，而如果寬度只有375px的情況下，寬度只有75px，展示的大小相差特別大。

所以，瀏覽器廠商為了讓用戶在小屏幕下網(wǎng)頁(yè)也能夠顯示地很好，所以把布局視口寬度設(shè)置地很大，一般在768px ~ 1024px之間，最常見的寬度是980px。這個(gè)寬度可以通過(guò)document.documentElement.clientWidth得到。

視覺(jué)視口

對(duì)于視覺(jué)視口來(lái)說(shuō)，這個(gè)東西是呈現(xiàn)給用戶的，它是用戶看到網(wǎng)頁(yè)區(qū)域內(nèi)CSS像素的數(shù)量。由于用戶可以自行進(jìn)行縮放控制，所以這個(gè)視口并不是開發(fā)者需要重點(diǎn)關(guān)注的。

值得注意的是，在移動(dòng)端縮放不會(huì)改變布局視口的寬度，當(dāng)縮小的時(shí)候，屏幕覆蓋的css像素變多，視覺(jué)視口變大，反之亦然。

而在PC端，縮放對(duì)應(yīng)布局寬度和視覺(jué)窗口寬度都是聯(lián)動(dòng)的。而瀏覽器寬度本身是固定的，無(wú)論怎么縮放都不受影響。

如果對(duì)上面的寬度還是很亂，那么這里有一個(gè)表格可以幫助你理清思路。

以下表格橫向都以瀏覽器窗口的寬度作為基準(zhǔn)：

對(duì)于PC端來(lái)說(shuō)：

對(duì)于移動(dòng)端來(lái)說(shuō)：

理想視口

以上，布局視口很明顯對(duì)用戶十分的不友好，完全忽略了手機(jī)本來(lái)的尺寸。

所以蘋果引入了理想視口的概念，它是對(duì)設(shè)備來(lái)說(shuō)最理想的布局視口尺寸。理想視口中的網(wǎng)頁(yè)用戶最理想的寬度，用戶進(jìn)入頁(yè)面的時(shí)候不需要縮放。

那么很明顯，所謂的理想寬度就是瀏覽器（屏幕）的寬度了。

所以就有了下面的這段代碼：

然而，這段代碼其實(shí)也并不完美，在IE瀏覽器中，由于橫屏豎屏的切換會(huì)對(duì)其造成影響，為了解決這個(gè)兼容性的問(wèn)題，最后再加上一句，就有了現(xiàn)在的：

width=device-width 這句代碼可以把布局視口設(shè)置成為瀏覽器（屏幕）的寬度。

initial-scale=1 的意思是初始縮放的比例是1，使用它的時(shí)候，同時(shí)也會(huì)將布局視口的尺寸設(shè)置為縮放后的尺寸。而縮放的尺寸就是基于屏幕的寬度來(lái)的，也就起到了和width=device-width同樣的效果。

另外，值得一提的是，我們?cè)谶M(jìn)行媒體查詢的時(shí)候，查詢的寬度值其實(shí)也是布局視口的寬度值。

有時(shí)候我們會(huì)發(fā)現(xiàn)，當(dāng)我們?cè)谶m某一機(jī)型的時(shí)候，顯示上沒(méi)什么問(wèn)題。但是一旦我換到另外一部手機(jī)，發(fā)現(xiàn)出現(xiàn)了模糊的情況，尤其以圖片更為顯著。

其實(shí)這個(gè)問(wèn)題，就是涉及到了上面講到的一個(gè)屬性：設(shè)備像素比，即我們經(jīng)常說(shuō)的dpr。下面先來(lái)看dpr的表現(xiàn)：

假設(shè)現(xiàn)在有一臺(tái)iphone6，那么它的設(shè)備獨(dú)立像素是375x667，dpr為2，尺寸是4.7in，那么物理像素就是750x1334。
同樣的我們也有一臺(tái)不知名的設(shè)備，它的設(shè)備獨(dú)立像素剛好也是375x667，尺寸也是4.7in，但是dpr為1，此時(shí)的物理像素就是375x667。

于是，它們的屏幕表現(xiàn)如下：

在不同的屏幕上，無(wú)論是普通屏幕還是retina屏幕，css像素所呈現(xiàn)的大小是一致的。（如果不理解這句話，可以寫一個(gè)2px的正方形使用谷歌控制臺(tái)移動(dòng)設(shè)備調(diào)試，在不同的設(shè)備之間來(lái)回切換，你會(huì)發(fā)現(xiàn)大小其實(shí)是一樣的。一開始我總以為這個(gè)css像素的實(shí)際寬高因?yàn)槭艿絛pr的影響而在不同設(shè)備上的長(zhǎng)寬是不一致的。）

不同的是，1個(gè)css像素對(duì)應(yīng)（覆蓋）的物理像素個(gè)數(shù)。

所以，如果我們想要在這兩個(gè)屏幕顯示這么一個(gè)css樣式：

width: 2px;
heigth: 2px;

在普通屏幕下，也就是dpr為1的屏幕中，1個(gè)css像素對(duì)應(yīng)（覆蓋）的是一個(gè)物理像素。在retina屏幕下，1個(gè)css像素對(duì)應(yīng)（覆蓋）的是4個(gè)物理像素。換句話說(shuō)，就是dpr為2的設(shè)備。看下面這張圖：

淺顯的理解就是可以看作是2cmx2cm的正方形被切割成四塊，然后遇到dpr為2的時(shí)候，被切割的四塊又被分別切割成四塊，但是總面積不變。

知道了1個(gè)css像素覆蓋的物理像素可能不同，就好理解為什么會(huì)出現(xiàn)模糊的情況了。

這里又講到一個(gè)名詞：位圖像素。

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

理論上來(lái)說(shuō)，1個(gè)位圖像素對(duì)應(yīng)1個(gè)物理像素，圖片才能達(dá)到完美清晰的展示。

但是上面說(shuō)過(guò)，在retina屏幕上，會(huì)出現(xiàn)1個(gè)位圖像素對(duì)應(yīng)多個(gè)物理像素。

還是以iphone6為例，1個(gè)位圖像素對(duì)應(yīng)4個(gè)物理像素。由于單個(gè)位圖像素已經(jīng)是最小的數(shù)據(jù)單位了，它不能再被進(jìn)行切割。于是為了能夠顯示出來(lái)，就只能就近取色，從而導(dǎo)致所謂的圖片模糊問(wèn)題。如下：

很明顯，由于位圖像素不夠分而產(chǎn)生模糊的情況，解決的辦法十分簡(jiǎn)單，就是使用跟dpr同個(gè)倍數(shù)大小的圖片。比如iphone6，一個(gè)200x300的img標(biāo)簽，原圖就要提供400x600的大小。

那么當(dāng)加載到img標(biāo)簽中，瀏覽器會(huì)自動(dòng)對(duì)每1px的css像素減半，可以理解為此時(shí)還是維持著1:1的css像素:物理像素，不產(chǎn)生模糊。

這個(gè)做法其實(shí)就是手淘團(tuán)隊(duì)在做retina適配的一個(gè)重要的原理之一，后面會(huì)講到，這里先放著不說(shuō)。

反向思考一下，如果普通屏幕，也就是dpr為1的屏幕，也使用了兩倍的圖片，會(huì)發(fā)生什么樣的情況呢？

很明顯，在普通屏幕下，200×300的img標(biāo)簽，所對(duì)應(yīng)的物理像素個(gè)數(shù)就是200×300個(gè)，而兩倍圖片的位圖像素個(gè)數(shù)則是200x300x4，于是就出現(xiàn)一個(gè)物理像素點(diǎn)對(duì)應(yīng)4個(gè)位圖像素點(diǎn)，所以它的取色也只能通過(guò)一定的算法進(jìn)行縮減，顯示結(jié)果就是一張只有原圖像素總數(shù)四分之一，肉眼看上去雖然圖片不會(huì)模糊，但是會(huì)覺(jué)得有點(diǎn)色差。（其實(shí)就是模糊的逆向過(guò)程）

用圖片來(lái)表示就是：

這里摘取了網(wǎng)上一篇博文的demo來(lái)闡述上面所說(shuō)的問(wèn)題。

以上是一張100x100的圖片，分別放在了100x100，50x50，25x25的容器中，在retina屏幕下面的顯示效果。

通過(guò)取色器放大鏡可以看出邊界像素點(diǎn)的差別：

在圖一中，邊界像素點(diǎn)就近取色，色值介于紅白之間，偏淡，圖片看上去會(huì)模糊(可以理解為圖片拉伸)。

在圖二中，圖片正常，很清晰。

在圖三中，邊界像素點(diǎn)就近取色，色值介于紅白之間，偏濃，圖片看上去有色差。

現(xiàn)今，適配手機(jī)端的傳統(tǒng)rem布局已經(jīng)逐步被手淘團(tuán)隊(duì)的一套flexible布局代替。

具體的實(shí)現(xiàn)方式以及細(xì)節(jié)這里也不鋪開來(lái)說(shuō)，具體參考w3cplus的一篇文章，很容易讀懂和理解。

這里我更想分析一下flexible.js做法的意義和原因。

讀過(guò)文章之后，相信大家應(yīng)該對(duì)整個(gè)開發(fā)適配的流程比較熟悉了。

假設(shè)現(xiàn)在要適配一個(gè)iphone6的設(shè)備。上面已經(jīng)說(shuō)過(guò)了iphone6的各個(gè)參數(shù)，這里不再贅述，需要的自行上移查看。

于是：

設(shè)計(jì)師給了一個(gè)750px寬度的設(shè)計(jì)稿（注意這里是750px而不是375px）

前端工程師用750px的這個(gè)比例開始還原

把寬高是px的轉(zhuǎn)換成rem

字體使用px而不使用rem

flexible.js會(huì)自動(dòng)判斷dpr進(jìn)行整個(gè)布局視口的放縮

從flexible.js中可見，在寬高中使用的是rem，這是為了保證在不同寬度尺寸的設(shè)備中能夠保證布局的等比例縮放。

而為什么字體不使用rem而是采用px呢？

首先，用過(guò)rem單位的小伙伴都會(huì)發(fā)現(xiàn)，使用rem后由于不同的尺寸，換算之后出現(xiàn)各種奇奇怪怪的數(shù)值，最為明顯的就是更多的小數(shù)位，比如13.755px之類的數(shù)值。在瀏覽器中，各瀏覽器中對(duì)小數(shù)點(diǎn)的計(jì)算存在偏差，而且有些帶小數(shù)的font-size值在特定的瀏覽器顯示并不夠清晰。

其次，我們希望在小屏幕下面顯示跟大屏幕同等量的字體。并且如果使用rem的話，那么由于等比例的存在，在小屏幕下就會(huì)存在小屏幕字體更小的情況，不利于我們更好的去閱讀，違背了適配的初衷。所以，對(duì)于字體的適配，更好的做法就是使用px和媒體查詢來(lái)進(jìn)行適配。

所以，也就不難解釋為什么要對(duì)font-size進(jìn)行放大的處理了，如下的sass代碼：

@mixin font-dpr($font-size) {
    font-size: $font-size;
    [data-dpr="2"] & {
        font-size: $font-size * 2;
    }
    [data-dpr="3"] & {
        font-size: $font-size * 3;
    }
}

由于retina屏幕下dpr的不同，我們又想顯示的字體一樣大，于是就給字體再增大dpr的倍數(shù)，這樣當(dāng)縮小dpr倍的時(shí)候，那么字體也就和設(shè)計(jì)稿所示的大小一樣大了，在不同的手機(jī)中顯示的大小也是一致的。

從flexible.js的代碼中可以知道，flexible布局僅僅只是針對(duì)iPhone進(jìn)行適配，而默認(rèn)所有的安卓設(shè)備都強(qiáng)制性設(shè)置dpr為1。

于是，因?yàn)檫@個(gè)緣故，很多小伙伴可能就會(huì)產(chǎn)生這樣的問(wèn)題：為什么安卓不用retina屏幕，安卓下面是不是就不會(huì)有模糊的問(wèn)題？

其實(shí)不然，模糊的本質(zhì)是因?yàn)閐pr，而安卓手機(jī)不同的設(shè)備的dpr也是不盡相同的。也就是說(shuō)，安卓手機(jī)下也存在模糊的情況。只不過(guò)它的屏幕不叫retina屏幕，沒(méi)有這個(gè)叫法，所以很多小伙伴都誤認(rèn)為安卓手機(jī)沒(méi)有這個(gè)毛病。

那么問(wèn)題又來(lái)了？既然也有模糊的毛病，那么為什么安卓手機(jī)不進(jìn)行適配呢？

問(wèn)題就在這里了，有興趣的小伙伴可以去看一下大中華的安卓手機(jī)，dpr參數(shù)五花八門，從1到4，連1.75、2.75這種奇葩的數(shù)字也有，所以個(gè)人覺(jué)得權(quán)衡之下，直接簡(jiǎn)單“粗暴”把安卓手機(jī)全部設(shè)置為1，是效率和收益更高的做法。

當(dāng)然，也有人進(jìn)行了flexible.js的改進(jìn)，就是對(duì)dpr比較正常的安卓手機(jī)進(jìn)行適配，也就是說(shuō)只適配dpr為整數(shù)的安卓設(shè)備。對(duì)于那些奇葩的dpr為1.75的設(shè)備直接忽略。實(shí)現(xiàn)這個(gè)并不難，有興趣的小伙伴們可以試下。

最后，對(duì)于響應(yīng)式和自適應(yīng)的區(qū)別，網(wǎng)上有各種各樣的解釋。

個(gè)人認(rèn)為，其實(shí)沒(méi)必要把它講得那么復(fù)雜，知乎上有個(gè)小伙伴講我覺(jué)得就很白話文：

響應(yīng)式針對(duì)的是不同分辨率設(shè)備而進(jìn)行的適配式設(shè)計(jì)，以利用@media規(guī)則為主要手段，而自適應(yīng)則忽略@media以比例布局為主，目的是適應(yīng)不同的瀏覽器窗口大小。

于是我們會(huì)發(fā)現(xiàn)，現(xiàn)今大型網(wǎng)站，例如說(shuō)淘寶網(wǎng)，已經(jīng)沒(méi)有做響應(yīng)式了。什么意思呢？

我們會(huì)發(fā)現(xiàn)，淘寶網(wǎng)手機(jī)端和網(wǎng)頁(yè)端使用的是兩個(gè)域名，也就是說(shuō)，不同的客戶端已經(jīng)不再共用一套dom結(jié)構(gòu)了。而是區(qū)分開來(lái)做自適應(yīng)。然后每次用戶訪問(wèn)的時(shí)候它就根據(jù)客戶端的類型重定向。

為什么呢？

試想一下淘寶這種大型網(wǎng)站，一個(gè)分頁(yè)下的商品條目特別多，并且每個(gè)商品條目的dom結(jié)構(gòu)又十分復(fù)雜，而且pc端往往顯示的信息是要比手機(jī)端更多的。如果不分開做兩套，而是直接用響應(yīng)式的話，那么pc端上顯示的很多dom就要在手機(jī)端上隱藏，結(jié)果這些dom都沒(méi)有被用到，但是卻加載了。在這個(gè)流量和速度至上的時(shí)代，代碼冗余先不說(shuō)，多加載的這些無(wú)用的代碼而消耗的流量，從某種意義上來(lái)說(shuō)就已經(jīng)損失了很多的效益。

考慮到兼容性的問(wèn)題，原先我們?cè)谖恼骂^部說(shuō)到的那段代碼：

從Chrome32+版本開始是會(huì)默認(rèn)禁用用戶縮放的，但是考慮到兼容大部分設(shè)備，還是要加上其他設(shè)置，讓meta標(biāo)簽?zāi)軌蛴懈玫娜蒎e(cuò)性。也就是下面這段代碼：

需要注意的是，在ios10+以上，盡管開發(fā)者設(shè)置了user-scalable=no，Safari還是允許用戶通過(guò)手勢(shì)來(lái)縮放。（安卓手機(jī)各大廠商的內(nèi)置瀏覽器也逐漸開放用戶縮放，即使使用meta標(biāo)簽進(jìn)行設(shè)置）

解決的方法也很簡(jiǎn)單，只需要檢測(cè)touch相關(guān)事件來(lái)阻止事件的觸發(fā)即可。

window.onload = function() {
    // 同時(shí)按下兩個(gè)手指
    document.addEventListener("touchstart", function(event) {
        if(event.touches.length > 1) {
            event.preventDefault()
        }
    })
    var lastTouchEnd = 0;
    // 特別注意300ms時(shí)差的設(shè)置
    document.addEventListener("touchend", function(event) {
        var now = (new Date()).getTime();
        if(now-lastTouchEnd <= 300) {
            event.preventDefault();
        }
        lastTouchEnd = now;
    })
}

以上，就是本文的全部啦。

文章有借鑒，借鑒的鏈接都會(huì)在這里放出來(lái)。

前輩們的經(jīng)驗(yàn)和知識(shí)很寶貴，我們需要做的，是站在巨人的肩膀上，去提煉這些東西，有自己更好的理解、思考和開拓新知識(shí)面。

相關(guān)鏈接：

移動(dòng)端適配方案（主要講解的是移動(dòng)端視口方面的知識(shí)）：
https://segmentfault.com/a/11...
https://segmentfault.com/a/11...

Retina屏幕下模糊的由來(lái)：
http://mobile.51cto.com/web-4...

手淘flexible.js布局：
http://www.w3cplus.com/mobile...