當前位置:首頁 » 網頁前端 » web移動端適配方案
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

web移動端適配方案

發布時間: 2023-06-20 07:44:37

1. 求教:移動端web頁面適配問題

之前默認使用的系統內置瀏覽器對象,去年應該已經在Android切換為第三方瀏覽器內核了。兼容性基本不用考慮,不需要考慮media
query了等等適配工作。基於參考要求,在任意一個終端上開發,在所有終端上都會有統一的展現。
基於em相對字體大小技術+屏幕DPI適配。

2. WEB二、移動端常見布局

目錄:2、流式布局 3、flex布局 4、rem適配布局-media 5.less

不管網頁的寬度怎麼調整,兩個div會分別佔50%的寬度:
但是注意這里設置了 最大寬度和最小寬度

效果圖:

一行三個盒子,兩邊的盒子大小固定不變,中間的盒子隨著窗口的大小而變化。

效果圖:

1、頁面布局文字能否隨著屏幕的大小變化而變化?
2、流式布局和flex布局主要針對於寬度布局,那高度如何設置?
3、怎麼樣讓屏幕發生變化的時候元素高度和寬度等比例縮放?

1、em單位例子:

2、rem單位例子:

當樣式比較繁多的時候,我們可以針對不同的媒體使用不同的stylesheets(樣式表)。
原理,就是直接在link中判斷設備的尺寸,然後引用不同的css文件。

css是一門非程序語言,沒有變數、函數、scope(作用域)等概念。

如下例子的缺點:

保存 less 文件 自動會生成css文件:

引入css文件:

3. 移動端H5頁面適配問題研究

剛開始做移動端web開發的同學應該都碰到過頁面適配問題,為什麼我在開發手機上調試好的頁面在其他手機會有這樣或那樣的樣式問題? viewport 我也設置了,為什麼還是顯示不正常?難道我要為每種手機屏幕寫媒體查詢,有沒有簡單的方式,可以不用關注手機屏幕的差異性呢?

網路中搜索 移動端H5頁面適配 關鍵字,大概可以得到180多萬的搜索結果,由此可見這個問題也得到很多人的關注。本文的目的主要是分析解決移動端H5頁面適配問題過程中牽扯到的知識點,然後梳理分析目前常見的適配解決方案。

由於本文內容較長,下面先給出文章的提綱:

1.1理解移動端單位
1.2理解viewport

2.1圖片高清適配
2.2字體大小適配
2.3布局寬度適配

---這里是分隔符,正文開始---

不知道正在看文章的你對上面列出來的這些單位是不是很熟悉,如果是的話,就可以跳過了。

理解這些單位的用法以及區別,對理解移動端頁面適配有很大的幫助。為了讓你對上面的單位有個大體的認知,這里把上面的單位分成了三類:

下面分別對每個單位展開分析:

*** dpi / ppi ***

** dpi ** , dot per inch ,每英寸的點數;列印或印刷領域使用的單位,代表列印機每英寸可以列印出的點數 。

ppi , pixel per inch ,每英寸的像素數,像素密度;表示圖像或者顯示器單位面積上像素數量。

dpi 和 ppi 都是描述解析度的單位,但是兩者是有區別的,但是在描述手機解析度時,可以認為兩者意義相同,以前android設備偏向於使用 dpi ,ios設備偏向於使用 ppi ,目前android和ios統一使用 ppi 描述手機屏幕的像素顯示密度。

ppi的計算方法:

*** ldpi、mdpi、hdpi、xhdpi、xxhdpi ***

android對移動設備不同屏幕解析度的分類。

*** pt,pc,sp ***

** pt ** ,磅(point的音譯),印刷中使用的表示字型的大小單位,1inch = 72pt (印刷中這個關系成立,ios中不成立),ios開發中使用的邏輯單位,是和設備無關的單位。

** pc ** 印刷中使用的單位,1pc = 12pt,不需要關注。

** sp **, scale independent pixel ,android設備中用來顯示字體大小的,和設備無關的尺寸,當設置字體大小單位為sp時,android系統字體大小會影響設置的字體渲染時的大小。

*** dip / dp ***

** dp/dip**, device independent pixel,表示設備獨立像素,和設備無關的尺寸,相同的dp/dip值,不同設備展示的效果是一樣的。

android使用的單位,之前偏向使用dip,目前建議使用dp。

android設備中,規定160ppi的屏幕,1dp = 1px;320ppi的屏幕,1dp = 2px,所以android設備中dp的計算方法:dp = px * (ppi / 160),這里的px是指設備的物理像素點。

和ios開發中用的pt單位類似。

*** px ***

** px ** ,像素,有兩種像素概念,一種是網頁設計中使用的css像素,一種是原生移動系統使用的物理像素。

作為css像素時,表示的也是一種設備無關單位,與android中使用的dp類似,默認情況下與系統解析度下的像素大小相同,標清設備中,一個css像素和一個設備物理像素大小相同;在高清設備中,一個css像素可以大於或者等於多個設備物理像素,具體一個css像素,需要多少個物理像素來展示,瀏覽器會根據dpr計算。

原生移動系統中使用px單位時,表示的就是屏幕的物理像素點,每種屏幕的物理像素點大小可能不一樣。

*** dpr ***

** dpr ** ,device pixel ratio, 橫向或者縱向設備物理像素數量與設備獨立像素數量的比值,瀏覽器中可以通過window.devicePixelRatio獲取(存在兼容性問題)。

對於原生app,ios和android系統會自動根據dpr計算出渲染時需要的px值,最終不同屏幕上展示出來的大小很接近;而移動端頁面渲染時想要做到這一點,就必須首先得到設備的dpr,然後再根據dpr計算渲染需要的px值。

ios設備中iphone3的dpr為1;iphone4,5,6,7的dpr為2;iphone6+,7+的dpr為3。iphone6+和iphone7+實際計算出來的dpr應該時2.6左右,但是官方還是建議dpr為3,這是因為ios系統利用了一種「縮減像素采樣」演算法,自動縮減到2.6。

android設備中dpr值有多種,可知的有0.75,1,1.5,1.75,2,2.5,2.75,3,4等。

*** em,rem ***

** em ** 相對單位,CSS2引入的單位,作為字體大小使用時和百分比單位類似,都是相對於最近的父元素設置的字體大小,在body上設置字體大小為100%和設置字體大小為1em是一樣的效果,默認情況下瀏覽器的字體大小為16px,這樣只要瀏覽器默認得字體大小不變,1em = 16px。

** rem ** 相對單位,root em,CSS3新增的單位,作用和em類似,唯一的區別就是em是相對父元素的,rem是相對html根節點的,即所有使用rem單位的子元素的字體大小都是相對根節點的,所以使用rem可以避免使用em帶來的子元素字體大小逐層復合的連鎖反應。

更多關於em,rem的知識參見這篇文章 理解web開發中的em單位和rem單位 。

*** 解析度 ***

平時說的手機屏幕解析度,也稱為物理解析度或者原生解析度,通常包括縱向解析度和橫向解析度,例如iphone6的物理解析度是1334 x 750,其中縱向解析度是1334px,橫向解析度是750px,表示縱向方向可以顯示1334個物理像素點,橫向上可以顯示750個物理像素點,這里描述解析度使用的px單位,和css中使用的px單位意義不一樣,這里代指物理設備的像素點。

還有一種解析度叫做系統解析度,例如iphone6的系統解析度是667 x 375,其中高度是667pt,寬度是375pt,這里描述解析度使用了pt單位,是一種設備無關單位。

屏幕尺寸相同的設備,物理解析度越高,ppi也就越大,絕對單位面積上展示的物理像素數量越多,展示圖片也就越細膩。

蘋果把ppi > 300的屏幕稱為視網膜屏,Retina屏。

傳統桌面web頁面布局通常是定寬布局,但是定寬布局的方式對移動端卻不適用,原因手機屏幕尺寸大小各異,定寬布局可能在某些手機上出現橫向滾動條,導致閱讀效果比較差。

為了讓手機有更好的網頁瀏覽體驗,蘋果引入了viewport,為頁面提供了一個虛擬的布局窗口,在這個虛擬的布局窗口中渲染頁面,然後系統會把渲染好的頁面自動縮放到手機屏幕大小。

雖然viewport還沒有成為正式的規范,但是現在絕大部分瀏覽器都支持viewport。

在桌面瀏覽器中,viewport嚴格等於瀏覽器窗口大小,頁面渲染時,頁面寬度不會超過瀏覽器的寬度。

移動端屏幕太窄,為了提供更好的頁面體驗,移動端提供了兩種viewport: 可視viewport 布局viewport

可視viewport 就是當前屏幕正在展示的區域,也就是移動設備屏幕的寬度,寬高通過window.innerWidth和window.innerHeight獲取(存在兼容性問題)。

布局viewport ,頁面布局實際用到的viewport,通常比可視viewport要寬,寬高通過document.documentElement.clientWidth和document.documentElement.clientHeight獲取。

移動端還有一種viewport概念,可以理解為 理想viewport ,作用就是在理想viewport下,不同移動設備,展示的字體大小接近,並且不需要用戶縮放就可以展示全部的頁面內容。

理想viewport的寬度默認等於可視viewport的寬度,但是對同一台設備來說,這個理想viewport的寬度是可以改變的,而可視viewport的寬度是不可變的。

如何使用理想viewport來布局頁面呢?只需要設置viewport的width等於device-width。

viewport的屬性,推薦使用以及支持度較廣泛的屬性只有6個: width , height , initial-scale , maximum-scale , minimum-scale , user-scalable 。

width 設置viewport布局寬度,內核是webkit的瀏覽器默認值是980px,取值范圍在200-10000px,也可以取值為設備寬度device-width(等於橫向設備無關像素數量)。

height 設置viewport布局高度,默認值依賴設備長寬比以及寬度值,取值范圍在223-10000px,也可以取值為設備高度device-height。

initial-scale 設置初始縮放比例,頁面第一次載入時的縮放比例。默認比例依賴於顯示密度。在密度低於200 dpi的顯示設備上,比例為1.0。在密度介於200及300 dpi之間的顯示設備上,比例為1.5。對於具有300 dpi以上密度的顯示設備,比例為密度/150 dpi向下取整的結果。取值范圍由 maximum-scale 屬性以及 minimum-scale 屬性決定。如果設置 initial-scale 值為1, width 默認是device-width, height 默認是device-height

initial-scale 設置的縮放大小會改變理想viewport的大小,不會改變可視viewport的大小,也不會改變布局viewport的大小,這是某些適配方案依賴的基本原理,也是解決 1px問題 的關鍵。後面分析適配方案時,動態viewport適配方案就依賴這個知識點。

maximum-scale 允許用戶縮放到的最大比例,默認值是0.5,范圍從0到10.0。

minimum-scale 允許用戶縮放到的最小比例,默認值是5.0,范圍從0到10.0。

user-scalable 用戶是否可以手動縮放,值可以是:yes/true允許用戶縮放;no/false不允許用戶縮放。

圖片適配的目的是為了在頁面中可以高清還原設計圖中用到的圖片。

頁面中用到的圖片是否清晰和展示頁面的硬體設備的dpr以及圖片解析度這兩個因素有關,下面會通過三個例子來說明這個問題。

***示例一 ***

例如dpr=2的設備,1個設備無關像素(android中的1dp,ios中的1pt)需要4個設備物理像素點填充。對於尺寸為100 x 120 (px)的圖片,如果用 <img> 來展示,圖片顯示時會產生模糊現象。

原因:渲染圖片時,寬度是100px,所以橫向會佔用100個設備無關像素,高度是120px,所以縱向會佔用120個設備無關像素,每個設備無關像素又需要2x2個物理像素點來填充,而圖片在每個設備無關像素(px)單位上提供的像素點只有1x1個,這時,系統通過一定的演算法在這1個像素點上就近取色,取到4個顏色(這4種顏色接近但是有一定區別)之後,當成4個像素點,然後填充到1個設備無關像素點上,這樣就導致圖片顯示時模糊,dpr越大,這種方式顯示的圖片越模糊。

示例二

還是dpr=2的設備,但是准備了一個尺寸為200 x 240 (px)的圖片,還是用 <img> 來展示,這時顯示的圖片就比較清晰了。

原因:這時圖片本身可以在一個設備無關像素單位上提供2x2個物理像素點,設備展示圖片時直接拿圖片提供的像素點來填充就可以了,不用對像素點進行處理,所以可以比較清晰的顯示圖片。

示例三

還是dpr=2的設備,這次准備一個尺寸400 x 480 (px)的圖片,還是用 <img> 來展示時,這種情況展示的圖片缺少銳利度,也影響了圖片的清晰度,但是很難看出來。

原因:圖片本身在一個設備無關像素點單位上提供了4x4個物理像素點,而設備本身只需要2x2個物理像素點,所以會通過縮減采樣演算法,在圖片提供的4x4個物理像素點中,選取顏色接近的2x2個物理像素點填充到設備無關像素點上,所以也會產生一定的色差,這種情況下圖片尺寸越大,這種色差也就越明顯,但是人眼很難區分這種色差。

下面是我在oppo的一款手機上的測試結果,結合這張效果圖就可以很好的理解上面的三個示例了:

圖片適配最佳實踐

要想高清顯示圖片,如果條件允許(有單獨的圖片伺服器)最直接的解決辦法,肯定是根據設備的dpr,為不同dpr的設備載入不同倍率大小圖片顯示;沒這種條件的或者對用戶體驗沒有很高要求的,只能選一種折中的方案了,一般情況下只需要提供布局尺寸2倍大小的切圖就可以了,也就是只高清適配dpr=2的設備,但是dpr為3或者4的設備展示效果也能接受,不容易看出來模糊現象。目前主流機型的dpr也就在2和3之間。

字體適配目標主要還是看設計要求,主要有兩種:

1.不同屏幕下,字體顯示大小都一樣,即需要等寬顯示字體;

2.不同屏幕下,一行能顯示的字數固定,即需要按比例縮放字體大小;

開始分析之前,先看下這兩種字體適配的示例:

第1種字體適配方案的示例

第2種字體適配方案的示例

下面就來具體分析下兩種字體適配方案的原理以及優劣。

** 第1種字體適配方案原理 **

在開始分析這種方式的原理之前,先通過一張圖理解下px和dp以及絕對長度之間關系。

由上圖可知字體大小隻與css單位px有關,而每個設備上px的絕對寬度又和設備的絕對寬度以及絕對寬度上劃分出的設備無關像素點dp有關;只要設備的橫向dp數量與絕對寬度的比值(dp/cm)相同,就可以保證px在不同設備上展示的絕對寬度是一樣的;如果dp/cm的比值過大,那麼px的絕對長度就會變小,看起來就會顯小;如果dp/cm的比值過小,那麼px的絕對長度就會變大,看起來就會顯大;一般來說手機屏幕解析度越高,相同px值的字體看起來就會越小。

iphone5和6的dp/cm比值十分接近,所以12px大小的字體在這兩種手機上顯示的大小基本一樣,看不出來區別,但是iphone6+的dp/cm比值要比iphone5,6的略大,這就導致12px大小的字體在6+上顯示的比5,6上顯示的略小,上面的淘寶對比圖仔細分辨可以看出來。

android的手機屏幕dp/cm比值在各個設備之間也有差異性,並且比較有多樣性。所以同樣12px大小的字體,各個設備顯示時也是有差別的。

這種顯示差別在iphone系列手機中可以忽略不計,但是android碎片化比較嚴重,完美兼容各種機型沒有必要,主流機型中這種顯示差別也可以忽略不計,所以採用這種方式進行字體適配只需要px值設置成一樣的就可以了。

** 第1種字體適配方案優缺點**

優點:1.不同設備中字體大小顯示一致,比較統一;2.大屏手機可以顯示更多的文字;

缺點:1.由於單個字體寬度是定死的,所以在有些機型下可能會影響頁面布局;

** 第2種字體適配方案原理 **

在設計稿中,計算出字體大小相對於基準字體大小(基準字體大小可以選擇設計稿寬度,一般為了計算方便,會把設計稿寬度/10得到的值作為基準字體大小)的比值,然後在不同布局寬度下,先得到基準字體大小,再根據上面計算出來的比值,就可以計算出來不同布局寬度下的字體大小,也就是不同布局寬度下等比例縮放字體。

利用rem的特性,在頁面的html標簽上設置一個基準字體大小,就可以實現這種方式。

例如,寬是750px的設計圖中,字體大小是32px,計算出基準字體大小為75px,比值為 32 * 10 / 75 = 0.426667。

如果布局寬度是414px,此時基準字體大小變成 414 / 10 = 41.4px,然後設置<html style="font-size:41.4px">,字體大小是0.426667rem,計算出來的字體大小為41.4x0.42667=17.66px。

如果布局寬度變成360px,此時基準字體大小變成36px,然後設置<html style="font-size:36px">,字體大小仍然用0.426667rem表示,計算出來的字體大小為36x0.42667=15.36px。

750/32 約等於 414/17.66 約等於 360/15.36,這樣就做到了等比縮放字體了。

** 第2種字體適配方案優缺點**

缺點:1.小尺寸設備屏幕上字體顯示小,大尺寸設備屏幕字體顯示大,導致字體顯示不一致;2.不能發揮大屏手機的優勢(顯示更多的字);3.字體大小會出現奇數或者小數點大小的值,某些字體不支持這些值,渲染時增加計算量;

優點:1.適配簡單,不同設備不會影響頁面布局,可以和設計稿布局保持一致;

布局中對寬度的適配,也是採用rem來實現,和上面第2種字體大小適配方式中的原理類似,也是計算出一個比例值,然後不同布局寬度中等比縮放,這里偷下懶,不在贅述。

目前的解決方案有兩類

第一類就是js動態生成viewport標簽,標簽中的initial-scale值根據設備的dpr計算,不同dpr設備的viewport值不同。

第二類就是js不操作viewport,每個設備都使用理想viewport來布局。

** 動態viewport解決方案分析 **

這里分析兩個動態viewport解決方案:

1.手機淘寶的flexible方案;
2.hotcss方案;

手機淘寶的flexible方案 ,特點:

1.僅針對iphone生成動態viewport,因為目前iphone的dpr只有1,2,3三種,android的dpr很有多種,不具有一致性;

2.字體大小不用rem做縮放處理,仍然使用px單位,設置不同dpr下對應的字體大小;

3.寬度利用rem等比縮放;

4.允許強制定義dpr;

使用時頁面頭部需要引入 flexible.js .

hotcss方案 ,特點:

1.不區分iphone和android,dpr只取三種1,2,3,android的dpr做近似處理;

2.寬度以及字體利用rem等比縮放;

3.允許強制定義dpr;

使用時頁面頭部需要引入 hotcss.js

動態viewport方案之所以會稱為動態viewport是因為,這個適配過程會根據系統dpr值設置initial-scale屬性的大小,大小等於1/dpr。

** 靜態viewport解決方案分析 **

利用rem特性,先根據標注圖算出各元素相對於設計稿寬度的比值,這個比值就作為rem值,然後頁面布局時就用算出的rem值表示,並且在html根元素設置當前布局頁面寬度作為基準。更rem值計算具體的解釋可以參考這篇文章 使用Flexible實現手淘H5頁面的終端適配 。通過這種方式設置標簽元素的寬高,位置以及字體大小,這樣利用rem特性就可以在不同手機屏幕上實現等比縮放。

參考資料
https://github.com/amfe/article/issues/17
http://www.cnblogs.com/pigtail/archive/2013/03/15/2961631.html

4. 在移動端 web怎麼做到自適應布局

css3用box-flex;在w3school里找找,主要是根據父元素按比例分配高度父元素{width:100%;display:box;}比如三欄布局A、B、C要想設成一樣的寬度就用A{box-flex:1;}B{box-flex:1;}C{box-flex:1;}要是兩欄布局B是A的2倍那就是A{box-flex:1;}B{box-flex:2;}高度也是還有一個css3的新功能就是calc()計算,可以計算高度,可以試著用一下PS,我只是說說,移動端響應式局的話,布局要隨著窗口變的,就像你這個,要是在普通的手機端就得變成一欄布局,不能保持三欄用MediaQuery設置不同的窗口寬度給不同的css樣式都是css代碼不用js控制

5. 移動web終端 viewport設置

移動web,顧名思義就是在移動端的web頁面,比如我們可以在手機的UC瀏覽器中訪問淘寶等網站:

可以發現淘寶的移動web版本和pc上web版本有很大的不同,在移動web版本中更像是模擬了native應用中的頁面。所以移動web的開發和pc上web的開發肯定也是有很大的不同。

先看正常的pc上web頁面在移動設備上的展示:

從上圖可以看出,正常PC上的網頁在移動設備被縮放了,這樣對於商城購物類的網站來說,用戶體驗非常差,所以就更應該要有適配移動設備的頁面了。

那麼究竟是怎樣適配移動端的頁面呢?答案就是viewport,可以將viewport理解為瀏覽器中用來承載網頁的那一層。默認情況下移動設備上瀏覽器會自動將viewport的值設置為980px或者1024px,不過手機的屏幕沒有那麼大,這時候網頁就縮放了。

到這里,web適配移動設備的方案就出來,讓viewport=手機的寬度就好了。是的,正常情況下都是這么用的:

在meta標簽中設置viewport的寬度為設備的寬度, initial-scale=1 的意思是頁面的縮放比例為1, user-scalable=no 的意思是禁止用戶縮放頁面, minimum-scale=1,maximum-scale=1 的意思是設置用戶的最大最小縮放比,當設置了 user-scalable=no 之後這兩個屬性值就沒有意義了。

以上就是viewport的主流設置,不錯淘寶(m.taobao.com)就是非主流的設置,淘寶的移動web頁面中viewport沒有設置寬度:

所以淘寶的viewport的width應該是用js動態獲取的。

6. 移動 WEB 如何適配千奇百怪的解析度

在移動端存在各式各樣的解析度,移動端網頁就會面對很復雜的兼容問題,並非是兼容系統,而是要保證頁面在不同解析度網頁當中效果的一致性。


對於這種問題,其實還是比較好解決的,橫向採用百分比,就能夠實現內容隨著設備寬度大小的變化而變化的需求。


比較難解決的問題是縱向上的高度問題,相信你也使用過百分比去嘗試解決,但是如果高度採用百分比,盒模型中padding、margin等屬性的計算方式有些特殊,這也就導致縱向不能夠使用百分比。(對於這方面如果希望了解,可以在一個叫「HTML5學堂」的網站當中查看,裡面有非常詳細和清晰的講解,在此我就不再重復書寫了)


這樣的現狀就導致縱向需要使用其他單位來解決,於是就會使用到CSS3當中一個新的單位,rem。

rem是一個相對度量單位,是針對html標簽的字體大小來計算的。如果html標簽的字體大小為16px,那麼1rem就是16px,如果html標簽的字體大小是20px,那麼1rem就是20px。


橫向使用百分比,縱向使用rem,之後用JS去獲取當前設備寬度,並根據設備寬度、設計圖寬度、設計圖基準字體大小,通過JS計算出當前設備下html文件的font-size(基準字體大小),就是適配移動端各個解析度設備的方法。


給出JS代碼作為參考,不過,這個JS是基於JQ的:


這個裡面設計圖是640的,設計圖中最小字體是24像素。所以,當你進行開發時,如上這段代碼當中的幾個數字,也要根據設計圖的具體值而調整。

7. VUE移動端及PC端適配方案

前幾天開發公司產品官網的時候,遇到了一些適配問題,當時選擇用postcss-px-to-viewport方案來實現適配,效果也很顯著,每個頁面都適配到位

step1. vue安裝postcss-px-to-viewport插件。

step2. 配置適配升磨念插件的參數

使用PostCss配置文件時,在<u>postcss.config.js</u>添加如下配置:

或者在<u>package.json</u>中,添加以下配置:

說明下幾個重要參數的使用:

適配存在的問題點:

註:執行指令後在package.json的devDependencies分支可以看到吵困相應的版本,

2. 在main.js中導入lib-fixible.

如果未使用游羨vue的夥伴可以直接在前端中直接使用阿里的CDN,如下:

註:此處是postcss-px2rem而不是px2rem-loader,網上很多文章都引用是後者,會導致在配置時候無法成功配置。
在vue.config.js中配置如下配置即可,如未有此文件請自行搜索查詢創建配置。

集成以上兩個步驟,基本前端即可根據屏幕自行適配,但可能有部分夥伴會遇到data-dpr始終為1,遇到這個情況多半是因為在html頭中自己設置了<meta name="viewport" ...>,

查看lib-flexble做了配置,默認會根據屏幕為我們添加頭文件的,如果自行設置,那麼只會進行修改設置的值而已,並不會再添加,所以導致data-dpr始終為1,所以把<metaname="viewport" ...>去除.