笔者从毕业开始做前端到现在，90% 的项目是移动端打交道，所以当简历上写了“移动H5”几个字时，必会被问到自适应方案与高清方案
”自适应“讲的是一套UI（例如750*1334），在多端下展示近乎一样的效果；而”高清“是因为 DPR 提升而所做的各种精度适配
这篇文章讲讲笔者理解的自适应方案和高清方案
先说结论自适应方案
- rem 适配思路 选择一个尺寸作为设计和开发基准定义一套适配规则，自动适配剩余的尺寸特殊适配效果给出设计效果 属于历史产物，CSS 视窗单位未得到主流浏览器的支持原理 根据视窗宽度动态调整根元素 html 的 font-size 的值把总宽度设置为 100 份，每一份被称为一个单位 x，同时设置 1rem 单位为 10x 缺点 需要加载 js 脚本，而且根据设备的视窗宽度进行计算，影响性能 影响力：从2015年出世至今，在 H5 适配领域占据一定比例相关技术库：flexible、px2rem
- vw 适配思路（如上）原理 利用 CSS 视窗的特性，总宽度为 100vw，每一份为一个单位 1vw，设置 1rem 单位为 10vw 缺点 因为是根据视图的宽度计算，所以不适用平板和PC 影响力：2018年出的方案，目前 H5 适配主流相关技术库：postcss-px-to-viewport
- px calc clamp 适配思路 根据 CSS 的新特性：css变量、calc()函数、clamp()、@container函数实现 特点 解决了rem、vw布局的致命缺点：失去像素的完美性，而且一旦屏幕低于或高于某个阈值，通常就会出现布局的移动或文字内容的溢出大漠在2021年提出，最先进，但没看到大厂使用（clamp函数浏览器支持率暂且不高），具体可以看看大漠的这篇：如何构建一个完美缩放的UI界面 缺点 因为方案先进，暂没看到大厂使用
高清方案
- 1 像素问题的解决方案
- 不同 DPR 下图片的高清解决方案
综上，自适应方案是解决各终端的适配问题，高清方案是解决Retina屏的细节处理
写在前面在说移动端适配方案之前先整明白一些技术概念
设备独立像素设备独立像素（DIP）=== CSS 像素 === 逻辑像素，在 Chrome 中能直接看到 375* 667
chrome中查看css像素
当你看到设备独立像素时，不要慌，它表示 CSS 像素，而它的长宽就是在 Chrome 中所查到的。可这样记忆，“设备独立像素”，字数长，文绉绉就是 CSS 像素，也是理论上人为给定的指标，也叫逻辑像素
物理像素物理像素可以理解为手机厂商在卖手机时宣传的分辨率，即物理像素 = 分辨率，它表示垂直和水平上所具有的像素点数
也就是说设备屏幕的水平方向上有 1920 像素点，垂直方向有 1080 像素点（假设屏幕分辨率为1920*1080），即屏幕分辨率表示物理像素，它在出厂时就定下来，单位为 pt，1pt=0.376mm
手机分辨率
物理像素，又被称为设备像素，即表示 设备像素 === 物理像素。可这样记忆，设备在物理世界能测量的长度
DPR（Device Pixel Ratio）而设备像素比（DPR）是什么？
DPR = 设备像素 / 设备独立像素，它通常与视网膜屏（Retina 屏）有关
以 iPhone7 为例子，iPhone7 的 DPR = iPhone7 物理像素 / iPhone7 设备独立像素 = 2
宽 1334 / 667 = 2
高 750 / 375 = 2
得到 iPhone7 的 DPR 为 2，也就是我们常说的视网膜屏幕，而这就是营销术语，它就是因为技术的进步，使得一个 CSS 像素塞入更多的物理像素
营销术语还有哪些：农夫山泉的大自然的搬运工、元气森林的“気”
笔者是这么记忆的：
- CSS 像素（设备独立像素）就像一个容器，以前是一比一塞入，所以 DPR 为 1，后来技术发展进步了，一个容器中能塞入更多的真实像素（物理像素）
- DPR = 设备像素 / 设备独立像素
- DPR = 物理像素（真实）/ CSS 像素（虚的）
在视网膜屏幕中，以 DPR = 2 为例，把 4（2x2）个物理像素当一个 CSS 像素使用，这样让屏幕看起来更加清晰（精致），但是元素的大小（CSS像素）本身不会改变
DPR对比
随着硬件的发展，像 iPhone13 Pro 等手机的 DPR 已经为 3，未来 DPR 突破 4 不是问题
说回来，DPR 为 2 或 3 会有什么问题？我们以 CSS 为最小单位来写代码的，展示在屏幕上也是以 CSS 为最小单位来展示，也就是说在 DPR 为 2 时，我们想要模拟 1 单位物理像素是做不到的（如果浏览器支持用 0.5px CSS 的话，可以模拟，但是DPR为 3 呢，用 0.333px？）；又因为手机的设备独立像素（CSS 像素）固定，使用传统静态布局（固定 px）时，会出现样式的错位
iPhone 5/SE: 320 * 568 DPR: 2
iPhone 6/7/8: 375 * 667 DPR: 2
iPhone 6/7/8 Plus: 414* 736 DPR: 3
iPhone X: 375 * 812 DPR: 3
所以我们要适配各终端的 CSS 像素以及不同 DPR 下，出现的 1 像素问题、图片高清问题等。随着技术的发展，前端们摆脱了 IE 的兼容，同时陷入了各大手机品牌的兼容沼泽
自适应方案Rem 布局——天下第二简介：rem 就是相对于根元素 html 的 font-size 来做计算
与 rem 相关联的是 em：
em 作为 font-size 单位时，其代表父元素的字体大小，em 作为其它属性单位时，代表自身字体大小
rem 作用于非根元素时，相对于根元素字体大小，rem 作用于根元素字体时，相对于其初始字体大小
本质：等比缩放，是通过 JavaScript 来模拟 vw 的特性
假设将屏幕宽度平均分为 100 份，每一份的宽度用 x 表示，x = 屏幕宽度 / 100，如果将 x 作为单位，x 前面的数值就代表屏幕宽度的百分比
p { width: 50x } /* 屏幕宽度的 50% */
如果想要页面元素随着屏幕宽度等比变化，我们就需要上面的 x，这个 x 就是 vw，但是 vw 是在浏览器支持后才大规模使用，在此之前，js rem 可模拟这种效果
之前说了，rem 作用于非根元素时，相对于根元素字体大小，所以我们设置根元素单位后，非根元素使用 rem 做相对单位
html { font-size: 16px }
p { width: 2rem } /* 32px */
html { font-size: 32px }
p { width: 2rem } /* 64px */
问题来了，我们要获取到一个动态的根元素 font-size，并以此变化各个元素大小
有趣的是，我司两个项目目前的做法是通过媒体查询设置根元素，分为四档，默认16px
笔者对这种做法表示不理解，原开发人员说我们这套运行了6年，UI适配也没人说什么问题。这里就有个疑问了，真的如他所说UI适配的很好吗，”媒体查询根元素 rem“也能适配好吗？是否完美呢？
后续笔者也会在 demo 中展示这种做法
但是根元素的 font-size 怎么变化，它不可能一直是 16px，在中大屏下还可以，但是在小屏下字体就太大了，所以它的大小也应该是动态获取的。如何让其动态化，就是上文所说，让根元素的 font-size 大小恒等于屏幕宽度的 1/100
html { font-size: width / 100};
如何设置 html 的字体大小恒等于屏幕宽度的百分之一呢？可以通过 js 来设置，一般需在页面 dom ready、resize 和屏幕旋转中设置
document.documentElement.style.fontSize = document.documentElement.clientWidth / 100 'px';
flexible 源码就如以上思路写的
我们设置了百分之一的宽度后，在写 css 时，就需要利用 scss/less 等 css 处理器来对 css 编译处理。假设给出的设计图为 750 * 1334，其中一个元素宽度为 200 px，根据公式：
width: 200 / 750 * 100 = 26.67 rem
在 sass 中，需要设置设计图宽度来做换算：
@use 'sass:math';
$width: 750px;
@function px2rem($px) {
@return #{math.div($px, $width) * 100}rem;
}
上面编译完后
div {width: 26.667rem}
在不同尺寸下，它的宽度不同
机型 尺寸 width iPhone 5/SE 320 * 568 170 * 170 iPhone 6/7/8 375 * 667 200 * 200 iPhone 6/7/8 Plus 414 * 736 220.797 * 220.797 iPhone X 375 * 812 200 * 200
效果如下（特意说明：图中演示的是引入 flexible 库，它的根元素的 font-size 为屏幕的 1/10）
