响应式页面几大流派

为了方便判断和描述，还需理解一些概念：
设备像素，物理像素，设备逻辑像素。
布局视口，视觉视口，理想视口。

简单来讲，手机可能像素很高清，但设备大小不骗人，我们按屏宽来算就好；
也意味着，不管手机尺寸如何，我们把它截图放大了跟 750px 的设计原稿比较，即为判断依据。

栅栏布局 Bootstrap 的时代

那时还是 PC 盛行的时代，手机和移动端网站的普及度不高。
@media 被发明之初，能满足 PC & 平板 & 手机响应式的网站的价格都翻了番。
也造就了 Bootstrap 这个封装了栅栏布局的前端 UI 框架的盛行。

但 bootstrap 布局的原理实则并不复杂，
将 <768px 认为是手机，<992px 则为平板，其他为电脑，>1200px 的大屏则设个定宽左右留白。
各区间内，屏宽在理论上被平分为 12 栏，比如 col-6 代表宽度占父级 50%，col-3 占 25%。

当然，本文中栅栏布局并不是重点，而是 定宽留白 和 百分比宽度。

比如屏幕宽度有 1334px 和 1280px 这样的差别，那也只是左右留白的区别而已。
而当是 480px 和 360px 的差别时，我只管宽度所占百分比不变即可（至少比定宽 100px 表现要好咯）。

（不管手机本来什么宽度，都等比放大成 750px 来比较，就会清晰发现与设计稿的异同）

-1

定宽留白 和 百分比宽度 可以说非常粗放地实现了响应式，
到现在也常常会使用 padding: 0 2% 或 width:200px;margin:0 auto 等这样的方式去布局。
但移动时代的演进和移动设备品种的增多，此类布局的弊端也不断地在放大。

更复杂的移动端响应式

首先面临的问题就是手机尺寸的变化，比如爱疯5那样的小屏手机与全面屏爱疯X，
虽然在物理像素上，仿佛差距只有 50-90 多像素，但整个屏幕也没几个 50 呀，
所以小屏手机上几乎占满的 300px 在大屏手机上可能只占了一半。

那么我们是否依旧还能使用定宽留白和百分比宽度来解决这个问题呢？
当然是显然不能的，因为 移动端网页的设计粒度不同了。
移动端中出现了更多小图标/小提示等，如果都只有 20px，那在大屏手机上恐怕会非常细小。

即使在 768px 以下再加一个区间来补充，或不断 @media 打点来补漏，
这套方案想想都觉得不太秒，也即下文的 em 布局方案，试图去解决 字体大小 的问题，
或者说，是非常粗放地去解决 20px 在 320px 和 414px 的手机上表现差异的问题。

还有就是元素高度的问题，即 等比缩放 问题。宽度等比了，但高度响应却是较难做到的。
（虽然可以使用 :before 的 padding-top 来实现宽高定比缩放）

除此之外，还有 高清屏 带来的问题，不清晰呀/1px 问题呀/高清图呀，等等。

所以，移动端的响应式问题解决起来要比PC端复杂得多，因此也涌现出了一些非常不错的方案。

为了移动端而奋斗！

em 布局

根据设备尺寸调整字号，让文字相应的越来越大，感觉上是可以尽可能少的地改动布局的。
比如以前在 320px 上的 20px，到了 375px 上变成 26px，相对来说是对布局进行了缩放。

因此就产生了下面这样的代码：

html { font-size: 10px;}
@media screen and (min-width:321px) and (max-width:375px){
    html {font-size:11px}
}
@media screen and (min-width: 376px) and (max-width: 414px) {
    html {font-size: 12px;}
}
@media screen and (min-width: 415px) and (max-width: 639px) {
    html {font-size: 15px;}
}
@media screen and (min-width: 640px) and (max-width: 719px) {
    html {font-size: 20px;}
}
@media screen and (min-width: 720px) and (max-width: 749px) {
    html {font-size: 22.5px;}
}
@media screen and (min-width: 750px) and (max-width: 799px) {
    html {font-size: 23.5px;}
}

最终效果其实还不赖，对整体布局的不会造成太大的改动，
小型元素或一定程度上定宽的元素则都可以使用 em 来布局，大屏手机上文字也更大了些。

但对大型元素和整体布局来说，实在无法将 em 与 百分比进行等同，
举个例子，当 320px 屏时 10em 可能刚刚好，但 375px 屏上就超出了。
这实在不是一个精细的布局方式，仅仅适用与小元素吧。

至于 Retina 屏问题加几个 @media (-webkit-min-device-pixel-ratio:1) 也算是能部分解决。

rem 布局

因此，用 js 来修改字号的精细版本就出现了。

!function() {
    function e() {
        r.innerText = "html{font-size:" + (a.style.fontSize = a.getBoundingClientRect().width / o * d + "px") + " !important;}"
    }
    var t = navigator.userAgent,
        n = (t.match(/(iPhone|iPad|iPod)/), t.match(/Android/i), window),
        i = document,
        a = i.documentElement,
        o = (n.devicePixelRatio, 375),
        d = 100,
        r = (i.head.querySelector('[name="viewport"]'), i.createElement("style"));
    r.innerText = "html{font-size:100px !important}", i.head.appendChild(r), e(), n.addEventListener("resize", e, !1);
    a.className += t.match(/ucbrowser/i) ? " app-uc " : ""
}();

相比以前 100% 等于多少都不知道，到现在能固定 3.75rem = 750px，rem 布局可谓是质的飞跃。
它充分发挥了 rem 的特性，em 还得受父级字号影响，但 rem 只受根元素字号的影响。

另一方面，它使得图片的等比缩放也变得更为简单，因为 rem 自带缩放。

还有一个彩蛋，即使按住 Ctrl 再滚轮，也不会缩放显示哟。

lib-flexible

官网：https://github.com/amfe/lib-flexible

它是 rem 布局现阶段的巅峰，非常成熟，在相当多的项目中被实践，社区活跃。
搭配上各种诸如 sublime 插件，让开发和计算都变得十分简单。
且为 rem 布局的方案增加了更多分辨率，机型，和字体大小的适配与试错。

vw 布局

既然 rem 是按屏宽来求默认基本单位的，那我 vw 不也是吗，
lib-flexible 的 10em = 750px，vw 的 100vw = 750px。
这一切是如此的相似，所以就此产生了相当多的争论。

撇开 vw 和 min-device-pixel-ratio 的兼容性不谈，
我个人是站在 vw 这边的，不仅仅是因为不用加入 js。

还有一些原因是不得不提一句的：
如果在 lib-flexible 布局中使用 @media 的 10rem 其实它并不是等同于 750px 的，你不妨试试。
除了 vw 外，官方还有 vmax 等属性搭配使用，让横屏和居中等布局问题有了更多可能性。

另外不得不承认，rem 布局和 vw 布局想要同事适配 PC 端是极不容易的事情，
因此此时的屏宽将造成字号极大，即使限制最大字号也将改动大量的宽度限制。
所以对此，多半我们还会选用下文的 后端判断跳页 这套方案一起使用。

pt 布局

pt 布局是一种很奇特的现象，如果不是 这篇文章 我都无从得知。

它不再需要 width=device-width 这个东西，整个 meta 只要不允许缩放即可。

<meta name="viewport" content="user-scalable=no" />

设计稿的 750px 等于开发时 750pt * 0.98，
如果你使用 less/sass，布局这件事件就变得很简单了。

因为这套方案过于奇特，虽然在项目中已有试用，但实在不敢保证无误。

固定视图

还有骚操作，也是抛弃了 device-width 判断的方法。

<meta name="viewport" content="width=750,user-scalable=no" />

设计稿的 750px 直接等于开发时的 750px。
这应该是非常理想的一种结局了吧，全凭 1:1 的 px 就能完美还原布局。
且不管是何种像素或分辨率的设备都会被认为是 750px 的视图大小。

然而，在欣喜地使用它有半年之久后，还是发现了一些问题。
在极少的 PC 端中，需要 width=935 才能让实际视图表现为 750px。而且这类机型的各类参数中又找不出与其他机型的区别，这让我很失落。从而又不得不回归 lib-flexible 的怀抱。

但如果你的项目只需运行在移动端，那不妨采用这个简单粗暴的布局办法。

百分比定位

在网页中还有一种特殊的存在，即营销类H5。
它往往没有什么嵌套关系，且以元素的定位布局为主。

虽然我们依旧可以采用上面的各种办法来进行适配，
但纯靠百分比去处理宽高也不失为一种特别适用于这类网页的处理方法。

后端判断

虽然以上办法都极大的解决了移动端网页的视觉还原问题，
但要让它们同时适配平板和PC，恐怕是有难度的。比如宽屏求 rem 就会非常不理想。

所以往往很多网站都选用了 多端分离 的办法，
在 PC 端访问的一个网站，在手机上访问的是另一个网站，在 APP 中可能又是一个网站。

不仅如此，这样拆分让各网站的功能和交互也可以根据终端的使用习惯而进行大量改动。