面試官：你瞭解過移動端適配嗎？

鏈接：https://juejin.im/post/5e6caf55e51d4526ff026a71

前言

手機市場日漸豐富的同時，給我們前端開發人員帶來的 “網頁內容自適應屏幕尺寸進行顯示的問題” 也日漸凸顯出來，接下來我們就要細說移動端適配的前世今生及方案。

一、為什麼要移動端適配？

一般情況下設計稿的設計師按照 375 的尺寸設計，然而，在現在移動終端（就是手機）快速更新的時代，每個品牌的手機都有著不同的物理分辨率，這樣就會導致，每臺設備的邏輯分辨率也不盡相同，此時 375 的設計稿，如果想要還原那基本是不可能了，因為如果一個左右佈局，左邊如果寫死，右邊自適應的話，每個設備的右邊所展示的內容大小就不盡相同，這時移動端適配就顯得尤其重要。

既然要了解前世今生，我們就從幾個概念說起，先上一張圖。

下面我們一個個解析

1.1 屏幕尺寸

屏幕尺寸是以屏幕對角線的長度來計量，計量單位為英寸。

如圖所示兩個對角線的長度就是這個屏幕的尺寸

1.2 像素

我們看到上圖 320x480 叫分辨率，而這個所謂的分辨率說白了就是橫向320個像素縱向480個像素組成

1.2.1 什麼叫像素呢？

像素（Pel, pixel, pictureelement），為組成一幅圖像的全部亮度和色度的最小圖像單元。電視的圖像是由按一定間隔排列的亮度不同的像點構成的，形成像點的單位也就是像素，組成圖像的最小單位就是像素。從計算機技術的角度來解釋，像素是硬件和軟件所能控制的最小單位。它指顯示屏的畫面上表示出來的最小單位，不是圖畫上的最小單位。一幅圖像通常包含成千上萬個像素，每個像素都有自己的顏色信息，它們緊密地組合在一起。由於人眼的錯覺，這些組合在一起的像素被當成一幅完整的圖像。當修改圖像的某區域，實際上是在修改該區域內的像素。對這些像素修改的好與壞將決定最終圖片的質量。單位面積內的像素越多，圖像的效果就越好。彩色電視圖像是由成千個像素點所組成的，而且每個像素都是由紅綠藍三種顏色並排組成的。(注意每個像素的大小是不固定的，他是根據設備的分辨率決定的，知識點，後面要考

1.2.2 什麼叫分辨率呢?

屏幕分辨率是指縱橫向上的像素點數，單位是 px。屏幕分辨率確定計算機屏幕上顯示多少信息的設置，以水平和垂直像素來衡量。就相同大小的屏幕而言，當屏幕分辨率低時（例如 640 x 480），在屏幕上顯示的像素少，單個像素尺寸比較大。屏幕分辨率高時（例如 1600 x 1200），在屏幕上顯示的像素多，單個像素尺寸比較小。

知道什麼叫做分辨率後，有人就會奇怪，我記得蘋果的蘋果官網上的蘋果 6 的分辨率為 750x1334 啊，但是設計稿上蘋果 6 的分辨率為 375x667 啊，而且各個設備的分辨率都比實際分辨率小很多，這就牽扯到一些歷史原因了

1.2.3 設備物理分辨率（設備像素）

相信我們所有前端開發者，都是見證了手機這個移動設備發展的過程。從藍屏手機，到彩屏手機，到諾基亞研發出來觸屏手機，再到智能手機一步步發展下來，我們的我們的手越來越清晰，越來越大，所以我們的屏幕發展也越來越迅速。

上圖可以清楚的看到，不同分辨率所帶來的的差距

從最初的顆粒感相當大的屏幕，到 720p 再到 1080p，甚至於現在各家旗艦手機的 2k 屏幕，我們的物理分辨率在變得原來越大。這樣就暴露出來一個問題，我們如果手機分辨率翻倍，我們的圖像不就要被縮小一倍，我們難道要在每個設備上就出個設計稿，每個設備的分辨不盡相同啊，其實你擔憂的問題，我們的喬幫主在很多年前就想到了。這就是我們的邏輯分辨率

1.2.4 邏輯分辨率（設備獨立像素）

如下圖所示，雖然設備物理分辨不同，但是他的這個邏輯分辨率卻都差不多，這就要感謝喬幫主了。

喬布斯在 iPhone4 的發佈會上首次提出了 Retina Display(視網膜屏幕)的概念，在 iPhone4 使用的視網膜屏幕中，把 2x2 個像素當 1 個像素使用，這樣讓屏幕看起來更精緻，但是元素的大小卻不會改變。從此以後高分辨率的設備，多了一個邏輯像素。這些設備邏輯像素的差別雖然不會跨度很大，但是仍然有點差別，於是便誕生了移動端頁面需要適配這個問題，既然邏輯像素由物理像素得來，那他們就會有一個像素比值。

1.2.5 設備像素比

設備像素比 device pixel ratio 簡稱 dpr，即物理像素和設備獨立像素的比值。為什麼要知道設備像素比呢？因為這個像素比會產生一個非常經典的問題，1 像素邊框的問題。

1. 1px 邊框問題

當我們 css 裡寫的 1px 的時候，由於它是邏輯像素，導致我們的邏輯像素根據這個設備像素比（dpr）去映射到設備上就為 2px，或者 3px，由於每個設備的屏幕尺寸不一樣，就導致每個物理像素渲染出來的大小也不同（記得上面的知識點嗎，設備的像素大小是不固定的），這樣如果在尺寸比較大的設備上，1px 渲染出來的樣子相當的粗礦，這就是經典的一像素邊框問題。

2. 如何解決

核心思路，就是在 web 中，瀏覽器為我們提供了 window.devicePixelRatio 來幫助我們獲取 dpr。在 css 中，可以使用媒體查詢 min-device-pixel-ratio，區分 dpr：我們根據這個像素比，來算出他對應應該有的大小，但是暴露個非常大的兼容問題。

其中 Chrome 把 0.5px 四捨五入變成了 1px，而 firefox/safari 能夠畫出半個像素的邊，並且 Chrome 會把小於 0.5px 的當成 0，而 Firefox 會把不小於 0.55px 當成 1px，Safari 是把不小於 0.75px 當成 1px，進一步在手機上觀察 iOS 的 Chrome 會畫出 0.5px 的邊，而安卓(5.0)原生瀏覽器是不行的。所以直接設置 0.5px 不同瀏覽器的差異比較大，並且我們看到不同系統的不同瀏覽器對小數點的 px 有不同的處理。

至於其他解決一像素邊框問題網上有一堆答案，在這裡我推薦一種非常好用，並且沒有副作用的解決方案。

transform: scale(0.5) 方案

<code>div {
    height:1px;
    background:#000;
    -webkit-transform: scaleY(0.5);
    -webkit-transform-origin:00;
    overflow: hidden;
}/<code>

css 根據設備像素比媒體查詢後的解決方案

<code>/* 2倍屏 */
@media only screen and (-webkit-min-device-pixel-ratio: 2.0) {
    .border-bottom::after {
        -webkit-transform: scaleY(0.5);
        transform: scaleY(0.5);
    }
}
/* 3倍屏 */
@media only screen and (-webkit-min-device-pixel-ratio: 3.0) {
    .border-bottom::after {
        -webkit-transform: scaleY(0.33);
        transform: scaleY(0.33);
    }
}/<code>

如此，完美的解決一像素看著粗的問題。

擴展補充

CSS 最新的規範中正在計劃通過標準的屬性實現一像素邊框，通過給border-width屬性添加hairline關鍵字屬性來實現，具體如下鏈接[1]。之所以叫hairline，是因為一像素邊框就跟頭髮絲一樣。

練習使用方案時，也要多多關注最新發展喲。

二、如何適配

2.1 viewport

視口(viewport)代表當前可見的計算機圖形區域。在 Web 瀏覽器術語中，通常與瀏覽器窗口相同，但不包括瀏覽器的 UI， 菜單欄等——即指你正在瀏覽的文檔的那一部分。

那麼在移動端如何配置視口呢？簡單的一個 meta 標籤即可！

<code>/<code>

他們分別什麼含義呢？

我們在移動端視口要想視覺效果和體驗好，那麼我們的視口寬度必須無限接近理想視口。

理想視口：一般來講，這個視口其實不是真是存在的，它對設備來說是一個最理想佈局視口尺寸，在用戶不進行手動縮放的情況下，可以將頁面理想地展示。那麼所謂的理想寬度就是瀏覽器（屏幕）的寬度了。

於是上述的 meta 設置，就是我們的理想設置，他規定了我們的視口寬度為屏幕寬度，初始縮放比例為 1，就是初始時候我們的視覺視口就是理想視口！

其中 user-scalable 設置為 no 可以解決移動端點擊事件延遲問題（拓展）

2.2 適配方法

2.2.1 rem 適配

rem 是 CSS3 新增的一個相對單位，這個單位引起了廣泛關注。這個單位與 em 有什麼區別呢？區別在於使用 rem 為元素設定字體大小時，仍然是相對大小，但相對的只是 HTML 根元素。這個單位可謂集相對大小和絕對大小的優點於一身，通過它既可以做到只修改根元素就成比例地調整所有字體大小，又可以避免字體大小逐層複合的連鎖反應。目前，除了 IE8 及更早版本外，所有瀏覽器均已支持 rem。對於不支持它的瀏覽器，應對方法也很簡單，就是多寫一個絕對單位的聲明。這些瀏覽器會忽略用 rem 設定的字體大小。

舉個例子：

<code>//假設我給根元素的大小設置為14px
html{
    font-size：14px
}
//那麼我底下的p標籤如果想要也是14像素
p{
    font-size:1rem
}
//如此即可/<code>

rem 的佈局，不得不提 flexible，flexible 方案是阿里早期開源的一個移動端適配解決方案，引用 flexible 後，我們在頁面上統一使用 rem 來佈局。

他的原理非常簡單

<code>// set 1rem = viewWidth / 10
function setRemUnit () {
    var rem = docEl.clientWidth / 10
    docEl.style.fontSize = rem + 'px'
}
setRemUnit();/<code>

rem 是相對於 html 節點的 font-size 來做計算的。所以在頁面初始話的時候給根元素設置一個 font-size，接下來的元素就根據 rem 來佈局，這樣就可以保證在頁面大小變化時，佈局可以自適應。

如此我們只需要給設計稿的 px 轉換成對應的 rem 單位即可。

當然，這個方案只是個過渡方案，為什麼說是過渡方案

因為當年 viewport 在低版本安卓設備上還有兼容問題，而 vw，vh 還沒能實現所有瀏覽器兼容，所以 flexible 方案用 rem 來模擬 vmin 來實現在不同設備等比縮放的“過度”方案，之所以說是過度方案，是因為這個他這個根據設備大小去判斷頁面的方案是根據屏幕大小去百分百還原設計稿，從而讓人看到的大小效果是一樣的，但是 蘋果 5 和蘋果 6p 雖然看到的設計稿還原是一樣的，但是他在一個合適距離上看到的效果能一樣嗎，本質上，用戶使用更大的屏幕，是想看到更多的內容，而不是更大的字。

so，這個用縮放來解決問題的方案是個過渡方案，註定被時代所淘汰。

2.2.2 vw，vh 佈局

vh、vw 方案即將視覺視口寬度 window.innerWidth 和視覺視口高度 window.innerHeight 等分為 100 份。

vh 和 vw 方案和 rem 類似也是相當麻煩需要做單位轉化，而且 px 轉換成 vw 不一定能完全整除，因此有一定的像素差。

不過在工程化的今天，webpack 解析 css 的時候用 postcss-loader 有個 postcss-px-to-viewport 能自動實現 px 到 vw 的轉化

<code>{
    loader: 'postcss-loader',
    options: {
    \tplugins: ()=>[
        \trequire('autoprefixer')({
        \t\tbrowsers: ['last 5 versions']
        \t}),
        \trequire('postcss-px-to-viewport')({
        \t\tviewportWidth: 375, //視口寬度（數字)
        \t\tviewportHeight: 1334, //視口高度（數字）
        \t\tunitPrecision: 3, //設置的保留小數位數（數字）
        \t\tviewportUnit: 'vw', //設置要轉換的單位（字符串）
        \t\tselectorBlackList: ['.ignore', '.hairlines'], //不需要進行轉換的類名（數組）
                minPixelValue: 1, //設置要替換的最小像素值（數字）
                mediaQuery: false//允許在媒體查詢中轉換px（true/false）
        \t})
    \t]
}/<code>

2.2.3 px 為主，vx 和 vxxx（vw/vh/vmax/vmin）為輔，搭配一些 flex（推薦）

之所以推薦使用此種方案，是由於我們要去考慮用戶的需求，用戶之所以去買大屏手機，不是為了看到更大的字，而是為了看到更多的內容

1. 為了偷懶，不願意去做每個手機的適
2. 不願意去學習新的佈局方式，讓 flex 等先進的佈局和你擦肩而過

2.3 移動端適配流程

1. 在 head 設置 width=device-width 的 viewport‘

2. 在 css 中使用 px

3. 在適當的場景使用 flex 佈局，或者配合 vw 進行自適應

4. 在跨設備類型的時候（pc 手機 平板）使用媒體查詢

5. 在跨設備類型如果交互差異太大的情況，考慮分開項目開發

寫在最後

疫情期間有了跳槽的想法，問到移動端佈局方面，雖然勉強能回答上來，但是總是支支吾吾，不是很瞭解，故而，發下宏願，梳理移動端適配，幫助後來人後來者居上！

閱讀更多 程序員BUG 的文章

關鍵字: iPhone 移動