rem不是神农草，治不了移动端百病

本文作者：IMWeb 结一 原文出处：IMWeb社区 未经同意，禁止转载

有很多朋友一聊起做移动端重构，第一个问题就是用什么单位合适。%，还是rem？（如果你还不太了解rem是什么单位，可先前往CSS3的REM设置字体大小了解。）

然后我的回答是：根据情况而言，%，rem，px都用，而且px用得比较多。然后就是各种疑惑和解释了。

那么多各种尺寸的视窗，到底用什么单位可以搞定呢？这里我借这篇文章，简单把一些遇到的问题总结下。

简单来说，总共就二个问题：

• 宽度不确定
• 高度不确定

下面我们一一说明

宽度不确定

目前主流的宽度： 360px, 375px, 414px等，外加一个小尺寸的320px。

从内容来看，我们的内容一般为文字或图片。

文字这块我们随便挑几个宽度不同的手机查看同一个app，会发现文字大小都是一样的，不会出现iphone se的时候是14px，iphone 6是16px， iphone 6plus是18px。当然我们同时也可以看出不同屏幕大小，还是有所不同的地方，如折行的位置不同，超过省略的字数不同，但这一般是不会影响视觉体验的或撑破布局（如果撑破就要写个media queries了），所以完全ok（当然如果你设置限制一个死高度，那肯定是有影响的）。

于是我们得出第一个结论：既然文字不需要适应各种视窗大小变化，所以单位设置px是完全没有问题的。

对于图片而言，我们会面临两种：一种是百分比的，一种是固定大小的。

对于百分比的，如滚动的banner图片，那肯定是要占全屏的；还有那些一行两个或三个产品，图片与文字按照竖直方面排列的，如淘宝的一些活动页，那也只能是百分比，假如一行两个，那么每个就是50%，如下图：

对于固定大小的，最典型的莫过于微信朋友圈的头像了，就是固定大小。同样我们可以扩展到如下场景：

于是我们得出第二个结论：图片会根据使用场景或用px，或用%（当然也可以使用更高级的vw）

结合前两个结论，得出第三个结论：如果只考虑宽度的不确定，其实rem完全可以不用。

当然rem还有另一种妙用，就是当做vw的替代品来说，具体参考：关于移动端百分比宽度的几种实现

高度不确定

对于高度不确定，90%的时候我们是不关心的，因为有滚动。但是有一种情况我们必须要关心：内容要一屏显示，或者某些内容必须要在首屏显示

当然最简单的办法那肯定是以最小的高度来做，但是对不起，设计师给我们的设计图肯定不是以最小高度来的哈哈。现在一般是以iphone 6为设计标准，高度为667px，那么现在问题来了，怎么搬到480px的高度上去呢？

于是该亮出我们的media queries这把宝剑了。下面来个简单的实例：第一个为iphone 4的效果，第二个为iphone 6效果

可以看出，为了要在480px中显示，我们缩小了图片及文字。

现在我们的问题来了，这个时候是不是要用rem呢？

在回答这个问题之前，先问下自己，如果不用rem，文字用px单位，图片用百分比单位是否可以搞定，答案当然是肯定的，因为我这里就是这么做的。

现在我们换成rem来解决，首先我们期望的目标是文字与图片都使用rem单位，然后只通过media queries改变html元素的font-size大小就可以完成我们需要的结果。

看起来是挺简单的，于是我们就开始试，但是我们面临一个问题图片的缩小比例与文字一般是不一样的，如文字可能从rem换算后的16px缩到14px或12px大小，但是图片估计就不止了，所以就悲剧了，我们还是得通过media queries去改变文字或图片的大小。

所以说rem并不能让你一劳永逸解决问题，如这种高度不确定的问题，本来就需要发挥我们的智商，通过media queries这里减少一分，那里减少二分，然后拼凑拼凑，达到一个正好一屏显示好的效果。

问题的根本是media queries，而不是rem，rem只是我们以为的一个简单而实际并不一定简单的解决办法，回归到本质，px及%也许比rem还简单。

最后总结：rem并不是移动端单位的一切，它不是神农草，并没有多么神奇的疗效，对于移动端px，%这些传统的单位仍然是好单位，顺便期待下vw和vh这两个实用单位加入。