移动端的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也是有副作用的：
1、移动端对于浮点数的计算其实并不像pc那么精确。实际工作中我们经常会碰到根节点fontSize设置为10px，实际元素的属性值（如border: .1rem solid #000）有小数点的情况，这种情况下，虽然理论上的px值应该为1px，但是实际上很有可能就变成了0px(也就是视觉上不可见)，也就是这个原因，也导致了rem的borderRadius的设置的圆看着像椭圆，所以‘px‘这个单位在这个背景下还是有它自己的使用空间，虽然这看上去甚至有一些违背使用rem的初衷。
2、css绘制的图形可以rem，但是图片却不行。我们都知道，图片的清晰度需要在它的实际分辨率范围内才能够保证，如果任由rem设置图片宽高，被肆意拉伸的图片其实并不是我们想要的，所以在设置图片的时候还需要有另外的考量。
3、有关rootElemenet元素的fontSize，并不是一直都那么准确，也即这套方案是有兼容性问题的。笔者的实际工作中就发现，有一些比较“另类”的手机在使用rem的实际效果很奇怪，它们内部的计算颇有些令人发指，所以，即使大范围使用了rem作为主要单位，但是很多场景下，‘%‘这个比例单位还是有使用空间的。
说完了rem的功过，我们来聊一下替代方案：
笔者有了解过的方案有两套：
1、基于vh,vw的方案：
其实相关的单位总共有4个，vh、vw、vmin、vmax，它们统称为视窗（Viewport，也称作视口）单位，vw、vh分别表示相对于视窗宽度/高度的百分比（如1vw表示视窗宽度的1%），读到这里，聪明的读者应该就能想象，如果能相对于视窗的百分比来设置，不就是能够自适应各种屏幕了么？没错，看上去确实是这样，但是，再一细想还是会有不能覆盖的场景，比如fontSize（其实有没有想过，说不定委员会制定vh、vw、rem等单位，其实初衷是想结合使用？），而且本身也有一些兼容问题，所以实践得并不算太多。
2、基于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还有着更多的“特性”等着我们去适配，前端还是任重而道远。