结一

8个月前
  • 2439

    浏览
  • 1

    评论
  • 2

    收藏

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%,如下图:

card list

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

media list

于是我们得出第二个结论:图片会根据使用场景或用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这两个实用单位加入。

1 条评论