不要再问我移动适配的问题了

width：将布局视口设置为固定的值，比如375px或者device-width（设备宽度）

initial-scale：设置页面的初始缩放

minimum-scale：设置最小的缩小程度

maximum-scale：设置最大的放大程度

user-scalable：设置为no时禁用缩放

虽然只有五个值，但仍有一些值得注意的点：

根据公式缩放系数 = 理想视口宽度 / 视觉视口宽度 ，如果设置了initial-scale比如为0.5，那么以iPhone6为例，iPhone6的设备宽度是375px，即理想视口宽度也为375px，所以视觉视口宽度 = 375px（理想视口宽度）/ 0.5（缩放系数）。很明显设置了initial-scale就相当于初始化了视觉视口，而且会将布局视口初始化为这个视觉视口的值。

上面说到设置了initial-scale相当于初始化了视觉视口和布局视口，但width用于指定布局视口的大小，那么一起设置的话听谁的呢？
还是以iPhone6为例，它的尺寸是667（h） * 375（w），如果设置，执行一下console.log(`布局视口: ${document.documentElement.clientWidth}; 视觉视口: ${window.innerWidth}`)会得到“布局视口: 400; 视觉视口: 400”。
这时候旋转一下设备，这时尺寸变成了667（w） * 375（h），再执行一下console.log(`布局视口: ${document.documentElement.clientWidth}; 视觉视口: ${window.innerWidth}`)会得到“布局视口: 667; 视觉视口: 667”。
结论是：width与initial-scale都会初始化布局视口，但浏览器会取其最大值。

这时候再看回，明明width=device-width和initial-scale=1都是去初始化布局视口成理想的布局视口，只写其中一个不就完了嘛，为什么要两个都一起写呢？因为有的浏览器只设置其中一个，不能保证理想视口的尺寸能随着屏幕的旋转而正确改变，所以两个一起写只是为了解决兼容性问题。

上面说了很多理论知识，其实就是为了能有一套方案舒服地还原移动端设计图，做出一个专为移动端访问的页面。

图片

这里的图片问题是指高清/Retina屏下图片会显示得比较模糊，这是因为我们平时使用的图片大多数是png、jpg这样格式的图片，它们称作是位图图像（bitmap），是由一个个像素点构成，缩放会失真。上面讲像素的时候说过，这种高清/Retina屏DPR大于一，则一像素横跨了多个设备像素，而位图图像需要一个像素点对应一个设备像素才清晰。所以假设一张100 x 100的图片放在普通屏上看是清晰的，放到高清/Retina屏上就会显得比较模糊，那是因为本来100 x 100的图片在普通屏上图片像素与设备像素一一对应，而到了高清/Retina屏上一个图片像素却要对应多个设备像素，这样一来看起来图片就比较模糊。

如图所示，如果一个图片像素要对应多个设备像素的话，那这些设备像素只能显示成跟这个图片像素差不多的颜色，导致看起来会模糊。
既然知道了问题产生的原因，那解决方法也很简单，位图图像需要一个像素点对应一个设备像素才清晰嘛，那就本来是100 x 100的图片在DPR为1的屏幕上显示清晰，在DPR为2的屏幕上显示模糊，那就在DPR为2的屏幕上放200 x 200的图好了，这样就一一对应了。

1px边框

“你看看设计图这根线是很细的，为什么你实现出来那么粗，看起来很劣质的感觉。”
没道理呀，设计图量的是1px，css写的也是1px，怎么会粗了呢？一般设计师出图的时候，都会按照一个尺寸作为标准来出图，比如按照iPhone6的尺寸出图，就是一张750px宽的设计图，这个750px其实就是iPhone6的设备像素，在测量设计图时量到的1px其实是1设备像素，而当我们设置时，布局视口等于理想视口等于375px，并且由于iPhone6的DPR为2，写css时的1px对应的是2设备像素，所以看起来会粗一点。
那么只要写0.5px就是对应1设备像素了嘛。是的，道理是这么说，但是很多浏览器并不支持0.5px的写法，导致显示不出来，但不要紧，网上很多方法解决这个问题的方法就不细说了，这里只是讲清楚1px边框问题产生的原因。

因为PC端屏幕一般都会比设计图尺寸要大，所以只需要居中固定一个内容区用于显示设计图的内容，其余多出的地方留白即可。而移动端屏幕有大有小，设计图一般会以一款机型为标准来出图，比如说iPhone6的尺寸，如果不经处理直接量设计图就开干会出现什么问题呢？

（从左到右为iPhone4、iPhone6、iPhone plus）
可以看到以iPhone6为标准出的设计图测量出来350px x 350px的元素在iPhone6上写width: 350px;height: 350px;是刚刚好的，左右的间隙各有10px，但小一点的屏幕iPhone4横向滚动条都出来了，而plus左右间隙明显比10px大很多，这样一来不同尺寸的屏幕出来的效果跟设计图的效果就会有不同程度的出入，这并不是我们想要的，我们想要的是不同尺寸的屏幕显示的效果与设计图比例是一致的。
既然想要的是不同屏幕尺寸显示的比例与设计图一致，那么显然适配方案就是等比缩放。
（以下代码都是为了讲述原理，没有过多的细节考虑与测试，不能用于生产环境）

viewport方案

说到缩放，首先想到的当然是initial-scale。回想一下initial-scale的作用：设置了initial-scale就相当于初始化了视觉视口，而且会将布局视口初始化为这个视觉视口的值。那么我们是不是可以以设计图为基准等比缩放布局视口从而适配呢？

这种方式进行适配优点是简单粗暴，缺点是太简单粗暴了，因为viewport的设置是影响全局的，这样一来虽然可以直接将设计图量得的尺寸写到css上，但如果有一些需要地方不需要等比缩放而需要设置固定尺寸，比如要求在不同尺寸屏幕上显示固定大小的文字，或者你引进了一个库，里面的有样式你也不知道人家是按照怎样的适配方案进行适配的，那么到了你的项目里由于全局的viewport缩放，可能会影响到这个库的显示效果。

rem方案

不同于px是固定尺寸单位，rem是相对单位，相对于html标签字体大小的单位。比如html标签的font-size为100px，那么1rem就等于100px。借助rem这个相对单位我们同样可以达到等比缩放的效果。

这个方案不需要对viewport进行缩放，所以首先按照惯例我们让布局视口等于理想视口：

还是以iPhone6的设备像素为标准的设计图，宽是750px，假设以设计图为标准的html标签的font-size为100px，所以1rem = 100px，那么这个设计图总宽就有7.5rem

以总宽是7.5rem的设计图为标准，则不同屏幕尺寸的总宽应该也是7.5rem，由于上面设置了布局视口等于理想视口，所以以iPhone6为例，iPhone6的布局视口等于理想视口，则它的布局视口为375px（也就是总宽7.5rem），现在只需要解决在布局视口为375px的情况下，html的font-size需要设置多少。很简单，html font-size * 7.5 = 375，那么font-size为50px。

拓展到其他屏幕document.documentElement.style.fontSize = `${document.documentElement.clientWidth / 7.5}px`

现在我们只需要测量设计图，比如设计图有一个300px的元素，那我们写css的时候就写成3rem（由于以1rem = 100px为基准，所以这里300px / 100即可）

使用这个方案，我们只对需要等比缩放的元素使用rem，而要求固定尺寸的地方使用px即可，这样一来相对于viewport方案来说就比较灵活，可以按需使用而不是一刀切。不过这种方案写css的时候可能会没那么直观，成本可能会高一点点，但是借助构建工具或者less/sass可以解决，毕竟现在应该很少项目不使用这些工具的了吧。

加强版rem方案

这里所说的加强版rem方案其实就是手淘的Flexible方案（也类似移动端高清、多屏适配方案），究竟加强了什么呢？那就是，通过设置viewport进而全局解决1px边框问题。
既然要通过设置viewport来解决1px边框问题，那设置这个viewport的方式肯定内有乾坤：

if (!dpr && !scale) {
    var isAndroid = win.navigator.appVersion.match(/android/gi);
    var isIPhone = win.navigator.appVersion.match(/iphone/gi);
    var devicePixelRatio = win.devicePixelRatio;
    if (isIPhone) {
        if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {                
            dpr = 3;
        } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){
            dpr = 2;
        } else {
            dpr = 1;
        }
    } else {
        // 其他设备下，仍旧使用1倍的方案
        dpr = 1;
    }
    scale = 1 / dpr;
}

得出的scale用于设置viewport的缩放document.write(``)，这样一来，对于Retina屏将viewport缩放为1 / dpr最终产生的效果是，1px css像素严格等于1px 设备像素，由此解决了1px边框问题。那为什么只对iPhone进行缩放呢？请看大漠老师的文章再谈Retina下1px的解决方案。
其他与rem相关的配置与上面的rem方案类似，这里就不再展开说了。
这个加强版rem方案最大的优势是解决了1px边框问题，但由此也进行了viewport的缩放，仍然会面临着上面说的viewport方案涉及到的一些影响，为此该方案会通过给html设置data-dpr

document.documentElement.setAttribute("data-dpr", dpr)

从而写css的时候可以针对不同的dpr固定设置尺寸：

.test {
    width: 1rem; 
    height: 2rem;
    font-size: 12px; 
}
[data-dpr="2"] .test {
    font-size: 13px;
}
[data-dpr="3"] .test {
    font-size: 14px;
}

vw方案

vw也是一个相对单位，它相对的是布局视口，1vw就是1%的布局视口宽度。其实rem方案就是在模拟vw，来看看使用vw怎么做。

还是熟悉的iPhone6标准设计图，宽750px。那么1vw = 1%视口宽度的话，按设计图来说就是100vw = 750px，则1vw = 7.5px。

设计图量得一个元素是100px，css需要写成 Xvw * 7.5 = 100，所以X就等于13.3vw。

计算的话还是交给构建工具即可，详细请看再聊移动端页面的适配

rem方案有的优势vw也有，而且也不会像rem那么绕，但就是兼容性不够rem好，长远来看vw最后会接棒rem作为移动适配的主力，因为它生来就干这个事情呢。

没有银弹。
全局viewport缩放方案很粗暴？但对于要求不高也不需要兼顾固定尺寸的页面，上来就全局缩放，拿起设计稿就可以写代码了。要求高又想灵活，还会怕构建的那一点点麻烦吗？rem方案走起。兼容性不需要考虑，那vw方案直白又优雅不试试看吗？方案没有优劣之分只有合适与否。
最后，如果有说得不对的地方，还望指正。