Css-移动端适配总结

前言

工做之后，大部分的业务工做都是基于移动端H5的，开发过程当中学习了不少东西，遇到过许多问题，诸如rememcss pxdevice px等，本文纯属我的的概括总结，若有问题，请指出亲喷~

PC端

本文主要是讲解移动端的响应式布局， 可是在真正进入以前， 先了解一些概念。

device px（设备像素）和 css px（css像素）

一般在PC端上面，咱们并不须要考虑设备像素和css像素之间的差异，以目前的pc来看，1个设备像素一般等于1个css像素。可使用screen.width/height来获取咱们屏幕的宽高设备像素。

screen.width // 1920
screen.height // 1080

若是你给一个元素的宽度为width: 192px; 那么你的屏幕上(假设你的屏幕宽度像素为1920)能够在一行上显示10个该元素。原理则是由于咱们的PC中1个设备像素等于1个css像素。

当用户放大或者缩小屏幕时（按住ctrl+滚动鼠标轮，也就是改变zoom值），则有所不一样。此时，咱们的设备像素仍然没有改变，仍是1920*1080，css像素的数量也没有改变，可是css像素大小变了。 假设放大到200%， 那么1个css像素就等于两个设备像素， 以此类推。

如下是引用ppk大神的三张图片， 下面深蓝色为设备像素， 上面浅蓝色为css像素

正常状况下：

缩小时：

放大时：

screen.width/height 和 window.innerWidth/innerHeight

screen.width/heihgt取的是屏幕的宽高，单位是是css像素。

window.innerWidth/innerHeight取的是网页区域的宽高， 单位是css像素。

当你改变zoom值时， screen不会改变， innerWidth/height会改变。

viewport的概念

viewport是一个限制html元素的功能， 能够理解为html元素的上一层元素。听起来有点难以理解， 下面讲一个例子：

假设， 你给某个div元素设置了width：50%的样式后， 当你缩小放大浏览器的时候，你会发现div元素老是占据了50%的宽度，咱们知道，宽度百分比是依赖它的包裹元素（假设是body）， 那么问题就回到了body的宽度身上。一般在没有设置宽度的状况下，全部块级元素都占用其父级宽度的100%。因此body和html元素同样宽。那么html元素有多宽呢，默认状况下它和浏览器窗口同样宽，这也就是为何div老是占据浏览器宽度的50%，而html元素则是受限于viewport(和viewport占据同样的宽度)，换句话说，viewport彻底等于浏览器窗口，并且它不是HTML语言元素，因此你没法经过使用css对其进行影响。

咱们能够经过document.documentElement.clientWidth/clientHeight来获取viewport的宽高， 它的单位是css像素。

clientWidth/Height 和 window.innerWidth/innerHeight

上面二者都可以获取网页区域大小， 可是他们之间仍是有区别的。 前者不包含滚动条， 后者包含。

html元素的大小

咱们能够经过document.documentElement.offsetWidth/offsetHeight来获取html元素的宽高， 它的单位是css像素。

event事件和媒体查询

event的三对属性：

• pageX/Y: 给出CSS像素中相对于html元素的坐标
• clientX/Y: 给出CSS像素中相对于viewport的坐标
• screenX/Y: 给出设备像素中相对于屏幕的坐标

媒体查询：

• 基于viewport（documentElement .clientWidth/Height）

@media all and (max-width: 400px)

• 基于屏幕（screen.width）

@media all and (max-device-width: 400px)

Mobile

在默认状况下，通常来说，移动设备上的viewport都是要大于浏览器可视区域的，这是由于考虑到移动设备的分辨率相对于桌面电脑来讲都比较小，因此为了能在移动设备上正常显示那些传统的为桌面浏览器设计的网站，移动设备上的浏览器都会把本身默认的viewport设为980px或1024px（也多是其它值，这个是由设备本身决定的），但带来的后果就是浏览器会出现横向滚动条，由于浏览器可视区域的宽度是比这个默认的viewport的宽度要小的。下图列出了一些设备上浏览器的默认viewport的宽度。

如下是关于各浏览器的viewport

三个viewport

前面介绍了viewport的概念， 可是在移动端的时候， viewport并不那么容易理解， ppk在移动端提出了三个viewport的概念。

Layout viewport
也就是布局viewport，即默认的浏览器viewport ， 而且能够经过document.documentElement.clientWidth 来获取。

图片引用自深刻理解viewport

visual viewport
layout viewport 的宽度是默认的浏览器viewport，因此咱们还须要一个viewport来表明可视区域的大小，ppk把这个viewport叫作 visual viewport。ppk说visual viewport的宽度能够经过window.innerWidth 来获取， 然而我获取的时候发现获得的值是网页区域的值。

图片引用自深刻理解viewport

ideal viewport
有了两个viewport并不ok， 由于咱们既不想让用户滚动滚动条来浏览咱们的网页，也不想用户盯着缩小了的pc网页浏览， 因此有了第三个viewport。 所谓的ideal viewport则是当layout viewport等于屏幕的宽度， 如ip6，它的ideal viewport就是375px。

设置viewport

开发过h5的应该都知道， 咱们常常会把下面这句代码复制到head标签中：

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">

它的做用其实就是设置了ideal viewport。如下是它的6个属性：

key	value
width	设置layout viewport 的宽度，为一个正整数，或字符串"width-device"
initial-scale	设置页面的初始缩放值，为一个数字，能够带小数
minimum-scale	容许用户的最小缩放值，为一个数字，能够带小数
maximum-scale	容许用户的最大缩放值，为一个数字，能够带小数
height	设置layout viewport 的高度，这个属性对咱们并不重要，不多使用
user-scalable	是否容许用户进行缩放，值为"no"或"yes", no 表明不容许，yes表明容许

那么若是咱们想设置ideal viewport， 只须要把width设置成width-device或者把initial-scale设置成1.0就能够了。

前者比较容易理解， 后者设置成1就能够是为何？ 首先要理解设置成1.0就是意味着没有缩放，而这样却能够达到ideal viewport的效果， 那么很明显， 缩放是相对于 ideal viewport来进行缩放的，当对ideal viewport进行100%的缩放，也就是缩放值为1的时候，不就获得了 ideal viewport。

若是两个属性都能设置ideal viewport， 那么当两个属性冲突时怎么解决？

遇到这种状况时， 浏览器会取它们两个中较大的那个值。例如，当width=400，ideal viewport的宽度为320时，取的是400；当width=400， ideal viewport的宽度为480时，取的是ideal viewport的宽度。

css像素和设备像素

在移动端中， 1个css像素并不等于1个设备像素， 而是取决于设备像素比（物理像素（设备像素）/独立像素（css像素）），像Iphone的Retina屏幕， 就有2倍屏（ip6s）、3倍屏(ip6 plus)， 也就是设备像素比的值分别是2和3，即1个css像素等同于4个设备像素或者9个， 如图：

而且， 咱们能够经过window.devicePixelRatio来获取设备像素比dpr。

1px的产生和解决

问题的产生

公司的设计大佬一般给的设计稿是基于ip6s的， 也就是750px（i6s的屏幕是375px，并且是上面说的两倍屏，因此有750个物理像素）。假设设计稿上面有个1px的border，咱们一般直接这样写：

border {
    border: 1px solid #ccc;
}

而后设计审核的时候就被打回来了， 由于设计以为变大了，也就是他以为是2px的线了。

究其缘由，是由于设计稿是750px， 里面的1px实际上在真机只有0.5px，因此就有了著名的1px问题。

问题的解决

1.直接使用0.5px
在iOS8下，苹果系列都已经支持0.5px了，那么意味着在devicePixelRatio = 2时，咱们能够借助媒体查询来处理：著做权归做者全部。

@media (-webkit-min-device-pixel-ratio: 2) {
    .border {
        border-width: 0.5px
    }
}

这种使用简单，可是兼容性不太好。

2.使用border-image或者background
也就是拿一张图片，一半透明，一半是咱们想要的颜色，而后填充上去， 具体的例子就不讲了， 这种基本没啥人会用， 改个颜色还要修改图片，太麻烦了。

3.box-shadow

.box-shadow-1px {
    box-shadow: inset 0px -1px 1px -1px #c8c7cc;
}

这种颜色有阴影， 估计过不了设计大佬的那关。

4.PostCSS的插件postcss-write-svg
直接借助插件帮助咱们实现， 其实也就是postcss帮咱们生成图片而已。

@svg 1px-border { 
    height: 2px; 
    @rect { 
        fill: var(--color, black); width: 100%; height: 50%; 
    } 
} 
.example { border: 1px solid transparent; 
           border-image: svg(1px-border param(--color #00b1ff)) 2 2 stretch;
}

最后Postcss会把对应的css编译出来， 这种兼容性好， 就是依赖于插件。

.example { border: 1px solid transparent; 
           border-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' height='2px'%3E%3Crect fill='%2300b1ff' width='100%25' height='50%25'/%3E%3C/svg%3E") 2 2 stretch
}

5.伪类 + transform 实现
原理是把原先元素的 border 去掉，而后利用 :before 或者 :after 重作 border ，并 transform 的 scale 缩小一半，原先的元素相对定位，新作的 border 绝对定位。

.scale-1px{
position: relative;
border:none;
}
.scale-1px:after{
content: '';
position: absolute;
bottom: 0;
background: #000;
width: 100%;
height: 1px;
-webkit-transform: scaleY(0.5);
transform: scaleY(0.5);
-webkit-transform-origin: 0 0;
transform-origin: 0 0;
}

这种兼容好， 可是会和伪类冲突， 也是我司采用的方式。

6.缩小viewport
原理是使用meta标签中的viewport， 也就是上面所说的设置viewport， 将整个页面缩小0.5倍， 这个主要是麻烦在其余的元素也要跟着放大一倍再缩小， 为了这个小问题而这样， 彷佛有点得不偿失。

然而， 淘宝的flexible方案（rem布局，见下文）帮咱们搞定了这个问题。

flexible和rem

上面提到了flexible和rem的布局方案， 在刚推出的时候， 确实很火， 公司的一些项目目前仍然是采用该方案， 这里简单的说下其原理。

px、em、rem

• px: px在前面已经讲了， 就是一个固定单位。
• em: em做为font-size的单位时，其表明父元素的字体大小，em做为其余属性单位时，表明自身字体大小。
• rem: rem做用于非根元素时，相对于根元素字体大小；rem做用于根元素字体大小时，相对于其出初始字体大小。

/* 做用于根元素，相对于原始大小（16px），因此html的font-size为32px*/
html {font-size: 2rem}

/* 做用于非根元素，相对于根元素字体大小，因此为64px */
p {font-size: 2rem}

flexible rem布局原理
flexible rem布局原理便是把设计稿等比宽的切成100份， 假设每份的单位是x， 那么咱们在布局的时候就能够以x为单位， 将设计稿等比例的放大缩小到对应的屏幕了，这样就不用为各个屏幕作适配。

然而像上面所说的x是不存在的， 不过好在咱们有rem， 只要咱们将rem设置成1x，那么开发过程当中，不就达到咱们的目的了吗？

如何将rem设成1x呢？ 回想一下， 咱们是否是能取得viewport的宽度（document.documentElement.clientWidth），咱们能取得设备像素比（window.devicePixelRatio）, 咱们可以设置html的样式（html.style.fontSize = '...'）， 因此简单的实现方案就有了

document.documentElement.style.fontSize = document.documentElement.clientWidth / 100 + 'px';

固然，flexible并不这么简单，它还对于不一样dpr作了处理， 它帮你处理了2倍屏、3倍屏等状况，经过设置viewport的缩放比，这也就是上面所说的0.5px处理方案之一， 具体的这里再也不赘述， 有兴趣的同窗能够看看原文。

最后，移动端 iOS 8 以上以及 Android 4.4 以上已经有了vw\vh单位， 1vw1vh至关于viewport的百分之一宽/高，也就是咱们上面所说的x单位， 若是你的手机支持该api， 也可使用该单位方案。

为何不用rem方案

依稀记得， 某次使用了rem处理活动页的时候， 被设计大佬驳回了。
大佬认为， 当用户使用更大的屏幕的时候， 他应该能看到更多的内容， 并且设计稿被放大或者缩小的话， 会失去他原来的感受。
因此， 对于rem方案其实可能已经不太适合当前的状况了， 毕竟使用媒体查询和px以及em就能解决各类响应式问题， 虽然效率会比较低下， 而关于这个， 也刚好看到了有人在知乎上提了这么个问题， 有兴趣的能够前去围观。

为何不少web项目仍是使用 px，而不是 rem？

总结

本文可能是概念上的，也参考了许多文章，要真正理解还须要多参考实际项目。

参考&引用

移动前端开发之viewport的深刻理解
A tale of two viewports — part one
A tale of two viewports — part two
Meta viewport
7 种方法解决移动端 Retina 屏幕 1px 边框问题
再谈Retina下1px的解决方案
vh,vw单位你知道多少？
Rem布局的原理解析