Web页面适配移动端方案研究
源寶導讀：由于我們ERP目前大都是在在PC上面運行，大家現在關注移動端比較少，談到移動端適配時，可能都有些生疏也可能比較好奇。以前做過一些移動端的little項目，那么借助這次分享的機會，和大家一起討論學習下。
一、背景
? ? 現在市場上移動設備的屏幕尺寸、分辨率、屏幕密度等因素各式各樣，盡可能做到所有設備都自適應，只用一套樣式布局來適配所有設備。
二、適配最終效果
在不同分辨率的手機上，頁面整體布局自適應，不會出現頁面的情況；
在不同分辨率的手機上，字體、寬高、間距、圖片大小能夠和高保真近視一致。
三、移動端相關的知識點
3.1 關于設備
屏幕的像素：物理設備的顯示屏最小組成單位，又稱物理像素，是由物理設備決定的，出廠時就確定了；
屏幕的尺寸：屏幕對角線的長度，單位是英寸，1英寸（inch）=2.54厘米（cm）；
屏幕的分辨率：例如：1366px768px的分辨率，意思就是屏幕上橫向設置了768個像素，豎向設置了1366個像素。假設你調節分辨率為800600，那么多余的像素塊會被系統分配相鄰的近視色塊占據，看起來就放大了，也模糊了；
屏幕的密度：PPI為屏幕每英寸的像素數量，可以理解為一個屏幕對角線長度為1英寸的正方形內所擁有的像素數，用于度量計算機顯示屏上像素的密度。
公式：
3.2 關于編碼
css像素：是一個相對單位，用來度量web頁面上面的內容，與設備像素無關，在標準屏幕密度下，1px對應1個設備像素，但是在現在主流手機上1px并不等于設備的1px；
dpr：設備像素比，定義物理像素和設備虛擬像素（可以理解為css像素）的對應關系。可以通過js獲取，dpr = window.devicePixelRatio = 設備像素 / CSS像素。
上圖說明了1px在不同dpr時等于幾個物理像素。1px對應物理像素除了和屏幕像素密度dpr有關，還和用戶縮放有關系。當用戶把頁面放大一倍，那么CSS中1px所代表的物理像素也會增加一倍；
反之把頁面縮小一倍，CSS中1px所代表的物理像素也會減少一倍。所以一般會在頭部meta中禁止用戶縮放:user-scalable=’no’。
viewport：針對移動端的視口概念，大致了解下：
width=device-width：設置布局視口的大小等于設備獨立像素；
initial-scale=1.0：設置布局視口和視覺視口的大小等于設備獨立像素；
minimum-scale=1.0、maximum-scale=1.0、user-scalable=no：不允許用戶進行縮放；
布局視口（layout viewport）：不同設備的布局視口寬度不同，一般都大于可視區域，樣式布局可用大小，document.documentElement.clientWidth來獲取；
視覺視口（visual viewport）：用戶看到的網站展示區域，一般視覺視口和設備寬度一致。并且它的CSS像素的數量會隨著用戶縮放而改變，單位是px（CSS像素）；該值是可變的（縮放情況下），可以通過window.innerWidth獲取。
完美視口（ideal viewport）:理想寬度就是屏幕的寬度。
四、尋找適配方案的心路歷程
4.1 在手淘方案沒有出來之前，移動端適配其實是一大難題，起初嘗試的方案思路：
先根據高保真1：1實現；
再根據媒體查詢對應不同屏幕寬度、不同屏幕密度來實現細節調整，如：字體、圖片等。舉個圖片的栗子：
優點：
圖片資源會在對應寬度才會下載；
語法兼容性好；
可以根據不同屏幕精準控制。
缺點：
顯而易見，代碼非常冗余，維護不便；
不同尺寸設備細節實現效果不好；
擴展性很差，不可能針對所有類型的終端屏幕做到面面聚到。
4.2 為了解css代碼維護難問題，采用flex彈性布局來解決此問題
大致思路如下：
設置完美視口，設置布局視口等于可視；
結構性布局都是用flex彈性布局；
細節性margin和padding采用高保真px來布局；
怪異屏幕分辨率，使用媒體查詢來做細節調整；
不同屏幕密度、圖片、字體仍然采用媒體查詢來控制。
優點：
解決了部分響應式布局代碼冗長的問題；
易于維護。
缺點：
不能兼顧到細節布局，細節布局還是需要采用媒體查詢來適配；
felx語法版本太多，需要針對不同系統設備來兼容；
felx部分特性兼容性不好，例如：自動換行。
4.3 雖然解決了部分css代碼冗長問題，但是還是有不少地方需要借用的媒體查詢來做適配，并且還是有一些奇葩機型上，顯示細節達不到預想效果。無意間發現關于viewport知識點的文章，上面介紹一個思路能夠非常簡單實現適配
大致思路如下：
布局還是根據高保真1:1實現，例如：750px；
通過js代碼計算出750px對應的dpi和縮放，然后動態設置target-densitydpi=dpi，告訴瀏覽器這樣來渲染網頁；
圖片和字號用媒體查詢適配。
優點：
減少了不同屏幕密度屏幕媒體查詢的適配代碼；
不需要考慮某些機型的奇葩寬度，對比上一個方案自適應效果好。
缺點：
未來兼容性不好，target-densitydpi在安卓4.0之后就廢棄了；
圖片和字體仍然需要媒體查詢來適配；
布局細節仍然需要單獨處理。
4.4 動態設置html的font-size + rem + viewport
大概思路：
根據clientWidth和dpr動態設置font-size；
然后將其他地方根據高保真px轉換成rem；
字體通過媒體查詢適配 （小屏幕下面顯示跟大屏幕同等量的字體。并且如果使用rem的話，那么由于等比例的存在，在小屏幕下就會存在小屏幕字體更小的情況，不利于我們更好的去閱讀，所以，對于字體的適配，更好的做法就是使用px和媒體查詢來進行適配）。
? ? rem與px對應關系，1rem代表在JS中設置的html font-size值（為一塊的寬度），px對應占多少塊。
優點：
兼容性比較好；
css適配代碼少，易于維護。
缺點：
對于不同dpr處理細節較麻煩；
1px細節問；
rem小數點問題，最終css值都是四舍五入的，可能不精準。
4.5 手淘方案：rem + flexible庫
大致思路：
選擇一種尺寸作為設計和開發的基準；
定義一套適配規則，自動適配剩下的尺寸；
特殊適配效果單獨處理。
原理：flexible庫其實做了以下3件事：
動態改寫標簽，動態設置scale縮放比例；
給元素添加data-dpr屬性，并動態改寫data-dpr的值；
給元素添加font-size屬性，并且動態改寫font-size的值。
使用方式和注意事項：
引用flexible_css.js,flexible.js；
px轉化成rem，由于flexible庫將設計圖等分成10份，750px設計稿，相當于1rem=7.5px，可以借助less或者scss去轉換，獲取采用px2rem庫統一轉換，還可以利用插件，方式很多不一一列舉；
字號不用rem用px，通過[data-dpr=”2”]和[data-dpr=”3”]分開設置px單位的字體。同樣可以采用less或者sass處理；
利用[data-dpr=”2”] .test，處理不同dpr的場景。
優點：
css適配代碼量明顯減少；
開發效率高，有成套的解決方案；
1px、2px細節通過縮放方式能夠有效解決 。
缺點：
奇葩Android中dpr為小數情況，導致1px兼容場景兼容不好；
針對不同分辨率、1px、高DPR、倍圖等場景，都是通過Hack手段處理，而不是原生css處理，相比純css處理性能會差點。flexible2.0針對1px場景增加兼容。
4.6 vw + rem
為了解決純VW布局不能設置最大最小寬度的問題，我們引入REM。大致思路：
給根元素大小設置隨著視口變化而變化的 vw 單位，這樣就可以實現動態改變其大小;
限制根元素字體大小的最大最小值，配合 body 加上最大寬度和最小寬度.
優點：
省去js計算font-size、和縮放比例的問題；
原生css處理，性能更好。
缺點：
兼容性不好，ios8、android4.4以上才完全支持；
margin采用px單位，很容易造成整體寬度超過100vw。
五、思考
PC端的ERP是否也能做到完全自適應呢？
移動端盛行，ERP或者周邊生態是否會衍生移動端項目呢？待續…
------ END ------
作者簡介
羅同學：?研發工程師，目前負責ERP建模平臺的設計與開發工作。
也許您還想看
從案例角度解析建模平臺動態規則引擎
WEB頁面前端性能診斷方法與實踐
前端異步對象的原理與使用方法
鏈路追蹤在ERP系統中的應用實踐
總結
以上是生活随笔為你收集整理的Web页面适配移动端方案研究的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 为自己而活，这很难吗？
- 下一篇： .net core HttpClient