通常狀況下設計稿的設計師按照375的尺寸設計,然而,在如今移動終端(就是手機)快速更新的時代,每一個品牌的手機都有着不一樣的物理分辨率,這樣就會致使,每臺設備的邏輯分辨率也不盡相同,此時357的設計稿,若是想要還原那基本是不可能了,由於若是一個左右佈局,左邊若是寫死,右邊自適應的話,每一個設備的右邊所展現的內容大小就不盡相同,這是移動端適配就顯得尤爲重要
既然要了解前世此生,咱們就從幾個概念提及先上一張圖css
下面咱們一個個解析html
屏幕尺寸是以屏幕對角線的長度來計量,計量單位爲英寸。
如圖所示兩個對角線的長度就是這個屏幕的尺寸前端
咱們看到上圖320x480叫分辨率,而這個所謂的分辨率就是說白了就橫向320個像素縱向480個像素組成webpack
像素(Pel,pixel;pictureelement),爲組成一幅圖像的所有亮度和色度的最小圖像單元。電視的圖像是由按必定間隔排列的亮度不一樣的像點構成的,造成像點的單位也就是像素,組成圖像的最小單位就是像素。從計算機技術的角度來解釋,像素是硬件和軟件所能控制的最小單位。它指顯示屏的畫面上表示出來的最小單位,不是圖畫上的最小單位。一幅圖像一般包含成千上萬個像素,每一個像素都有本身的顏色信息,它們緊密地組合在一塊兒。因爲人眼的錯覺,這些組合在一塊兒的像素被當成一幅完整的圖像。當修改圖像的某區域,其實是在修改該區域內的像素。對這些像素修改的好與壞將決定最終圖片的質量。單位面積內的像素越多,圖像的效果就越好。彩色電視圖像是由成千個像素點所組成的,並且每一個像素都是由紅綠藍三種顏色並排組成的。(注意每一個像素的大小是不固定的,他是根據設備的分辨率決定的,知識點,後面要考)
屏幕分辨率是指縱橫向上的像素點數,單位是px。屏幕分辨率肯定計算機屏幕上顯示多少信息的設置,以水平和垂直像素來衡量。就相同大小的屏幕而言,當屏幕分辨率低時(例如 640 x 480),在屏幕上顯示的像素少,單個像素尺寸比較大。屏幕分辨率高時(例如 1600 x 1200),在屏幕上顯示的像素多,單個像素尺寸比較小。
知道什麼叫作分辨率後,有人就會奇怪,我記得蘋果的蘋果官網上的蘋果6的分辨率爲750x1334啊,可是設計稿上蘋果6的分辨率爲375x667啊,並且各個設備的分辨率都比實際分辨率小不少,這就牽扯到一些歷史緣由了web
相信咱們全部前端開發者,都是見證了手機這個移動設備發展的過程。從藍屏手機,到彩屏手機,到諾基亞研發出來觸屏手機,再到智能手機一步步發展下來,咱們的咱們的手愈來愈清晰,愈來愈大,因此咱們的屏幕發展也愈來愈迅速。數組
上圖能夠清楚的看到,不一樣分辨率所帶來的的差距瀏覽器
從最初的顆粒感至關大的屏幕,到720p再到1080p,甚至於如今各家旗艦手機的2k屏幕,咱們的物理分辨率在變得原來越大。這樣就暴露出來一個問題,咱們若是手機分辨率翻倍,咱們的圖像不就要被縮小一倍,咱們難道要在每一個設備上就出個設計稿,每一個設備的分辨不盡相同啊,其實你擔心的問題,咱們的喬幫主在不少年前就想到了。這就是咱們的邏輯分辨率佈局
以下圖所示,雖然設備物理分辨不一樣,可是他的這個邏輯分辨率卻都差很少,這就要感謝喬幫主了post
喬布斯在iPhone4的發佈會上首次提出了Retina Display(視網膜屏幕)的概念,在iPhone4使用的視網膜屏幕中,把2x2個像素當1個像素使用,這樣讓屏幕看起來更精緻,可是元素的大小卻不會改變。今後之後高分辨率的設備,多了一個邏輯像素。這些設備邏輯像素的差異雖然不會跨度很大,可是仍然有點差異,因而便誕生了移動端頁面須要適配這個問題,既然邏輯像素由物理像素得來,那他們就會有一個像素比值學習
設備像素比device pixel ratio簡稱dpr,即物理像素和設備獨立像素的比值。爲何要知道設備像素比呢?由於這個像素比會產生一個很是經典的問題,1像素邊框的問題。
當咱們css裏寫的1px的時候,因爲它是邏輯像素,致使咱們的邏輯像素根據這個設備像素比(dpr)去映射到設備上就爲2px,或者3px,因爲每一個設備的屏幕尺寸不同,就致使每一個物理像素渲染出來的大小也不一樣(記得上面的知識點嗎,設備的像素大小是不固定的),這樣若是在尺寸比較大的設備上,1px渲染出來的樣子至關的粗礦,這就是經典的一像素邊框問題
核心思路,就是 在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有不一樣的處理。因此若是咱們把單位設置成小數的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); } } 複製代碼
如此,完美的解決一像素看着粗的問題
視口(viewport)表明當前可見的計算機圖形區域。在Web瀏覽器術語中,一般與瀏覽器窗口相同,但不包括瀏覽器的UI, 菜單欄等——即指你正在瀏覽的文檔的那一部分。
那麼在移動端如何配置視口呢? 簡單的一個meta標籤便可!
<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1; minimum-scale=1; user-scalable=no;"> 複製代碼
他們分別什麼含義呢?
咱們在移動端視口要想視覺效果和體驗好,那麼咱們的視口寬度必去無限接近理想視口
理想視口:通常來說,這個視口其實不是真是存在的,它對設備來講是一個最理想佈局視口尺寸,在用戶不進行手動縮放的狀況下,能夠將頁面理想地展現。那麼所謂的理想寬度就是瀏覽器(屏幕)的寬度了。
因而上述的meta設置,就是咱們的理想設置,他規定了咱們的視口寬度爲屏幕寬度,初始縮放比例爲1,就是初始時候咱們的視覺視口就是理想視口!
其中user-scalable設置爲no 能夠解決移動端點擊事件延遲問題(拓展)
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,這個用縮放來解決問題的方案是個過渡方案,註定時代所淘汰
vh、vw方案即將視覺視口寬度 window.innerWidth和視覺視口高度 window.innerHeight 等分爲 100 份。
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) }) ] } 複製代碼
之因此推薦使用此種方案,是因爲咱們要去考慮用戶的需求,用戶之因此去買大屏手機,不是爲了看到更大的字,而是爲了看到更多的內容,這樣直接使用px是最明智的方案,使用vw,rem等佈局手段無可厚非,可是,flex這種彈性佈局大行其道的今天,若是若是還用這種傳統的思惟去想問題顯然是有兩個緣由(我的認爲px是最好的,可能有大佬,能用vw,或者rem寫出精妙的佈局,也說不許):
一、爲了偷懶,不肯意去作每一個手機的適
二、不肯意去學習新的佈局方式,讓flex等先進的佈局和你擦肩而過
1. 在head 設置width=device-width的viewport‘
2. 在css中使用px
3. 在適當的場景使用flex佈局,或者配合vw進行自適應
4. 在跨設備類型的時候(pc <-> 手機 <-> 平板)使用媒體查詢
5. 在跨設備類型若是交互差別太大的狀況,考慮分開項目開發
疫情期間有了跳槽的想法,問到移動端佈局方面,雖然勉強能回答上來,可是老是支支吾吾,彷彿不是很瞭解,故而,發下宏願,梳理移動端適配,幫助後來人後來者居上!