【css】rem及其替換方案

　　移動端的web前端開發其實常常會有一些使人頭疼的問題，好比屏幕適配、1像素問題等，rem也是以前在屏幕適配上比較完善的一套方案，可是隨着業務的深刻，任何方案都有其優秀與不足的地方，rem這套方案也同樣，筆者今就來從自身項目的角度，簡單的聊聊rem這整套方案的得與失。

　　首先，介紹下原理：

　　rem是什麼？它是css3新推出的相對單位，英文全稱爲font size of the root element，意思就是根據網頁的根元素來設置字體大小，和另外一個em(font size of the element)根據父元素的字體大小來者是不一樣，它是根據根節點，也就是html元素來設置大小，舉個簡單的例子：

html{
    font-size: 12px;
}
p{
    width: 1rem; //實際長度 1 * 12 = 12px;
}

　　也正因爲這個機制，咱們就能根據只改變根元素的fontSize這一個點的方式就能改變全局的設置了rem單位的元素的樣式。

　　可是，正如前面提到的，沒有什麼方案是沒有反作用的，rem也是有反作用的：

　　一、移動端對於浮點數的計算其實並不像pc那麼精確。實際工做中咱們常常會碰到根節點fontSize設置爲10px，實際元素的屬性值（如border: .1rem solid #000）有小數點的狀況，這種狀況下，雖然理論上的px值應該爲1px，可是實際上頗有可能就變成了0px(也就是視覺上不可見)，也就是這個緣由，也致使了rem的borderRadius的設置的圓看着像橢圓，因此'px'這個單位在這個背景下仍是有它本身的使用空間，雖然這看上去甚至有一些違背使用rem的初衷。

　　二、css繪製的圖形能夠rem，可是圖片卻不行。咱們都知道，圖片的清晰度須要在它的實際分辨率範圍內纔可以保證，若是任由rem設置圖片寬高，被肆意拉伸的圖片其實並非咱們想要的，因此在設置圖片的時候還須要有另外的考量。

　　三、有關rootElemenet元素的fontSize，並非一直都那麼準確，也即這套方案是有兼容性問題的。筆者的實際工做中就發現，有一些比較「另類」的手機在使用rem的實際效果很奇怪，它們內部的計算很有些使人髮指，因此，即便大範圍使用了rem做爲主要單位，可是不少場景下，'%'這個比例單位仍是有使用空間的。

　　說完了rem的功過，咱們來聊一下替代方案：

　　筆者有了解過的方案有兩套：

　　一、基於vh,vw的方案：

　　　　其實相關的單位總共有4個，vh、vw、vmin、vmax，它們統稱爲視窗（Viewport，也稱做視口）單位，vw、vh分別表示相對於視窗寬度/高度的百分比（如1vw表示視窗寬度的1%），讀到這裏，聰明的讀者應該就能想象，若是能相對於視窗的百分比來設置，不就是可以自適應各類屏幕了麼？沒錯，看上去確實是這樣，可是，再一細想仍是會有不能覆蓋的場景，好比fontSize（其實有沒有想過，說不定委員會制定vh、vw、rem等單位，其實初衷是想結合使用？），並且自己也有一些兼容問題，因此實踐得並不算太多。

　　二、基於meta中設置viewport scale的方案：

　　這個方案也是源於移動端那個著名的1像素問題，實現其實很簡單，主要是這樣：

<!--
    服務器端根據前端第一次請求頁面時帶的客戶端信息，判斷客戶端是幾倍屏，而後對應的設置viewport的scale
-->
<meta name="viewport" content="initial-scale=0.5, maximum-scale=0.5, minimum-scale=0.5, user-scalable=no">

　　這樣設置了以後，就能夠在樣式中正常的使用'px'單位，可是在物理上它會表現爲對應的實際像素，經過scale來彌補邏輯像素到物理像素的差別，將實際的使用場景拉回了以前的咱們熟悉的「正常」場景，而後在須要適配的場景依然沿用以前的rem的方案，由於含有小數點的場景能夠經過「真」的px去覆蓋，幾乎完整的補齊了rem的缺憾。

　　第一套方案由於有兼容性的隱形坑，因此實際使用得並不算多，而第二種方案，再結合rem可謂是當今的主流實現了，不過它自己也有一個小缺陷，這種設置至關於前端頁面就須要服務端直出了（不過爲了SEO，SSR其實也是大前端的時代的一個趨勢吧），不能簡單的發佈靜態頁面。

　　簡單的總結一下，其實移動端因爲性能上和pc的一些差距和使用環境上的一些區別，在瀏覽器設計之初就會有一些針對移動端的作一些特殊的實現，本文簡單總結了一些筆者最近在調研的一些適配方案，只是移動端這些「特性」的一些方面，而最近開始逐漸普及的android 7還有着更多的「特性」等着咱們去適配，前端仍是任重而道遠。