一篇搞定移動端適配

 

原文做者:好學習吧丶php

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

1、爲何要移動端適配?

通常狀況下設計稿的設計師按照 375 的尺寸設計,然而,在如今移動終端(就是手機)快速更新的時代,每一個品牌的手機都有着不一樣的物理分辨率,這樣就會致使,每臺設備的邏輯分辨率也不盡相同,此時 375 的設計稿,若是想要還原那基本是不可能了,由於若是一個左右佈局,左邊若是寫死,右邊自適應的話,每一個設備的右邊所展現的內容大小就不盡相同,這時移動端適配就顯得尤爲重要。html

既然要了解前世此生,咱們就從幾個概念提及,先上一張圖。前端

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

下面咱們一個個解析webpack

1.1 屏幕尺寸

屏幕尺寸是以屏幕對角線的長度來計量,計量單位爲英寸。web

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

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

1.2 像素

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

1.2.1 什麼叫像素呢?ide

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

1.2.2 什麼叫分辨率呢?

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

知道什麼叫作分辨率後,有人就會奇怪,我記得蘋果的蘋果官網上的蘋果 6 的分辨率爲 750x1334 啊,可是設計稿上蘋果 6 的分辨率爲 375x667 啊,並且各個設備的分辨率都比實際分辨率小不少,這就牽扯到一些歷史緣由了

1.2.3 設備物理分辨率(設備像素)

相信咱們全部前端開發者,都是見證了手機這個移動設備發展的過程。從藍屏手機,到彩屏手機,到諾基亞研發出來觸屏手機,再到智能手機一步步發展下來,咱們的咱們的手愈來愈清晰,愈來愈大,因此咱們的屏幕發展也愈來愈迅速。

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

上圖能夠清楚的看到,不一樣分辨率所帶來的的差距

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

1.2.4 邏輯分辨率(設備獨立像素)

以下圖所示,雖然設備物理分辨不一樣,可是他的這個邏輯分辨率卻都差很少,這就要感謝喬幫主了。

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

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

1.2.5 設備像素比

設備像素比 device pixel ratio 簡稱 dpr,即物理像素和設備獨立像素的比值。爲何要知道設備像素比呢?由於這個像素比會產生一個很是經典的問題,1 像素邊框的問題。

  1. 1px 邊框問題

當咱們 css 裏寫的 1px 的時候,因爲它是邏輯像素,致使咱們的邏輯像素根據這個設備像素比(dpr)去映射到設備上就爲 2px,或者 3px,因爲每一個設備的屏幕尺寸不同,就致使每一個物理像素渲染出來的大小也不一樣(記得上面的知識點嗎,設備的像素大小是不固定的),這樣若是在尺寸比較大的設備上,1px 渲染出來的樣子至關的粗礦,這就是經典的一像素邊框問題。

  1. 如何解決

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

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

其中 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 有不一樣的處理。因此若是咱們把單位設置成小數的 px 包括寬高等,其實不太可靠,由於不一樣瀏覽器表現不同。

至於其餘解決一像素邊框問題網上有一堆答案,在這裏我推薦一種很是好用,而且沒有反作用的解決方案。

transform: scale(0.5) 方案

div {
height:1px;
background:#000;
-webkit-transform: scaleY(0.5);
-webkit-transform-origin:0 0;
overflow: hidden;
}

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

/* 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);
    }
}

如此,完美的解決一像素看着粗的問題。

擴展補充

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

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

2、如何適配

2.1 viewport

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

那麼在移動端如何配置視口呢?簡單的一個 meta 標籤便可!

<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1; minimum-scale=1; user-scalable=no;">

他們分別什麼含義呢?

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

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

理想視口:通常來說,這個視口其實不是真是存在的,它對設備來講是一個最理想佈局視口尺寸,在用戶不進行手動縮放的狀況下,能夠將頁面理想地展現。那麼所謂的理想寬度就是瀏覽器(屏幕)的寬度了。

因而上述的 meta 設置,就是咱們的理想設置,他規定了咱們的視口寬度爲屏幕寬度,初始縮放比例爲 1,就是初始時候咱們的視覺視口就是理想視口!

其中 user-scalable 設置爲 no 能夠解決移動端點擊事件延遲問題(拓展)

2.2 適配方法

2.2.1 rem 適配

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

舉個例子:

//假設我給根元素的大小設置爲14px
html{
    font-size:14px
}
//那麼我底下的p標籤若是想要也是14像素
p{
    font-size:1rem
}
//如此便可

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

他的原理很是簡單

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

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 份。

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

vh 和 vw 方案和 rem 相似也是至關麻煩須要作單位轉化,並且 px 轉換成 vw 不必定能徹底整除,所以有必定的像素差。

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

{
loader: 'postcss-loader',
options: {
plugins: ()=>[
require('autoprefixer')({
browsers: ['last 5 versions']
        	}),
require('postcss-px-to-viewport')({
viewportWidth: 375, //視口寬度(數字)
        		viewportHeight: 1334, //視口高度(數字)
        		unitPrecision: 3, //設置的保留小數位數(數字)
        		viewportUnit: 'vw', //設置要轉換的單位(字符串)
        		selectorBlackList: ['.ignore', '.hairlines'], //不須要進行轉換的類名(數組)
                minPixelValue: 1, //設置要替換的最小像素值(數字)
                mediaQuery: false //容許在媒體查詢中轉換px(true/false)
        	})
    	]
}

2.2.3 px 爲主,vx 和 vxxx(vw/vh/vmax/vmin)爲輔,搭配一些 flex(推薦)

之因此推薦使用此種方案,是因爲咱們要去考慮用戶的需求,用戶之因此去買大屏手機,不是爲了看到更大的字,而是爲了看到更多的內容,這樣直接使用 px 是最明智的方案,使用 vw,rem 等佈局手段無可厚非,可是,flex 這種彈性佈局大行其道的今天,若是若是還用這種傳統的思惟去想問題顯然是有兩個緣由(我的認爲 px 是最好的,可能有大佬,能用 vw,或者 rem 寫出精妙的佈局,也說不許)。

  1. 爲了偷懶,不肯意去作每一個手機的適

  2. 不肯意去學習新的佈局方式,讓 flex 等先進的佈局和你擦肩而過

2.3 移動端適配流程

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

2. 在 css 中使用 px

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

4. 在跨設備類型的時候(pc <-> 手機 <-> 平板)使用媒體查詢

5. 在跨設備類型若是交互差別太大的狀況,考慮分開項目開發

寫在最後

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

 

 

 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
相關文章
相關標籤/搜索