【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还有着更多的“特性”等着咱们去适配，前端仍是任重而道远。