rem, vw, 仍是...? 各憑本事的移動端適配方案

前言

2018年最後的法定假期都已經結束了,我相信大部分正在進行或曾經進行過移動端頁面開發的同窗都或多或少的瞭解過使用rem進行移動端頁面適配的方案以及使用vw的方案,(沒了解過的同窗能夠參見大漠老師的這兩篇文章 使用Flexible實現手淘H5頁面的終端適配再聊移動端頁面的適配)也面臨過在不一樣適配方案間進行抉擇的思考,我我的最近對於移動端適配方案也進行了一輪從新的研究,期間,對各類適配方案也有一些本身的看法,正好記錄下來與你們一塊兒分享。css

vw與rem方案中的一些思考

因此,移動端適配 = vw or rem ?

固然不是。並非全部場景下的移動端頁面都適合採用vw或rem的方案,這類方案的本質是佈局等比例的縮放,讓頁面在不一樣尺寸的屏幕下有相似於矢量圖片縮放的效果,即保證頁面各元素之間位置尺寸的比例關係,並讓元素能夠清晰地展示。 這樣的方案更適合於視覺組件種類較多,視覺設計對元素位置的相對關係依賴較強的移動端頁面。其實大部分頁面均可以使用rem或vw的方案進行適配,但對於文本內容較多,或者說但願引導用戶沉浸瀏覽的頁面,我我的並不推薦使用等比縮放的方案,至少並不推薦徹底使用等比縮放的方案,對於文本內容仍是應該直接使用px這種絕對長度單位,畢竟在大屏手機上用戶但願看到的是更多的內容而不是更大的內容。實際上不少這類的網站也確實是直接使用px結合flex等佈局方式進行移動端適配的,這個在後面討論具體技術方案的時候我會舉幾個例子。html

rem方案到底在作什麼?

在各類rem適配方案的實現中,有兩個核心的點前端

  • 設置<meta name="viewport" content="xxx">(能夠根據dpr縮放viewport,也能夠直接使用1倍的視口大小)
  • 根據當前佈局的寬度(一般是viewport寬度, 也能夠是被限制的最大/最小布局寬度)來設置html元素的font-size

以前我已經提到過,vw和rem的方案的本質都是「等比例縮放」,由於vw和rem都是相對長度單位(relative length unit),能夠很好的知足這個需求。區別是vw是viewport width的1%,而rem是html元素的font-size。當咱們讓html元素的font-size與viewport width產生了關聯後,rem就能夠模擬出使用vw進行佈局的效果了。因此在rem方案中,咱們只是在把rem當作是vw的影子。寫做rem,讀做vw...(劇情彷佛狗血起來了... rem: 固然是選擇原諒大家啊) html5

我rem有話說

那直接用vw不就完事兒了嗎?

且慢
且慢,當初之因此使用rem的方案流行開來正是由於在那時viewport units的瀏覽器支持程度不甚理想(IOS 8+, Android 4.4+ 參見viewport units的 caniuse)。而相比較之下rem就好多了(IOS 4.1+, Android 2.1+ 參見 caniuse),因此對於vw,在當時的大環境下前端想說愛你不容易。

我想這時候有人要說了:「醒醒兄弟 已經8102年了!」 是的,8102年都快要過去了,對於兼容性要求不是特別高的狀況下vw也算是能夠見天日了,而且也有一些針對vw的補丁方案,但還有一個問題咱們要稍微討論一下...git

vw能夠徹底替代rem嗎?

回答依舊是否認的。單純使用vw進行佈局不能限制佈局的寬度,對於有這個需求的場景至少仍是須要將vw和rem混用來處理邊界狀況。下文也會更詳細地提到這種方案,這裏先按下不表。github

現有生產環境中移動端適配方案的一點總結

當咱們在苦苦地尋找適合本身的道路時,不妨先擡頭看看別人是怎麼作的。那麼現實世界裏各家互聯網公司的移動端頁面都採用了什麼樣的適配方案呢?有沒有一些比較有特點的絕活兒呢?如下我按照頁面實際使用的css長度單位做爲劃分標準,爲你們舉一些栗子。瀏覽器

px方案

就像開篇提到的,並非說移動端就必定要使用相對長度單位,傳統的響應式佈局依然是很好的選擇,尤爲在新聞,社區等可閱讀內容較多的場景直接使用px單位能夠營造更好地體驗。px方案可讓大屏幕手機展現出更多的內容,更符合人們的閱讀習慣。採用這種方案的網站有:markdown

  • 騰訊框架

    移動端首頁主要是新聞內容,須要更好的閱讀體驗,適合直接使用px進行佈局。oop

  • 知乎

    知乎也是比較典型的追求閱讀體驗的場景,不出意外的也是直接使用px。

  • 點評

    視覺元素較豐富,依舊採用了px方案,頁面基本是flex佈局,適配效果很好

  • 頭條

    頭條的這個方案有點特點,依然會設置html元素的font-size也會加上data-dpr屬性而且會對viewport進行scale, 可是最終css的輸出仍是px,並無使用rem,而且會對不一樣dpr下的樣式單獨定義,以下圖所示:

    頭條的適配方案
    這樣能夠解決1px border的問題,文字大小也不會隨屏幕尺寸變更(畢竟文本內容較多),雖然我暫時沒找到使用到rem的地方,但確實能夠在須要的時候對特殊元素作rem方案的佈局,不過這種方案應該會形成css文件大小倍增,並且輸出這樣的css確定也少不了構建流程插件的支持,算是一種特定的解決方案吧。

看到這裏你覺得最終輸出px就不能作相似於rem/vw的彈性佈局了嗎,下面就給你們看一手絕活兒...

  • 淘寶

    什麼?給咱們看了半天文章結果用的是px?

    喵喵喵
    其實聰明的你必定很快就會發如今效果上淘寶移動端的適配方案和rem/vw的方案實際上是差很少的,元素的樣式都是經過js生成的,雖然單位確實是px,可是方案依舊是以375px寬度的尺寸爲基準進行縮放的。原理上應該是一種css in js的方案,只不過把rem方案中設置html元素font-size的過程內化到使用js計算元素style的過程當中去了。這樣的方案涉及到總體的開發框架上的統一與支持,並不算是一個特別通用的方案。好處多是直接使用px單位結果更爲精確。能夠說是一手絕活兒了。固然淘寶旗下仍是有很是多的產品線的,也未必是一樣的適配方案(好比大漠老師文中的例子),這裏只針對這個移動端首頁來講。

rem方案

rem方案能夠說是比較成熟了,出鏡率也較高,也就再也不贅述了,總的來講rem方案主要分爲兩種,一種是縮放viewport的方案,如當年的lib-flexible,能夠對1px border等細節問題較方便的處理,但會影響到media query。另外一種就是不縮放viewport,對1px boder等問題單獨引入處理方案。而後對於基準尺寸下的html元素fong-size也有不少不一樣的定義方式,這個提及來沒什麼標準可言,我就隨便舉幾個例子說明吧:

不縮放viewport

(如下說明的rem與px的對應關係都是在屏幕寬度爲375px的狀況下)

  • 馬蜂窩 1rem = 37.5px

  • 小米 1rem = 52.0833px

  • 小紅書 1rem = 50px

  • 微博

    1rem = 16px 稍微說明下 微博的font-size是根據media query來生成的

縮放viewport

(如下說明的rem與px的對應關係都是在屏幕寬度爲375px, viewport scale 0.5的狀況下)

vw方案

來了,終於來了!前面說了這麼多關於vw的問題,到底有沒有現有的產品在大規模的使用vw的方案呢?兼容方案又是怎麼作的呢?

  • 京東

    京東的移動端首頁採用了vw+rem的佈局方式,元素佈局上依然使用rem單位,沒有縮放viewport, html元素的font-size則使用vw + px fallback的形式,而且使用media query來限制佈局寬度,以下圖所示

    正常狀況下:

    京東適配方案 正常狀況下
    邊界狀況下
    京東適配方案 邊界狀況下

  • 網易

    網易的方案和京東基本相同,沒有縮放viewport,使用media query,只處理html元素的font-size,並限制佈局寬度。

  • 餓了麼

    餓了麼也是採用的vw+rem的方案,不過對viewport進行了縮放,也沒有限制佈局寬度,html元素的font-size依然由px指定,可是具體元素的佈局上使用vw + px fallbak的形式,以下圖所示:

餓了麼適配方案

能夠看到,使用上述兩種vw+rem的方案對現有的rem方案的改動都不會很大,都採用了vw + fallback的方式,兼容性問題獲得了保證,只是餓了麼的方案可能更須要構建過程當中的插件支持(關於這個,後面我給大家解釋解釋什麼叫驚喜)。這樣來看,對於大漠老師提出的vw方案中使用viewport-units-buggyfill庫進行兼容的作法,我我的就並非很推薦了,由於該庫使用了css content屬性進行兼容處理,官方文檔中就指出了對部分瀏覽器的img標籤有影響 ,須要全局引入一條css規則。且對於須要正常使用content的狀況(如:圖標字體)也會引發不可避免的衝突,另外也不支持僞元素的兼容。因此從我我的的角度來講,若是你必定要問我使用怎樣的vw適配方案,我會推薦給你上述兩種vw + rem的方案。

這就是所有了嗎?

固然不是,我只是列舉了幾個比較典型的移動端適配方案,其實在具體實現的細節上能夠自行把握的點仍是不少的,適合的終歸纔是最好的,那顆銀彈或許不會出現,但咱們的手中也從未缺乏過利器。

彩(an)蛋(li)部分

相信大多數同窗也是有想法在實際開發中把vw融入到現有的移動端適配方案中的。如我上述提到的兩種vw+rem方案,只修改html元素font-size的方案對於已經在使用rem方案的同窗來講改動的成本並不大,只須要在本來的media query 裏(或js生成style時)在font-size: *px後面加上font-size: *vw就能夠了,如需限制佈局寬度則需多加一點判斷。

而對於餓了麼那種在使用到長度單位時同時輸出rem+vw的方式,確定是要經過一點額外的插件來作了。若是你和我同樣恰好在使用Stylus做爲css預處理器,那我專門寫了一個Stylus的插件用來幫你處理這個問題。 這個插件可讓你在開發流程使用px書寫css, 和現有的部分插件不一樣的是,它同時支持多種適配方案的輸出,目前支持rem,純vw方案以及剛纔提到的vw+rem方案的輸出。而且對不但願轉換px的場景作了很方便的處理。也就是說,若是你如今使用rem方案,能夠直接替換使用該插件,當你須要切換到vw或vw+rem方案時基本能夠作到無縫切換。

具體的使用方式和示例請參見pandaGao/stylus-px-to-relative-unit

懂個人意思吧
相關文章
相關標籤/搜索