2018年最后的法定假期都已经结束了,我相信大部分正在进行或曾经进行过移动端页面开发的同窗都或多或少的了解过使用rem进行移动端页面适配的方案以及使用vw的方案,(没了解过的同窗能够参见大漠老师的这两篇文章 使用Flexible实现手淘H5页面的终端适配和再聊移动端页面的适配)也面临过在不一样适配方案间进行抉择的思考,我我的最近对于移动端适配方案也进行了一轮从新的研究,期间,对各类适配方案也有一些本身的看法,正好记录下来与你们一块儿分享。css
固然不是。并非全部场景下的移动端页面都适合采用vw或rem的方案,这类方案的本质是布局等比例的缩放,让页面在不一样尺寸的屏幕下有相似于矢量图片缩放的效果,即保证页面各元素之间位置尺寸的比例关系,并让元素能够清晰地展示。 这样的方案更适合于视觉组件种类较多,视觉设计对元素位置的相对关系依赖较强的移动端页面。其实大部分页面均可以使用rem或vw的方案进行适配,但对于文本内容较多,或者说但愿引导用户沉浸浏览的页面,我我的并不推荐使用等比缩放的方案,至少并不推荐彻底使用等比缩放的方案,对于文本内容仍是应该直接使用px这种绝对长度单位,毕竟在大屏手机上用户但愿看到的是更多的内容而不是更大的内容。实际上不少这类的网站也确实是直接使用px结合flex等布局方式进行移动端适配的,这个在后面讨论具体技术方案的时候我会举几个例子。html
在各类rem适配方案的实现中,有两个核心的点前端
<meta name="viewport" content="xxx">
(能够根据dpr缩放viewport,也能够直接使用1倍的视口大小)以前我已经提到过,vw和rem的方案的本质都是“等比例缩放”,由于vw和rem都是相对长度单位(relative length unit),能够很好的知足这个需求。区别是vw是viewport width的1%,而rem是html元素的font-size。当咱们让html元素的font-size与viewport width产生了关联后,rem就能够模拟出使用vw进行布局的效果了。因此在rem方案中,咱们只是在把rem当作是vw的影子。写做rem,读做vw...(剧情彷佛狗血起来了... rem: 固然是选择原谅大家啊) html5
我想这时候有人要说了:“醒醒兄弟 已经8102年了!” 是的,8102年都快要过去了,对于兼容性要求不是特别高的状况下vw也算是能够见天日了,而且也有一些针对vw的补丁方案,但还有一个问题咱们要稍微讨论一下...git
回答依旧是否认的。单纯使用vw进行布局不能限制布局的宽度,对于有这个需求的场景至少仍是须要将vw和rem混用来处理边界状况。下文也会更详细地提到这种方案,这里先按下不表。github
当咱们在苦苦地寻找适合本身的道路时,不妨先抬头看看别人是怎么作的。那么现实世界里各家互联网公司的移动端页面都采用了什么样的适配方案呢?有没有一些比较有特点的绝活儿呢?如下我按照页面实际使用的css长度单位做为划分标准,为你们举一些栗子。浏览器
就像开篇提到的,并非说移动端就必定要使用相对长度单位,传统的响应式布局依然是很好的选择,尤为在新闻,社区等可阅读内容较多的场景直接使用px单位能够营造更好地体验。px方案可让大屏幕手机展现出更多的内容,更符合人们的阅读习惯。采用这种方案的网站有:markdown
腾讯框架
移动端首页主要是新闻内容,须要更好的阅读体验,适合直接使用px进行布局。oop
知乎也是比较典型的追求阅读体验的场景,不出意外的也是直接使用px。
视觉元素较丰富,依旧采用了px方案,页面基本是flex布局,适配效果很好
头条的这个方案有点特点,依然会设置html元素的font-size也会加上data-dpr属性而且会对viewport进行scale, 可是最终css的输出仍是px,并无使用rem,而且会对不一样dpr下的样式单独定义,以下图所示:
看到这里你觉得最终输出px就不能作相似于rem/vw的弹性布局了吗,下面就给你们看一手绝活儿...
什么?给咱们看了半天文章结果用的是px?
rem方案能够说是比较成熟了,出镜率也较高,也就再也不赘述了,总的来讲rem方案主要分为两种,一种是缩放viewport的方案,如当年的lib-flexible,能够对1px border等细节问题较方便的处理,但会影响到media query。另外一种就是不缩放viewport,对1px boder等问题单独引入处理方案。而后对于基准尺寸下的html元素fong-size也有不少不一样的定义方式,这个提及来没什么标准可言,我就随便举几个例子说明吧:
(如下说明的rem与px的对应关系都是在屏幕宽度为375px的状况下)
马蜂窝 1rem = 37.5px
小米 1rem = 52.0833px
小红书 1rem = 50px
1rem = 16px 稍微说明下 微博的font-size是根据media query来生成的
(如下说明的rem与px的对应关系都是在屏幕宽度为375px, viewport scale 0.5的状况下)
来了,终于来了!前面说了这么多关于vw的问题,到底有没有现有的产品在大规模的使用vw的方案呢?兼容方案又是怎么作的呢?
京东的移动端首页采用了vw+rem的布局方式,元素布局上依然使用rem单位,没有缩放viewport, html元素的font-size则使用vw + px fallback的形式,而且使用media query来限制布局宽度,以下图所示
正常状况下:
网易的方案和京东基本相同,没有缩放viewport,使用media query,只处理html元素的font-size,并限制布局宽度。
饿了么也是采用的vw+rem的方案,不过对viewport进行了缩放,也没有限制布局宽度,html元素的font-size依然由px指定,可是具体元素的布局上使用vw + px fallbak的形式,以下图所示:
能够看到,使用上述两种vw+rem的方案对现有的rem方案的改动都不会很大,都采用了vw + fallback的方式,兼容性问题获得了保证,只是饿了么的方案可能更须要构建过程当中的插件支持(关于这个,后面我给大家解释解释什么叫惊喜)。这样来看,对于大漠老师提出的vw方案中使用viewport-units-buggyfill库进行兼容的作法,我我的就并非很推荐了,由于该库使用了css content属性进行兼容处理,官方文档中就指出了对部分浏览器的img标签有影响 ,须要全局引入一条css规则。且对于须要正常使用content的状况(如:图标字体)也会引发不可避免的冲突,另外也不支持伪元素的兼容。因此从我我的的角度来讲,若是你必定要问我使用怎样的vw适配方案,我会推荐给你上述两种vw + rem的方案。
固然不是,我只是列举了几个比较典型的移动端适配方案,其实在具体实现的细节上能够自行把握的点仍是不少的,适合的终归才是最好的,那颗银弹或许不会出现,但咱们的手中也从未缺乏过利器。
相信大多数同窗也是有想法在实际开发中把vw融入到现有的移动端适配方案中的。如我上述提到的两种vw+rem方案,只修改html元素font-size的方案对于已经在使用rem方案的同窗来讲改动的成本并不大,只须要在本来的media query 里(或js生成style时)在font-size: *px
后面加上font-size: *vw
就能够了,如需限制布局宽度则需多加一点判断。
而对于饿了么那种在使用到长度单位时同时输出rem+vw的方式,确定是要经过一点额外的插件来作了。若是你和我同样恰好在使用Stylus做为css预处理器,那我专门写了一个Stylus的插件用来帮你处理这个问题。 这个插件可让你在开发流程使用px书写css, 和现有的部分插件不一样的是,它同时支持多种适配方案的输出,目前支持rem,纯vw方案以及刚才提到的vw+rem方案的输出。而且对不但愿转换px的场景作了很方便的处理。也就是说,若是你如今使用rem方案,能够直接替换使用该插件,当你须要切换到vw或vw+rem方案时基本能够作到无缝切换。
具体的使用方式和示例请参见pandaGao/stylus-px-to-relative-unit