前言2018年最后一个法定假期结束了。移动端页面适配使用rem的方案，和使用vw的方案，我已经大致了解了。再来说说移动端页面的适配）我也曾面临过在不同的适配方案之间进行选择的思考。我个人最近对移动端适配方案进行了一轮重新研究。自己的一些感悟，记录下来分享给大家。关于vw和rem方案的一些思考那么，移动适配=vw还是rem？当然不是。并不是所有场景下的所有移动端页面都适合使用vw或者rem方案。这类方案的本质是对布局进行等比例缩放，让页面在不同尺寸的屏幕上都能产生类似矢量图缩放的效果，即保证页面的位置和位置之间的比例关系每个元素的大小，并允许元素被清楚地显示。这样的方案更适用于视觉组件类型较多，视觉设计严重依赖元素位置相对关系的移动端页面。其实大部分页面都可以使用rem或者vw的方案进行适配，但是对于文字内容比较多的页面，或者想要引导用户沉浸式浏览的页面，我个人不建议使用比例缩放的方案，在至少不完全使用比例缩放方案，px的绝对长度单位应该直接用于文本内容。毕竟在大屏手机上，用户更希望看到的是更多的内容，而不是更大的内容。事实上，很多这样的网站确实是直接使用px结合flex等布局方式进行移动适配。后面讨论具体的技术方案时，我会举几个例子。rem计划到底在做什么？在各种rem适配方案的实现中，有两个核心点设置（可以根据dpr缩放视口，也可以直接使用1倍视口大小）根据以当前布局的宽度（通常是视口的宽度，或限定的最大/最小布局宽度）用于设置html元素的font-size。前面说过，vw和rem方案的本质是“按比例缩放”，因为vw和rem都是相对长度单位，可以很好地满足这个要求。区别在于vw是viewport宽度的1%，rem是html元素的font-size。当我们将html元素的font-size与视口宽度相关联时，rem就可以模拟出使用vw进行布局的效果。所以在rem方案中，我们只是把rem当作vw的影子。写rem，读成vw……（剧情好像血腥……rem：当然是选择原谅你了）然后直接用vw就完了？等等，当初之所以流行使用rem的方案，是因为当时浏览器对viewportunits的支持不是很理想（IOS8+，Android4.4+指的是caniuseofviewportunits）。相比较而言，rem要好很多（IOS4.1+，Android2.1+见caniuse），所以对于vw来说，在现在的环境下，前端说我爱你并不容易。我想这时候会有人说：醒醒哥，已经8102年了！是的，8102快结束了，如果兼容性要求不是特别高的话vw是可以处理的，vw也有一些patchingscheme，但是还有一个问题我们稍微谈一下...vw完全可以吗替换雷姆？答案仍然是否定的。简单的使用vw做layout是不能限制layout的宽度的。有这种需求的场景，至少要混合vw??和rem来处理边界条件。该方案在下文中也会有更详细的介绍，这里不再赘述。现有生产环境下移动端适配解决方案总结当我们在苦苦寻找适合自己的路径时，不妨看看别人是怎么做的。那么在现实世界中，互联网公司的移动端页面采用了什么样的适配方案呢？有没有绝招？下面我以页面实际使用的css长度单位作为划分标准给大家举个栗子。px的解决方案就像开头说的一样。这并不意味着移动终端必须使用相对长度单位。传统的响应式布局仍然是一个不错的选择，尤其是在新闻、社区等可读性更强的场景中。直接使用px单位可以创造更好的体验。px方案让大屏手机显示的内容更多，更符合人们的阅读习惯。采用该方案的网站有：腾讯手机首页以新闻内容为主，需要更好的阅读体验，适合直接使用px进行布局。知乎知乎也是追求阅读体验的典型场景。不出意外，px也是直接用的。评论的视觉元素更加丰富，依旧采用px方案。页面基本是flex布局，适配效果很好。缩放视口，但最终css输出还是px，并没有使用rem，分别定义不同dpr下的样式，如下图：这样可以解决1px边框的问题，文字大小会不会随着屏幕尺寸的变化而改变（毕竟文字内容比较多），虽然暂时没找到用rem的地方，但是确实可以用rem方案的布局在需要的时候用于特殊元素，但是这个方案应该会导致css文件的大小翻倍，而且输出这样的css也必须要有buildprocess插件的支持，算是一种具体的解决方案。看到这里，是不是觉得px的最终输出不能做类似于rem/vw的灵活布局？接下来，我就给大家看一招绝活……淘宝呢？看了半天文章，结果是px？其实聪明的你很快就会发现，淘宝的手机适配方案在效果上其实和rem/vw方案差不多。元素的样式都是js生成的。虽然单位确实是px，但是方案还是按照375px宽度的大小进行Scaled。原则上应该是cssinjs方案，但是rem方案中设置html元素font-size的过程内化到使用js计算元素样式的过程中。这样的方案涉及到整体开发框架的统一和支持，不是特别通用的方案。好处可能是直接使用px单位的结果更准确。可以说是一门绝活。当然淘宝还是有很多产品线的，不一定是同一个适配方案（比如大魔老师文章中的例子）。这仅适用于此移动主页。remschemeremscheme可以说是比较成熟了，出镜率也很高，就不赘述了。总的来说，rem方案主要分为两种，一种是缩放viewport，比如当年的lib-flexible，可以更方便的处理1px边框等细节，但是会影响mediaquery。另一种是不对viewport进行缩放，针对1pxboder等问题引入单独的解决方案。然后有很多不同的方法来定义基准尺寸下的html元素的fong-size。是在屏幕宽度为375px的情况下)马蜂窝1rem=37.5px小米1rem=52.0833px小红书1rem=50px微博1rem=16px稍微说明下微博的font-size是根据mediaquery生成的scaledviewport(下面介绍的rem和px的对应关系是在屏幕宽度为375px，视口比例为0.5的情况下）评论1rem=100pxB站主站1rem=46.875px搜狐1rem=75pxvw解决方法来了，终于来了！前面说了很多关于vw的问题，现在有没有大规模使用vw的现有产品？兼容解决方案是如何完成的？京东移动首页采用vw+rem布局方式，元素布局依然使用rem单位，viewport不缩放，html元素的font-size使用vw+pxfallback的形式，mediaquery用于限制布局宽度，如下图正常情况下：网易网易的解决方案和京东在borderline情况下的解决方案基本一致。它不缩放视口，使用媒体查询，只处理html元素的字体大小，并限制布局宽度。你饿了吗？饿了么也采用了vw+rem的方案，但是视口是缩放的，布局宽度没有限制。html元素的font-size依然是px指定的，但是具体元素的布局使用了vw+pxfallbak的形式，如下图所示：可以看出使用以上两种vw+rem的方案不会改变现有的rem解决方案很多，都是采用vw+fallback的方式，保证了兼容性问题，只是饿了么的解决方案在构建过程中可能需要更多的插件支持（关于这个，后面会跟大家解释什么是惊喜）。从这点来看，我个人不建议在大魔君提出的vw解决方案中使用viewport-units-buggyfill库进行兼容，因为该库使用了csscontent属性进行兼容处理，官方指出document为了影响某些浏览器的img标签，需要全局引入一个css规则。而对于需要正常使用内容的情况（如：图标字体），也会造成不可避免的冲突，并且不支持伪元素的兼容。所以从我个人的角度来说，如果你一定要问我用什么vw适配方案，我会推荐你??以上两种vw+rem的方案。仅此而已吗？当然不是，我只是列举了几个典型的移动端适配方案。其实在具体实现的细节上还有很多点可以自己去把握。适合的终究是最好的，银弹未必出现，但我们手中从来不缺利器。彩(an)蛋(li)部分相信大部分同学在实际开发中也有将vw集成到现有移动端适配方案中的想法。像我上面提到的两个vw+rem方案，只修改html元素的font-size的方案，对于已经在使用rem方案的同学来说，成本并不高。只需要在原来的mediaquery（或者js生成style的时候）在font-size:*px后面加上font-size:*vw就可以了，如果需要限制布局宽度，需要多加一点判断。至于饿了么在使用长度单位时同时输出rem+vw的方式，那肯定是通过一点额外的插件来实现的。如果你碰巧像我一样使用Stylus作为css预处理器，那么我写了一个Stylus插件来帮助你处理这个问题。这个插件可以让你在开发过程中使用px来写css。与现有的一些插件不同，它支持同时输出多种适配方案。目前支持rem、purevw方案和刚才提到的vw+rem方案Output。而且处理不想转换px的场景也很方便。也就是说，如果你现在使用的是rem方案，可以直接用这个插件替换，需要切换到vw或者vw+rem方案时基本可以无缝切换。具体用法和例子参考pandaGao/stylus-px-to-relative-unit
