如何解決存在的1px問題？

最近在項目開發(fā)中一直深受 1px 的困擾，移動端展示的樣式不是偏粗就是偏細(xì)、甚至無法看清。也許大家都嘗試過或正在使用著各種解決方案，可是對于物理像素、邏輯像素、設(shè)備像素比等概念到底是什么，為什么會產(chǎn)生 1 像素等問題始終是一頭霧水。。在進(jìn)行了一番調(diào)研后，發(fā)現(xiàn)網(wǎng)上對于一些細(xì)節(jié)原理描述的都不太清晰。故本文結(jié)合了個人的一些理解，重點對其原理及實現(xiàn)進(jìn)行探討，希望能對像素相關(guān)問題徹底解惑。

為了便于更好的理解本文，下面對像素相關(guān)概念進(jìn)行梳理。

簡單來說就是像素單位基本分為三種：設(shè)備像素(物理像素)、設(shè)備獨立像素(邏輯像素)、CSS 像素。下文將會圍繞相關(guān)概念展開討論。

話不多說，正文開始~~

為什么使用 1px 會出現(xiàn)問題

自從 2010 年 iPhone4 推出了 Retina 屏開始，移動設(shè)備屏幕的像素密度越來越高，于是便有了 2 倍屏、3 倍屏的概念。簡單來說，就是手機(jī)屏幕尺寸沒有發(fā)生變化，但屏幕的分辨率卻提高了一倍，即同樣大小的屏幕上，像素多了一倍。那么我們獲取到的 CSS 像素就不是真實的物理像素點了，于是便有了設(shè)備像素比的概念（ devicePixelRatio 簡稱 dpr）。它用來描述屏幕物理像素與邏輯像素的比值。不同手機(jī)有不同的設(shè)備像素比，可參考 wiki 百科中對視網(wǎng)膜屏的描述^[1] 。

CSS 中的 1px 并不等于設(shè)備的 1px

對于前端來說，在高清屏出現(xiàn)之前，前端代碼的 1px 即等于手機(jī)物理像素點的 1px。但有了 dpr 的概念之后，由于前端代碼中的使用的是 CSS 像素，手機(jī)會根據(jù) dpr 換算成實際的物理像素大小來渲染頁面。比如 iPhone6 的設(shè)備像素比 dpr = 2 ，相當(dāng)于一個 CSS 像素等于兩個物理像素，即 1px 由 2個物理像素點組成。

那么問題來了，以 iPhone6 為例，其 dpr = 2、屏幕尺寸(CSS 像素) 為 375x667，一般設(shè)計稿提供 2 倍圖尺寸為 750x1334 。那么設(shè)計稿中的 1px，對應(yīng)屏幕尺寸其實應(yīng)該寫成 0.5px。再由 dpr 計算公式可知，0.5 * 2 = 1px 物理像素。

此時你應(yīng)該已經(jīng)發(fā)現(xiàn)了，設(shè)計稿要實現(xiàn) 1px 細(xì)線、1px 邊框，為什么前端實現(xiàn)總是偏粗的？那是因為如果你在代碼中直接寫成 1px，再通過 dpr 計算之后其實是 2px 物理像素，并不符合設(shè)計稿的要求。

其實設(shè)計稿本質(zhì)上要實現(xiàn)的是 CSS 像素的 ！

那么當(dāng) dpr=2 時，代碼中直接寫成 0.5px 就解決問題了嗎？

小數(shù)點像素 0.5px 的兼容性問題

其實在項目中，我們已經(jīng)采用 rem 單位進(jìn)行了設(shè)計稿與屏幕尺寸的換算，即把 1px 換算成了 0.5px 。但這種方案其實有各種各樣的兼容性問題。

PC端

先上結(jié)論，在 PC 端瀏覽器的最小識別像素為 1px。

所以在開發(fā)階段，當(dāng)在開發(fā)者工具上進(jìn)行頁面調(diào)試時，可以看到即便代碼中是 0.5px ，但默認(rèn)會被瀏覽器識別并渲染為 1px。所以在瀏覽器看來總是偏粗了。如果你習(xí)慣用 PC 端的頁面來進(jìn)行視覺走查，那么結(jié)果可想而知...

上圖中兩個元素 width:200px;height:100px，分別為 border:0.5px、border:1px ，檢查元素時可以看到頁面上 border=0.5px 的元素計算大小后和 1px 效果是一樣的，均是 width:202px;height:102px。說明瀏覽器都識別成 1px 了。

由上面的 gif 圖也可以看到，因為設(shè)備 dpr=2，所以放大后 1px 的確是使用了2個物理像素點來渲染。并不是我們想實現(xiàn)的 0.5px。

移動端

在手機(jī)端，不同手機(jī)瀏覽器對小數(shù)點像素的處理效果就更千奇百怪了。

首先我們先來看一下采用 REM 布局方式下，代碼中的 0.01rem 到底被換算成了多少？

這里簡單說下 REM 實現(xiàn)原理

rem（font size of the root element），即根據(jù)網(wǎng)頁的根元素（html）來設(shè)置字體大小。和 em（font size of the element） 的區(qū)別是，em 是根據(jù)其父元素的字體大小來進(jìn)行設(shè)置。

簡單來說，rem 布局實現(xiàn)移動端適配的思想是，由于 rem 單位是根據(jù)頁面根元素的 fontSize 來計算的，那么將 fontSize 設(shè)置成屏幕寬度 clientWidth 與設(shè)計稿寬度 750 的比值，那么我們按照設(shè)計稿的尺寸來重構(gòu)頁面的時候，使用 rem 單位即自動乘以 fontSize 計算出了適配不同屏幕的尺寸。

//?以750設(shè)計稿為例，計算rem?font-size
let?clientWidth?=?document.documentElement.clientWidth?||?document.body.clientWidth;
let?ft?=?(clientWidth?/?7.5).toFixed(2);
//?設(shè)置頁面根字號大小
document.documentElement.style.fontSize?=?ft?+?"px";


由上面的計算方式可知，不同屏幕寬度會計算出不同 fontSize ，那么 0.01rem 到底被換算成了多少呢？下面舉例計算了幾個機(jī)型的“1像素”大小

由表格可看出，不同手機(jī)計算的“1px”大小差別很大，而且手機(jī)本身對小數(shù)點的處理情況就存在較大的兼容性問題。

比如 IOS8+ 系列都已經(jīng)支持 0.5px 了，可以借助媒體查詢來處理，但是安卓手機(jī)對小數(shù)像素的表現(xiàn)形式卻各不相同。網(wǎng)上關(guān)于不同型號手機(jī)瀏覽器對小數(shù)點的處理情況的資料較少，只知道在一些低版本的系統(tǒng)里，0.5px 將會被顯示為 0px；有的能夠畫出半個像素的邊，有的大于 0.55px 當(dāng)成 1px，有的大于 0.75px 當(dāng)成 1px，從表格計算結(jié)果來看是很難直接實現(xiàn)適配的。

比如 HUAWAI P30 的 0.01rem 計算后為 0.48px ，這種較小的小數(shù)像素其 border 已經(jīng)無法正常展示了。

那么如何實現(xiàn) 1px 的效果？

在進(jìn)行一番調(diào)研之后，發(fā)現(xiàn)目前的實現(xiàn)方案都離不開以下三種。

1. 使用偽元素 + CSS3``縮放的方式
2. 使用 動態(tài)?viewport + rem 布局 的方式（即 Flexible 實現(xiàn)方案）
3. 新方案：使用 vw?單位適配方案（將來推薦的一種方案，但目前項目中沒有實際應(yīng)用，故本文不做討論）

1. 偽元素 + CSS3縮放

其實這種方案也是大家在項目中經(jīng)常使用的方式。文本主要對其實現(xiàn)原理進(jìn)行分析。

前面已經(jīng)討論過要實現(xiàn)設(shè)計稿中的 1px，其實代碼中要實現(xiàn) 0.5px 。縮放的方式就是避免了直接寫小數(shù)像素帶來的不同手機(jī)的兼容性處理不同。先上代碼：

//?通過偽元素實現(xiàn)?0.5px?border
.border::after?{
????content:?"";
????box-sizing:?border-box;?//?為了與原元素等大
????position:?absolute;
????left:?0;
????top:?0;
????width:?200%;?
????height:?200%;?
????border:?1px?solid?gray;
????transform:?scale(0.5);?
????transform-origin:?0?0;
}

//?通過偽元素實現(xiàn)?0.5px?細(xì)線
.line::after?{
????content:?'';
????position:?absolute;
????top:?0;
????left:?0;
????width:?200%;
????height:?1px;
????background:?#b3b4b8;
????transform:?scale(0.5);
????transform-origin:?0?0;
}

//?dpr適配可以這樣寫
@media?(-webkit-min-device-pixel-ratio:?2)??{
????.line::after?{
?????...
??????height:?1px;
????????transform:?scale(0.5);
????????transform-origin:?0?0;
????}
}

@media?(-webkit-min-device-pixel-ratio:?3)??{
????.line::after?{
????????...
??????height:?1px;
????????transform:?scale(0.333);
????????transform-origin:?0?0;
????}
}


為什么要先放大 200% 再縮小 0.5？

為了只縮放 border 1px 的粗細(xì)，而保證 border 的大小不變。如果直接 scale(0.5) 的話 border 整體大小也會變成二分之一，所以先放大 200%（放大的時候 border 的粗細(xì)是不會被放大的）再縮放，就能保持原大小不變了。

為什么采用縮放的方式，就可以解決手機(jī)對小數(shù)點處理的兼容性問題？

此處我是這樣理解的。首先代碼中處理的是 1px ，避免了直接操作小數(shù)像素的問題；當(dāng) dpr=2 時，換算成物理像素為 2px，此時去縮放 scale(0.5)、當(dāng) dpr=3 時，換算成物理像素為 3px，此時縮放 scale(0.3) 后，手機(jī)均會默認(rèn)使用最小物理像素 1px 來渲染。按照 CSS3 transform 的 scale 定義，邊框可以任意細(xì)，理論上可以實現(xiàn)任意細(xì)的縮放效果。

該方案的優(yōu)點在于，針對老項目使用縮放的形式可以快速實現(xiàn) 1px 的效果。

需要注意的是，我們是在 1px 的基礎(chǔ)上進(jìn)行縮放！

• 如果項目中使用了 rem 單位的話，此處的 1px 是不能用 rem 單位的，否則根據(jù) rem 換算后再進(jìn)行縮放，會使得邊框變得更細(xì)。

• 如果項目中使用了 postcss-pxtorem 插件進(jìn)行編譯的話，記得不要對 1px 進(jìn)行編譯。配置文檔參考 postcss-pxtorem^[2] 。

  .ignore {
  border: 1Px solid; // ignored
  border-width: 2PX; // ignored }

Px or PX is ignored by postcss-pxtorem but still accepted by browsers。

2. 動態(tài) Viewport + REM 方式

第二種實現(xiàn)方案是采用動態(tài)設(shè)置 viewport + rem 布局，該方案其實是參考了阿里早期開源的一個移動端適配解決方案 flexible ，本文進(jìn)行了一些改進(jìn)。該方案不僅解決了移動端適配的問題，同時也較好的解決了 1px 的問題。

在理解它的實現(xiàn)原理之前，我們先來了解幾個關(guān)鍵概念 viewport視口 及 meta 標(biāo)簽 及 頁面縮放 initial-sacle。

視口

就是瀏覽器上(或者是一個 APP 中的 webview )用來顯示網(wǎng)頁的那部分區(qū)域，但 viewport 又不局限于瀏覽器可視區(qū)域的大小，它可能比瀏覽器的可視區(qū)域要大，也可能比瀏覽器的可視區(qū)域要小。

網(wǎng)上關(guān)于 viewport 的介紹比較經(jīng)典的就是 Peter-Paul Koch^[3] 的 A tale of two viewports^[4] 。它闡述了三種 viewport，我們一般最常用的是 layout viewport (瀏覽器默認(rèn)的 viewport)。默認(rèn)寬度大于瀏覽器可視區(qū)域的寬度，所以瀏覽器默認(rèn)會出現(xiàn)橫向滾動條。

const?clientWidth?=?document.documentElement.clientWidth?||?document.body.clientWidth


通過 meta 標(biāo)簽設(shè)置

如果不設(shè)置 meta 標(biāo)簽的話，由于 viewport 默認(rèn)寬度是大于瀏覽器可視區(qū)域的，所以需要通過設(shè)置 viewport 的寬度等于屏幕寬 width=device-width 來避免出現(xiàn)橫向滾動條。

??name="viewport"?
??content="
????width=device-width,??//?設(shè)置viewport的寬等于屏幕寬
????initial-scale=1.0,??//?初始縮放為1
????maximum-scale=1.0,?
????user-scalable=no,??//?不允許用戶手動縮放
????viewport-fit=cover?//?縮放以填充滿屏幕
????"?
>


• name 設(shè)置元數(shù)據(jù)的名稱，content 設(shè)置元數(shù)據(jù)的值。name 屬性值為 viewport 時，表示設(shè)置有關(guān)視口初始大小的提示，僅供移動端使用
• 同時設(shè)置 width=device-width,initial-scale=1.0 是為了兼容 iOS 和 IE 瀏覽器

關(guān)于頁面縮放

initial-scale 縮放值越大，當(dāng)前 viewport 的寬度就會越小，反之亦然。

比如屏幕寬度是 320px 的話，如果我們設(shè)置 initial-scale=2 ，此時 viewport 的寬度會變?yōu)橹挥?160px 了。這也好理解，放大了一倍嘛，就是原來 1px 的東西變成 2px 了，但是并不是把原來的 320px 變?yōu)?640px ，而是在實際寬度不變的情況下，1px 變得跟原來的 2px 的長度一樣了。所以縮放頁面的時候，實際上改變了 CSS 像素的大小，而數(shù)量不變。所以原來需要 320px 才能填滿的寬度現(xiàn)在只需要 160px 就做到了。

在開篇的表格中對 CSS 像素的定義是，不考慮縮放情況下，1個 CSS 像素等于1個設(shè)備獨立像素。頁面放大 200% 時，CSS 像素個數(shù)不變，大小變?yōu)槎叮喈?dāng)于一個 CSS 像素在橫縱向上會覆蓋兩個設(shè)備獨立像素。瀏覽器窗口可容納的設(shè)備獨立像素數(shù)量是不變的，所以可視區(qū)域內(nèi) CSS 像素數(shù)量變少。

Flexible 適配方案及問題

有了上面幾個概念，下面我們來說說 flexible 方案的實現(xiàn)原理及歷史遺留問題。

Flexible 的大致實現(xiàn)思路是，首先根據(jù) dpr 來動態(tài)修改 meta 標(biāo)簽中 viewport 中的 initial-scale 的值，以此來動態(tài)改變 viewport 的大小；然后頁面上統(tǒng)一使用 rem 來布局，viewport 寬度變化會動態(tài)影響 html 中的font-size 值，以此來實現(xiàn)適配。

為什么不直接引用 flexible 庫來進(jìn)行移動端適配呢？

因為 lib-flexible 這個庫目前基本被棄用，由于該方案誕生較早，官方也是認(rèn)為 flexible 已經(jīng)完成了它的歷史使命，比如當(dāng)時它只處理了 iOS 不同 dpr的場景，安卓設(shè)備下默認(rèn)都設(shè)置為 dpr = 1 等，這是有問題的。有關(guān)于這方面的詳細(xì)使用可以閱讀早期整理的文章 使用Flexible實現(xiàn)手淘H5頁面的終端適配^[5] 。

在日常的業(yè)務(wù)場景中，雖然我們不會去使用 flexible 庫，但其實大多還是沿用 flexible 實現(xiàn)的原理來進(jìn)行移動端適配，并從中進(jìn)行了一些改進(jìn)來達(dá)到適配的目的。

下面為簡單實現(xiàn)


??????????name="viewport"
??????content="width=device-width,user-scalable=no,initial-scale=1,
????????????????minimum-scale=1,maximum-scale=1,viewport-fit=cover"
????/>
????
??


為什么頁面縮放比例 initial-scale 設(shè)置為 1 / dpr ？

這也是為什么前文大篇幅去闡述設(shè)備像素比 dpr、縮放等概念了。

通過設(shè)置頁面縮放比例為 1/dpr，可將 viewport 的寬度擴(kuò)大 dpr 倍。還是以 iPhone6 手機(jī)為例，不進(jìn)行頁面縮放時 viewport 寬度 375px、dpr=2。由于 dpr 的存在使得一個 CSS 像素需要兩個物理像素來渲染。

當(dāng)設(shè)置 initial-scale = 1 / dpr = 0.5 時，獲取到的 viewport 寬度 clientWidth = 750px ，被擴(kuò)大了 dpr 倍，就正好是設(shè)備物理像素的寬度。簡單推導(dǎo)一下就是，當(dāng) scale=0.5 時，由于 viewport 內(nèi)可容納的 CSS 像素數(shù)量的增多，相當(dāng)于一個設(shè)備獨立像素在橫縱向上會覆蓋兩個 CSS 像素，

CSS像素個數(shù)?=??設(shè)備獨立像素個數(shù)?/??scale???=?（?物理像素個數(shù)?/?dpr?）/?scale
scale?=?1?/?dpr?
//?所以
CSS像素個數(shù)?=?物理像素個數(shù)


此時我們寫的 1px 其實正好是一個物理像素的大小，并且可以較好的畫出 1px 的邊框，從而提高顯示精度，從此我們就可以愉快地直接寫 1px 啦！同時這個方案也較好的解決了只使用 rem 進(jìn)行布局時，出現(xiàn)計算后的各種 0.5px、0.55px 等問題。完美~

實戰(zhàn)對比

下面為 border 的幾種實現(xiàn)方式在不同測試機(jī)的對比圖。

測試機(jī)型為 iPhone6、iPhone6Plus、iPhoneXR、HUAWEI P30，以 750 的設(shè)計稿為例，設(shè)置 fontSize = clientWidth / 7.5 + 'px'。

4.1 首先采用第一種解決方案即 縮放的形式

? 按鈕1：直接寫 1px，根據(jù) dpr 計算可知，效果總是偏粗的。

? 按鈕2：rem 布局下，不改變 viewport 的縮放比，即 initial-scale= 1，fontSize 計算后范圍在 48px~55px 不等，0.01rem 計算后 iPhone6 為 0.5px ，dpr=2，顯示效果較好；而 Huawei P30 的 0.01rem = 0.48px，此時邊框已經(jīng)展示不清楚了。總體來說效果展示偏細(xì)。

?? 按鈕3：也是 rem 布局下，initial-scale= 1，使用了第一種解決方案， 縮放 0.5 后，總體效果展示較好。

4.2 采用第二種解決方案，即動態(tài)設(shè)置 布局方式的對比圖

設(shè)置 rem 布局下，

?? 按鈕1：直接寫 1px

?? 按鈕4：使用 0.01rem，不同機(jī)型 fontSize 在 100px~144px之間，0.01rem 計算后基本都大于等于 1px。

分析下計算過程：

• iPhone6 屏幕寬 375px，dpr = 2、initial-scale= 0.5 時，clientWidth 變?yōu)?750px，根元素 fontSize = 100px，那么 0.01rem 正好等于 1px，并且大小和設(shè)計稿一致，展示效果理論上應(yīng)該是最好的。
• Huawei P30 屏幕寬 360px，dpr = 3、initial-scale= 0.3 時，clientWidth 變?yōu)?1080px，根元素 fontSize = 144px，那么 0.01rem = 1.44px。其實這個時候我們實現(xiàn)的已經(jīng)大于 1px 了。相當(dāng)于大于1個物理像素來渲染。

兩種方式效果展示都比較好，說明在此方案下，我們可以直接寫 1px 或者 0.01rem 都是可以的。

一些手機(jī)的屏幕分辨率整理

總結(jié)

移動端適配主要就分為兩方面，一方面要適配不同機(jī)型的屏幕尺寸，一方面是對細(xì)節(jié)像素的處理過程。如果你在項目中直接寫了 1px ，由于 dpr 的存在展示導(dǎo)致渲染偏粗，其實是不符合設(shè)計稿的要求。如果你使用了 rem 布局計算出了對應(yīng)的小數(shù)值，不同手機(jī)又有明顯的兼容性問題。此時老項目的話整體修改 viewport 成本過高，可以采用第一種實現(xiàn)方案進(jìn)行 1px 的處理；新項目的話可以采用動態(tài)設(shè)置 viewport 的方式，一鍵解決所有適配問題。

其實移動端對 1px 的渲染適配實現(xiàn)起來配置簡單、代碼簡短，能夠快速上手。但文本通過大量篇幅去闡述其原理，旨在能夠?qū)ζ湔嬲斫獠氐捉饣螅Ｍ軌驅(qū)Υ蠹矣兴鶐椭?/p>

參考

移動前端開發(fā)之viewport的深入理解^[6]

使用Flexible實現(xiàn)手淘H5頁面的終端適配^[7] (Git地址^[8])

剖析 iOS 11 網(wǎng)頁適配問題^[9]

viewports剖析^[10]

再聊移動端頁面的適配^[11]

再談Retina下1px的解決方案^[12]

關(guān)于本文

作者：SDYZ
https://juejin.cn/post/6870691193353666568

最后