编者注：在移动端中利用rem的相对于根HTML进行改变，通过一段时间JS实现了移动端自适应，本文则使用纯CSS视口单位来自行自适应，虽然现在的兼容性还没法完全能够接受，但不妨碍你认识这个vw和vh的强大。

响应式布局的实现依靠媒体查询（Media Queries）来实现，选取主流设备宽度尺寸作为断点针对性写额外的样式进行适配，但这样做会比较麻烦，只能在选取的几个主流设备尺寸下呈现完美适配。

即使是通过rem单位来实现适配，也是需要内嵌一段脚本去动态计算根元素大小。

近年来，随着移动端对视口单位的支持越来越成熟、广泛，使得我们可以尝试一种新的办法去真正地适配所有设备尺寸。

认识视图单位（Viewport units）

首先，我们要了解什么是视口。

在业界，极为推崇的一种理论是Peter-Paul Koch（江湖人称"PPK大神"）提出的关于视口的解释---在桌面端，视口指的是在桌面端浏览器的可视区域；而在移动端较为复杂，它涉及到三个视口，分别是：Layout Viewport（布局视口）、Visual Viewport（视觉视口）、Ideal Viewport

而视口单位中的 "视口"，在桌面端，毫无疑问指的就是浏览器的可视区域；但是在移动端，它指的则是三个Viewport中的Layout Viewport。

根据css规范，视口单位主要包括以下4个：

vw：1vw等于视口宽度的1%
vh：1vh等于视口高度的1%
vmin：选取vw和vh中最小的那个
vmax：选取vw和vh中最大的那个

视口单位区别于%单位，视口单位是依赖于视口的尺寸，根据视口尺寸的百分比来定义的；而%单位则是依赖于元素的祖先元素。

用视口单位度量，视口宽度为100vw，高度为100vh（左侧为竖屏情况，右侧为横屏情况）

例如，在桌面端浏览器视口尺寸为650px，那么1vw = 650 * 1% = 6.5px（这是理论推算得出，如果浏览器不支持0.5px，那么实际渲染结果可能是7px）。

兼容性

其兼容性如下图有所示，可以知道：在移动端ios8以上以及Android 4.4以上获得支持，并且在微信 x5 内核中也得到完美的全面支持

截图来自Can I Use

利用视口单位适配页面

对于移动端开发来说，最为重要的一点是如何适配页面，实现多终端的兼容，在不同的适配方式各有千秋，也各有缺点。

就主流的响应式布局、弹性布局来说，通过Media Queries 实现的布局需要配置多个响应断点，而且带来的体验也对用户十分不友好：布局在响应断点范围内的分辨率下维持不变，而在响应断点切换的瞬间，布局带来断层式的变化，如同卡带的唱机般“咔咔咔”地一下又一下。

而通过采用rem单位的动态计算的弹性布局，则是需要在头部内嵌一段脚本来进行监听分辨率的变化来动态改变根元素字体大小，使得CSS与js耦合在了一起。

有没有办法能够解决这样的问题呢？

答案是肯定的，通过利用视口单位实现适配的页面，是技能解决响应式断层问题，又能解决脚本以来的问题的。

做法一：仅使用vw作为css单位

在仅使用vw作为单位作为唯一一种CSS单位的做法下，我们遵守：

对于设计稿的尺寸转换成vw单位，我们使用Sass函数编译

// iPhone 6 尺寸作为设计稿基准
$vw_base: 375px;
@function vw($px) {
    @return ($px / $vw_base) * 100vw;
}

无论是文本还是布局宽度、间距等都使用vw作为CSS单位

.mod_nav {
    background-color: #fff;
    &_list {
        display: flex;
        padding: vw(15) vw(10) vw(10); // 内间距
        &_item {
            flex: 1;
            text-align: center;
            font-size: vw(10); // 字体大小
            &_logo {
                display: block;
                margin: 0 auto;
                width: vw(40); // 宽度
                height: vw(40); //高度
                img {
                    display: block;
                    margin: 0 auto;
                    max-width: 100%;
                }
            }
            &_name {
                margin-top: vm(2);
            }
        }
    }
}

1px物理像素线（也就是普通屏幕下1px，高清屏幕下0.5px的情况）采用transform 属性 scale 实现。

.mod_grid {
    position: relative;
    &::after {
        // 实现1px的下边框线
        content: '';
        position: absolute;
        z-index: 1;
        pointer-events: none;
        background-color: #ddd;
        height: 1px;
        left: 0;
        right: 0;
        top: 0;
        @media only screen and ()
    }
}

对于需要保持高宽比的图，应改用padding-top实现

.mod_banner {
    position: relative;
    padding-top: percentage(100/700); // 使用padding-top
    height: 0;
    overflow: hidden;
    img {
        width: 100%;
        height: auto;
        position: absolute;
        left: 0;
        top: 0;
    }
}

由此，我们能够实现一个常见布局的页面效果如下：

体验地址点击此处

做法二：搭配vw和rem，布局更优化

这样的页面虽然看起来适配得很好，但是你会发现由于它是利用视口单位实现布局，依赖于视口大小而自动缩放，无论视口过大还是过小，他也随着视口过大或者过小，失去了最大最小宽度的限制。

当然，你可以不在乎这样微小的不友好用户体验，但我们还是尝试下追求修复这样的小瑕疵吧。

于是，联想到不如结合rem单位来实现布局？rem弹性布局的核心在于动态改变根元素大小，那么我们可以通过：

给根元素大小设置随着视口变化而变化的vw单位，这样就可以实现动态改变其大小。
限制根元素字体大小的最大最小值，配合body加上最大宽度和最小宽度

这样我们就能够实现对布局宽度的最大最小限制。因此，根据以上条件，我们可以得出代码实现如下：

// rem 单位换算： 定位75px 只是方便运算， 750-75px、 640-64px、 1080-108px， 如此类推
$vw_fontsize: 75; // iPhone6 尺寸的根元素大于基准值
@function rem($px) {
    @return ($px / $vm_fontsize) * 1rem;
}
// 根元素大小使用vw单位
html {
    font-size: ($vm_fontsize / ($vm_design / 2)) * 100vw;
    // 同时，通过Media Queries 限制根元素最大值，最小值
    @media screen and (max-width: 320px) {
        font-size: 64px;
    }
    @media screen and (min-width:540px) {
        font-size: 108px;
    }
}

// body 也增加最大最小宽度限制，避免默认100%宽度的block元素跟随body而过大过小
body {
    max-width: 540px;
    min-width: 320px;
}

这里就不再给出截图，但可以点击此处在线地址进行体验。

小结

相对于做法一，个人比较推崇做法二，有以下两点原因：

第一，做法二相对来说用户视觉体验更好，增加了最大最小宽度的限制；

第二，更重要是，如果选择主流的rem弹性布局方式作为项目开发的适配页面方法，那么做法二更适合于后期项目从rem单位过渡到vw单位。只需要通过改变根元素大小的计算方式，你就可以不需要其他任何的处理，就无缝过渡到另一种CSS单位，更何况vw单位的使用必然会成为一种更好的适配方式，目前它只是碍于兼容性的支持而得不到广泛的应用。

后语

这是笔者在偶然中阅读到[翻译]使用VH和VW实现真正的流体排版这一篇文章得到的感悟与成果，也满心欢喜地期待这篇文章同样能够带给读者一些启发，并提出一些vw单位的使用秘笈来就留交流~:)

此文为转载。原文：凹凸实验室 https://aotu.io/notes/2017/04/28/2017-4-28-CSS-viewport-units/