再聊移動端頁面的適配

時間 2019-12-18

標籤移動頁面適配欄目無線简体版

原文原文鏈接

再聊移動端頁面的適配

前端圈真亂，這話一點不假。但亂也亂的好處，亂則生變，有變化纔有進步。今天仍是老調重談，聊聊移動端頁面的適配。由於對於一枚前端而言，每天和頁面打交道（H5頁面），那麼佈局的活老是少不了，這也將面臨不一樣終端的適配問題。不知道你是否和我同樣，頁面佈局老是或多或少會有一些蛋疼的事情發生。若是是的話，建議你花點時間閱讀完下面我扯蛋的東東。css

Flexible承載的使命

Flexible到今天也有幾年的歷史了，解救了不少同窗針對於H5頁面佈局的適配問題。而這套方案也相對而言是一個較爲成熟的方案。簡單的回憶一下，當初爲了能讓頁面更好的適配各類不一樣的終端，經過Hack手段來根據設備的dpr值相應改變<meta>標籤中viewport的值：html

從而讓頁面達麼縮放的效果，也變相的實現頁面的適配功能。而其主要的思想有三點：前端

根據dpr的值來修改viewport實現1px的線
根據dpr的值來修改html的font-size，從而使用rem實現等比縮放
使用Hack手段用rem模擬vw特性

有關於Flexible方案實現適配，在2015年雙十一以後作過這方面的技術文檔分享，感興趣的同窗能夠移步閱讀《使用Flexible實現手淘H5頁面的終端適配》一文。雖然Flexible解決了適配終端不少問題，但它並非萬能的，也不是最優秀的，他仍是存在一些問題的，好比iframe的引用，有時候就把咱們本身給埋進去了。針對其中的一些不足之處，有些同窗對其進行過相關的改造，在網上搜索能找到相關的方案。css3

那麼時代在變化，前端技術在不斷的變化，試問：Flexible仍是最佳方案？Flexible還有存在的必要嗎？ 最近一直在探討這方面，這裏先告訴你們Flexible已經完成了他自身的歷史使命，咱們能夠放下Flexible，擁抱新的變化。接下來的內容，我將分享一下我最近本身探討的新的適配方案，或許不少團隊同窗已經開始使用了，若是有不對之處，但願能獲得大嬸們的指正；若是您有更好的方案，但願能一塊兒分享一塊兒探討。瀏覽器

先上菜，再嘮嗑

先上個二維碼：svg

你可使用手淘App、優酷APP、各終端自帶的瀏覽器、UC瀏覽器、QQ瀏覽器、Safari瀏覽器和Chrome瀏覽器掃描上面的二維碼，您看到相應的效果：函數

iPhone系列效果工具

部分Android效果佈局

注：若是掃上面的二維碼沒有任何效果，你能夠點擊這裏，打開在線頁面，從新生成你的設備能識別的二維碼號。post

上面的Demo，測試了Top30的機型。目前未獲得支持的：

Top30機型中不在列表中的，將看到的效果如上圖所示。至於敢不敢用，這就得看親了。必竟第一個吃螃蟹的人是須要必定的勇氣！(^_^)

適配方案

前面給你們介紹了這個方案目前獲得的支持狀況以及效果。也扯了很多廢話，接下來進入正題吧。

在移動端佈局，咱們須要面對兩個最爲重要的問題：

各終端下的適配問題
Retina屏的細節處理

不一樣的終端，咱們面對的屏幕分辨率、DPR、1px、2x圖等一系列的問題。那麼這個佈局方案也是針對性的解決這些問題，只不過解決這些問題再也不是使用Hack手段來處理，而是直接使用原生的CSS技術來處理的。

適配終端

首要解決的是適配終端。回想一下，之前的Flexible方案是經過JavaScript來模擬vw的特性，那麼到今天爲止，vw已經獲得了衆多瀏覽器的支持，也就是說，能夠直接考慮將vw單位運用於咱們的適配佈局中。

衆所周知，vw是基於Viewport視窗的長度單位，這裏的視窗（Viewport）指的就是瀏覽器可視化的區域，而這個可視區域是window.innerWidth/window.innerHeight的大小。用下圖簡單的來示意一下：

由於Viewport涉及到的知識點不少，要介紹清楚這方面的知識，都須要幾篇文章來進行闡述。@PPK大神有兩篇文章詳細介紹了這方面的知識。中文能夠移步這裏進行閱讀。

在CSS Values and Units Module Level 3中和Viewport相關的單位有四個，分別爲vw、vh、vmin和vmax。

vw：是Viewport's width的簡寫,1vw等於window.innerWidth的1%
vh：和vw相似，是Viewport's height的簡寫，1vh等於window.innerHeihgt的1%
vmin：vmin的值是當前vw和vh中較小的值
vmax：vmax的值是當前vw和vh中較大的值

vmin和vmax是根據Viewport中長度偏大的那個維度值計算出來的，若是window.innerHeight > window.innerWidth則vmin取百分之一的window.innerWidth，vmax取百分之一的window.innerHeight計算。

仍是用一張圖來示意吧，一圖勝於千言萬語：

因此在這個方案中大膽的使用vw來替代之前Flexible中的rem縮放方案。先來回歸到咱們的實際業務中來。目前出視覺設計稿，咱們都是使用750px寬度的，從上面的原理來看，那麼100vw = 750px，即1vw = 7.5px。那麼咱們能夠根據設計圖上的px值直接轉換成對應的vw值。看到這裏，不少同窗開始感到崩潰，又要計算，能不能簡便一點，能不能再簡單一點，實際上是能夠的，咱們可使用PostCSS的插件postcss-px-to-viewport，讓咱們能夠直接在代碼中寫px，好比：

PostCSS編譯以後就是咱們所須要的帶vw代碼：

在實際使用的時候，你能夠對該插件進行相關的參數配置：

假設你的設計稿不是750px而是1125px，那麼你就能夠修改vewportWidth的值。有關於該插件的詳細介紹，能夠閱讀其官方使用文檔。

上面解決了px到vw的轉換計算。那麼在哪些地方可使用vw來適配咱們的頁面。根據相關的測試：

容器適配，可使用vw
文本的適配，可使用vw
大於1px的邊框、圓角、陰影均可以使用vw
內距和外距，可使用vw

另外有一個細節須要特別的提出，好比咱們有一個這樣的設計：

若是咱們直接使用：

最終的效果會形成[w-187-246]容器的高度小於[w-188-246]容器的高度。這個時候咱們就須要考慮到容器的長寬比縮放。這方面的方案不少，但我仍是推薦工具化來處理，這裏推薦@一絲姐姐寫的一個PostCSS插件postcss-aspect-ratio-mini。這個插件使用很簡單，不須要作任何的配置，你只須要本地安裝一下就OK。使用的時候以下：

編譯出來：

這樣就能夠完美的實現長寬比的效果。有關於這方面的原理在這裏不作過多闡述，感興趣的話能夠閱讀早前整理的文章:

CSS實現長寬比的幾種方案
容器長寬比
Web中如何實現縱橫比
實現精準的流體排版原理

目前採用PostCSS插件只是一個過渡階段，在未來咱們能夠直接在CSS中使用aspect-ratio屬性來實現長寬比。

解決`1px`方案

前面提到過，對於1px是不建議將其轉換成對應的vw單位的，但在Retina下，咱們始終是須要面對如何解決1px的問題。在《再談Retina下1px的解決方案》文章中提供了多種解決1px的方案。在這裏的話，我的推薦另一種解決1px的方案。依舊是使用PostCSS插件，解決1px可使用postcss-write-svg。

使用postcss-write-svg你能夠經過border-image或者background-image兩種方式來處理。好比：

這樣PostCSS會自動幫你把CSS編譯出來：

使用PostCSS的插件是否是比咱們修改圖片要來得簡單與方便。

上面演示的是使用border-image方式，除此以外還可使用background-image來實現。好比：

編譯出來就是：

這個方案簡單易用，是我所須要的。目前測試下來，基本能達到我所須要的需求。但有一點千萬別忘了，記得在<head>中添加：

上面闡述的是這個適配方案中所用到的技術點，簡單的總結一下：

使用vw來實現頁面的適配，而且經過PostCSS的插件postcss-px-to-viewport把px轉換成vw。這樣的好處是，咱們在擼碼的時候，不須要進行任何的計算，你只須要根據設計圖寫px單位
爲了更好的實現長寬比，特別是針對於img、vedio和iframe元素，經過PostCSS插件postcss-aspect-ratio-mini來實現，在實際使用中，只須要把對應的寬和高寫進去便可
爲了解決1px的問題，使用PostCSS插件postcss-write-svg,自動生成border-image或者background-image的圖片

這裏使用了多個PostCSS的插件，其實如今有不少優秀的PostCSS插件能幫助咱們解決不少問題。哪果你從未接觸過有關於PostCSS相關的知識，建議你能夠花點時間去學習一下，在W3cplus提供了一些有關於PostCSS相關的文章。若是你想系統的學習PostCSS相關的知識，推薦你購買《深刻PostCSS Web設計》一書：

降級處理

最開始提到過，到目前爲止，T30的機型中還有幾款機型是不支持vw的適配方案。那麼若是業務須要，應該怎麼處理呢？有兩種方式能夠進行降級處理：

CSS Houdini：經過CSS Houdini針對vw作處理，調用CSS Typed OM Level1 提供的CSSUnitValue API。
CSS Polyfill：經過相應的Polyfill作相應的處理，目前針對於vw單位的Polyfill主要有：vminpoly、Viewport Units Buggyfill、vunits.js和Modernizr。我的推薦採用Viewport Units Buggyfill

Viewport不足之處

採用vw來作適配處理並非只有好處沒有任何缺點。有一些細節之處仍是存在必定的缺陷的。好比當容器使用vw單位，margin採用px單位時，很容易形成總體寬度超過100vw，從而影響佈局效果。對於相似這樣的現象，咱們能夠採用相關的技術進行規避。好比將margin換成padding，而且配合box-sizing。只不過這不是最佳方案，隨着未來瀏覽器或者應用自身的Webview對calc()函數的支持以後，碰到vw和px混合使用的時候，能夠結合calc()函數一塊兒使用，這樣就能夠完美的解決。