把为PC端设计的网页展示到移动端浏览器上，也许第一个面临的就是设备宽度不够带来的排版错乱问题，为了让页面在不同尺寸的设备上都能合理排版显示，我们需要做一些适配措施。

前置知识

1. 设备的一些物理属性

image.png

• 屏幕尺寸：屏幕对角线的长度
• 设备像素：设备像素是物理概念，指的是屏幕的发光点
• 屏幕分辨率是指屏幕的像素点数。分辨率2400*1080指有2400*1080（= 2592000）个像素点
• PPI（Pixels Per Inch）是像素密度（Screen density）的单位，指每英寸的像素数量。屏幕尺寸和分辨率已知，（根据分辨率计算对角线上的像素数量 / 屏幕尺寸），就能计算出像素密度

2. 设备独立像素（device-independent pixel，简称DIP或DP）

设备独立像素是与设备无关的逻辑像素，【独立于设备】用于【逻辑上衡量尺寸】的单位，这样我们就【不需要关注设备的物理分辨率】了
我们在web开发布局时使用的px都是逻辑像素

• 当我们在布局时将一个元素设置为100px（不管屏幕分辨率和尺寸是多少）
  —— 如果这个设备的视口宽度是100dp（也就是设备提供给你的这个视觉窗口内能显示的逻辑px值是100），则这个元素显示的宽度刚好充满屏幕
  —— 如果这个设备的视口宽度是200dp，则这个元素显示的宽度为屏幕的一半

• 从上面可以看出px是个相对单位，即使元素都设置为100px，显示出的物理尺寸也可能是不同的。

3. DPR（设备像素比，devicePixelRatio ）

我们布局时使用的是逻辑像素，设备显示时需要将逻辑像素转换为实际的物理像素。DPR就描述的是设备物理像素与逻辑像素之间的转换关系：

设备像素比（DPR）：window.devicePixelRatio = 物理像素 / 逻辑像素。

• 当像素比为1:1（DPR=1）时，即使用1个物理像素显示1个CSS像素；

• 当像素比为2:1（DPR=2）时，使用4个物理像素显示1个CSS像素；

  
  
  dpr.png

<略>了解了物理像素、逻辑像素、DPR之后，我们知道影响元素物理尺寸的是：元素所设置的px值、dpr、ppi：px值和dpr决定了显示元素所使用的物理像素数量，再由ppi值（每英寸的像素数量）计算物理显示尺寸

4. <略>PC端浏览器视口的逻辑宽度

image.png

• 浏览器视口的逻辑宽度与我们调整的显示器分辨率和缩放值有关。上图配置，浏览器全屏时视口宽度为 1920 / 1.5 = 1280dp。如果我们将缩放调至100%，视口宽度为1920dp

• 浏览器缩放，不断放大时，元素显示的物理尺寸变大，说明显示1px所用的物理像素在变多，即dpr值在变大，而且视口的逻辑宽度在变小。下图中可以看到这种改变：

  
  
  dpr.gif

移动端适配1——viewport

1. 布局视口

• layout viewport，这个视口就是HTML页面布局的区域，开发者可以自定义它的宽高（主要是加宽），使得原本为PC端设计的页面结构不会在移动设备上被破坏。用户可以在视觉视口(visual viewport，手持设备屏幕的可视区域)中拖动或者缩放网页，来获得良好的浏览效果。使用viewport meta标签，可以创建一个虚拟的布局视口

• 移动设备上的浏览器会给viewport设置默认的尺寸，常见宽度为980px和1024px。可以通过document.documentElement.clientWidth查看。

• 因为移动设备的默认布局视口往往大于设备逻辑宽度，此时就会在横向出现滚动条才能完整的容纳页面。例：在逻辑宽度为375px的设备上浏览网页：

  
  
  不设置viewport，默认宽度.gif

2. 理想视口

移动端浏览器为viewport设置默认尺寸虽然不会排版错乱，但是有滚动条问题

理想视口，最理想的视口大小——用户无需缩放或滚动就可以浏览横向的全部内容。它只是一种概念，用于指导开发者设计最理想的页面大小，它的宽度应为设备逻辑宽度。

移动端适配的第一步，将视口设置为理想视口，这时我们需要能自己定义视口大小：

3. 自定义viewport的尺寸

<meta name="viewport" content="">

• viewport 标签只对移动端浏览器有效，对 PC 端浏览器是无效的

• <meta name="viewport" content="width=device-width">将viewport宽度设置为设备逻辑宽度，达到理想视口：
  

  image.png

• <meta name="viewport" content="initial-scale=1">也能将viewport的宽度设置为设备逻辑宽度。因为缩放是相对于 ideal viewport来进行缩放的，当缩放值为1的时候，就得到了 ideal viewport了。

• 为什么同时写width=device-width, initial-scale=1
  

  image.png

• 同时设置这两个属性还有一个原因：如果设置了viewport宽度大于设备逻辑宽度，如果不设置initial-scale，照理来说会出现横向滚动条，chrome devTools下模拟是有滚动条的，但是手机上测试没有，它会自动计算一个缩放值，缩放至不出现横向滚动条的状态，导致页面内容显示很小，所以还是需要设置initial-scale来覆盖这种默认行为，不要自动缩放，而是【让它正常出现滚动条】。

视口宽度设置为800，没有出现滚动条，而是自动缩放	对比width设置为device-width

• 如果同时设置initial-scale和width，而且有冲突？
  则会取较大的值。
  <略>例如当设备逻辑宽度为375px时，设置initial-scale为3.0，则viewport的宽度为375px / 3 = 125px；（initial-scale = 设备逻辑宽度 / viewport宽度， initial-scale设置的越大，viewport的宽度就越小）。比如同时设置了width为400，则viewport的宽度为400px

将viewport设置到理想视口，使用户不需要进行拖动和缩放，是在移动端浏览网页获得良好体验的第一步

移动端适配2——媒体查询

rem和vw的方式都是等比缩放元素，但是移动设备越来越大并不是为了让元素越来越大，而是为了展示更多的内容。当设备尺寸差别过大可能布局设计已经不一样了，不再是单纯缩放，这时就需要使用 媒体查询

@media not|only mediatype and (mediafeature and|or|not mediafeature) {
  CSS-Code;
}

移动端适配3——相对单位之 rem

保持页面设计结构不变，大屏时让元素显示的更大，小屏则尺寸小一点，是适配各种设备的一种方法，使用rem能便捷地达到这种效果

• rem也是相对单位，相对于根元素(html)的font-size值来计算，假如根元素的字号为20px，则1rem为20px

:root { font-size: 20px; }

1. 如何根据设计稿来使用rem？

1. 先不考虑ui设计稿的整体尺寸，将设计稿上的1rem视为100px（因为100方便换算，不设置为10px的原因：chrome不支持小于12px的字号），也就是说设计稿上根节点font-size为100px
2. 将设计稿上元素尺寸换算为rem：假如设计稿上某元素字体为20px，则换算为0.2rem，那么在开发时，任何设备，这个字体设置时都是0.2rem
3. 当我们能把设计稿上的px都换算为rem，就只需要关注在各种设备上将根节点的字号设置为多少px
4. 以我们移动端ui设计稿为例，宽度为750px，1rem视为100px。当设备逻辑宽度为375px，这个设备上1rem = 375 / (750 / 100) = 50px

5. 需要js动态获取当前设备逻辑宽度，计算根节点的font-size值

   
   
   移动端.png

2. 是把设计稿上所有px都转成rem吗？

• rem只是我们工具箱中的一个，对于需要适配屏幕等比缩放的元素可以选用 rem 作为单位，不需要等比缩放的元素可以依旧选用其他单位。
• 这需要我们自己分辨，例如对font-size使用rem，对border使用px，对padding、margin、border-radius等使用em，声明容器的宽度用百分比等。当然这都不是绝对的

3. 使用插件将px换算成rem

• 虽然将1rem视为100px已经便于换算，但毕竟还是多了一步计算，最好可以直接把设计稿上的px值拿来直接用！
• 我们移动端就使用了postcss-pxtorem插件，以1rem为100px为基准将代码中的px值转换成rem，这样开发时就能直接用设计稿上的px值了。
  
  配置.png

移动端适配4——相对单位之 vw

vw和vh是相对于viewport的单位，也能实现【设备宽度不同时，网页元素宽高等比缩放】的效果
1vw = 1% viewport width
1vh = 1% viewport height

1. 换算

• 计算逻辑：假如设计稿宽度750px，那么30px则换算为 30 / 750 * 100 = 4vw，不需要关注各种设备实际的vw是多少
• 插件：手动计算显然过于麻烦，postcss-px-to-viewport 同样可以自动将px转换为vw（配置viewportWidth为设计稿的宽度），这样就能在开发时直接使用设计稿上的px值了

2. 与rem的对比

• 如果使用rem：px → 换算成rem → 计算不同viewport下根节点的font-size
• 如果使用vw：px → 换算成vw

所以，使用vw比rem方便之处在于——这是个纯css方案，不需要使用js去关注当前设备的vw值。

<略>3. 100vh有点方便
我们总会遇到这种场景：底部按钮固定，上方表单区域滚动显示：

        :root {
            --height: 98px;
        }

        .form {
            height: calc(100vh - var(--height));
            overflow: auto;
        }

        .btn {
            height: var(--height);
        }

        .container {    
            height: 100vh;
            display: flex;
            flex-direction: column;
        }

        .form {
            flex: 1;
            overflow: auto;
        }

        .btn {
            height: 98px;
        }

<略>4. vw和vh混用可能会导致元素变形

• 以750x1334的设计稿为例，假如元素是一个30 x 30px的正方形
• 如果网页的vw和vh分别是375px x 667px（iPhone6的理想视口），则此元素宽为30 / 375 * 100 = 8vw，高为30 / 667 * 100 ≈ 4.498vh
• 将元素宽高设置为8vw和4.498vh
• 如果网页的vw和vh分别是414px x 896px（iPhone XR的理想视口），按照8vw和4.498vh计算，这个元素的尺寸为33.12 x 40.3px，就不是一个正方形了，也就是会发生变形，所以建议不要混用vw和vh

5. 兼容性

最后

1. 微信小程序的rpx

image.png

微信小程序规定所有设备上逻辑宽度都是750rpx。设计师只要按照iPhon6的750*1334进行设计，开发者可以将设计稿中的px以1:1直接替换为rpx，不再需要自己考虑自适应的问题

image.png

• 使用rem，是开发者根据设备逻辑宽度和设计稿宽度算出根节点的font-size值，即1rem为多少px作为基准
• 使用rpx，是小程序根据设备逻辑宽度和自己规定的750rpx算出1rpx为多少px作为基准，省去了我们自己去计算基准值的步骤。

2. 移动端1px问题

当设计师要求边框宽度为1px（750x1334px的设计稿），开发时设置为0.01rem或者1px时，那么高dpr设备中看这个边框，会比在设计稿中看起来要粗。

<略>这里所说的border更粗，是分别看设计稿和设备上的border和其他元素的比例，而不是去比较2个不同dpr的设备上显示1px border的物理尺寸
<略>不同的浏览器处理小于1px的方式不同，有些采用四舍五入，有些大于某个值展示1px否则就不展示，有些只是线条的颜色变浅了，从视觉上看就变细了

• 边框设置为0.01rem，在逻辑宽度为375px的设备上计算为0.5px（根元素字号50px），如果设备将0.5四舍五入为1px
• 或者由于设备可能不支持小于1px的值而直接设置border-width: 1px

也就是说，设计师要求的1px是使用1排物理像素点的宽度，而开发时设置的1px是使用1排逻辑像素，而在高dpr设备中，显示1px会使用多个物理像素点，实际上我们使用了多排物理像素来显示这1px

image.png

1.1 媒体查询
在高dpr设备中再使用小于1的值

.border {
  border: 1px solid #fff;
}

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

但这种方法只在ios上支持，安卓上小于1px的可能会四舍五入或当做0处理。所以出现了第二种方式：

1.2 伪元素模拟边框 + scale缩放
为伪元素设置1px的边框，在此基础上再利用transform: scale()缩小，避免直接使用小于1px值时各设备兼容性处理不同。

.border { position: relative; }
.border::after {
  content: "";
  position: absolute;
  top: 0;
  left: 0;

 /*---------注意这里----------*/
  box-sizing: border-box;
  width: 200%; /* 因为之后要缩小到0.5 所以初始尺寸先放大 */
  height: 200%;
  border: 1px solid #000;
  transform: scale(0.5);
  transform-origin: top left;
 /*--------------------------*/
}

dpr为1的设备其实只需要正常使用1px，不需要缩放；dpr为2时scale(0.5)，dpr为3时应scale(0.3333)。可以配合媒体查询在不同dpr时设置不同的缩放值

:root {
  --borderScale: 1;
}

@media only screen and (-webkit-min-device-pixel-ratio: 2) {
  :root {
    --borderScale: 0.5;
  }
}

@media only screen and (-webkit-min-device-pixel-ratio: 3) {
  :root {
    --borderScale: 0.3333;
  }
}

.border { position: relative; }
.border::after {
  /* ... */
  transform: scale(var(--borderScale));
  /* ... */
}

这种方法的缺点是对于已有伪元素的元素需要多层嵌套。
在uView框架中也使用了缩放来处理线条：

image.png

image.png

3. 小数问题

根据rem或vw去计算时，都会出现小数点问题，插件配置时给我们提供了小数位精度的选项，但如果需要展示小于1物理像素的部分，是无法精确处理的

4. 刘海屏

5. 1px → 0.667px

开发过程中遇见设置border为1px而实际computed style为0.667px，后来发现是显示器分辨率导致的，但只有border属性有这个问题

- image.png	- image.png