单屏页面响应式适配玩法
source link: https://aotu.io/notes/2018/10/22/Responsive-single-screen-design/?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
首先瞅一下效果图（GIF有点大，可能加载有点慢~）
接着就是思考怎么做，我的想法如下图。
把公共的 页头 、 页脚 、 导航栏 、 边框 放到最顶层，比方说设置层级为 999 ，其他每个独立页则放在下面，然后切换页面的时候更新独立页的层级以达到效果图的效果（当然不能超过最顶层）。
适配
上面的方式已经把效果做出来了，接下来就是响应式适配了。
1、Mac OS + Chrome
先考虑一下我自己的系统及显示器，
MacBook Pro 1440 x 900 + 外设 hp 1920 x 1080
也就是说 Chrome 的网页可视区高度大概为： 900(或1080) - 180 = 720px
180 = 60 + 20 + 100
60: MAC 桌面程序坞动态尺寸，60 可能是我常用的尺寸吧，那就先这个 20: MAC 桌面最顶部 icon 放置栏高度 100: Chrome 标签页高度 + 地址栏高度 + 书签栏高度
2、Windows + Chrome
然后我们再看看 Windows + Chrome 的情况，以 1366 x 768 为例，
Chrome 的网页可视区高度大概为 768 - 150 = 618px
150 = 40 + 110
40: Windows 桌面底部程序坞尺寸 110: Chrome 标签页高度 + 地址栏高度 + 书签栏高度
3、总结上面两点
Safari
4、主流系统分辨率尺寸
然后我们看下当前主流系统及分辨率有哪些
PC & MAC & Chrome
常用 1280 x 800 1366 x 1024 (IPad Pro) 1440 x 900 1680 x 1050 1600 x 900 1920 x 1200 2560 x 1440 更高忽略 2880 x 1620 3200 x 1800 5120 x 2880
PC & Windows & Chrome （或 PC & MAC & Chrome & 外设显示器）
1280x 720/1024 1366x 768 1440× 900 1600x 900 1920x 1080
Mobile & Android
360 x 480 412 x 732 待补充
Mobile & IOS
IPhone 6: 375x 667 IPhone6Plus: 414x 736 IPhone X: 375x 812
不上不下的 IPad:
768x 1024
5、分析
我们以宽度 1024 及以下算作移动端，以上算作 PC 端，所以两种选择
- 移动端适配一个移动端页面，PC 端适配一个 PC 端页面。
- 设计之初就想好一个页面适配两端，当然这个设计稿需要比较符合适配两端的条件。
6、别人适配是怎么做的？
贴几个录制的 GIF，体积有点大，耐心~
所以，单屏页面最好页面内容言简意赅，设计层面倾向于水平垂直都居中的情况，是最适合做好这个页面的，并且在各种尺寸变化的情况下能比较良好地展示UI，且开发成本也比较合理。
7、自身情况及实现
我们是分两个页面做的，先看一下 PC 端设计稿
结合动画的展现形式，其实并不是很理想做响应式，但还是要适配。
本来想用 rem 做适配的，但是 rem 需要些写很多个匹配，即下面的代码
@media all and (max-width: 1024px) {
html, body {
font-size: 10px;
}
}
@media all and (max-width: 1366px) {
html, body {
font-size: 12px;
}
}
// 1680 1920 2560 等
然后有个问题就是， @media 是根据 width 的变化来匹配的，完全按照桌面分辨率来显示是没问题的，不过高度随便调节一下（变小），而宽度还是很宽，这时候页面底部的部分文本就会溢出被隐藏掉。
我们不需要考虑更低端的浏览器，所以可以使用比较前沿的特性，如 pointer-events 等特性。
所以使用 vh 做适配方案， vh 是什么单位详情可以看下这篇文章，这里做个简单介绍。
vw: 相对于浏览器可视区的宽度 1vw = 浏览器可视区宽度的 1% vh: 相对于浏览器可视区的高度 1vh = 浏览器可视区高度的 1%
也就是说 100vh 实际上等于浏览器可视区的高度，所以 px 与 vh 的换算我们举个例子说明一下（一个很简单的数学换算）。假设浏览器可视区高度为 720px ，某个元素的宽度为 300px ，那应该写成多少 vh 才与 300px 相等呢，如下。
300÷ (720 ÷ 100) ≈ 41.666
比如设计稿为 1920x1080 （单屏设计高度应该更小一点，如适配第一节所说），可以写个 CSS 预处理函数，这样方便直接使用设计稿的尺寸，以 Sass 为例如下。
@function vh( $value ) {
@return ( $value / 1080 / 100 ) + vh;
}
或者
@function vw( $value ) {
@return ( $value / 1920 / 100 ) + vw;
}
然后， 300px 可以无缝写成 vh(300) 或 vw(300) 。
so… 对于我们的页面选择 vh 一举两得，不用写很多 rem 匹配，也不会出现溢出的问题。
因为高度变矮，内容的尺寸会随之变小，而页面是 1190 宽，水平居中布局，所以当只改变浏览器宽度的情况下，不会出现宽度变化溢出问题（除非分辨率超大，然后高度居很高，只把宽度缩很小的情况，这个下面会说到）。写完后在上面列举的主流分辨率下一一测试通过。
看看效果（当然这个是最终效果，只改变宽度的拉伸适配在最后会说）：
8、特殊场景
这里就是刚刚说到的 分辨率超大，然后高度居很高，只把宽度缩很小的情况 ，因为设计稿是长宽比例为横向矩形，所以明显与用长宽比为竖向的矩形来看页面是背道而驰的。
委屈委屈，但还是要兼容下，至少看起来要显示正常。
8.1、尝试 rem + vh 方案
一开始想的是 rem + vh 结合使用，根元素 html 使用 vh ，其他单位则使用 rem ，然后找到有问题的宽高比，通过 @media 方式设置 html 为 vw 来达到适配。
事实是， rem 缩小到一定值就不会再缩小了，这个跟浏览器对字体大小限制为最小 12px 一样，看个例子。
根字体小于 12px 以后， rem 对应的值则都是设置的倍数乘以 12 ；设置根字体为 vh, vw 单位同理， rem 会在 vh, vw 换算达到 12 以后就不再改变。
PPPS: 是不是有点坑，应该字体的属性最小值为 12，而其他属性的值没有控制才对
所以，如果使用 rem + vh 方案，在界面缩小到一定尺寸后继续缩小，有些值达到最小值固定不变，而有些值仍在变小，UI 的展示就变得混乱。
8.2、落地方案， vh + vw + JavaScript 计算
而直接在元素的属性值上设置为 vh 或 vw ，所有的值都会实时变动，没有最小值（除了属性为字体有最小值），这样就最大程度减少 UI 变乱的情况了，除非缩到很小很小，那就…（此处省略 1000 个字）。
于是乎，现在的想法是
- 在原来以
vh为基础的情况下，拷贝所有带vh单位的代码，把vh换成vw，当然这些改动都在一个比如叫.vw-mode的类下面，基本上可以无缝迁移，只需替换vh函数名即可。 - 把
.vw-mode下的内容设置为上下居中。 - 通过
JS计算，当可视区比例为竖向比例时，则在顶层元素加上.vw-mode类名，当比例为横向比例时，则去掉.vw-mode类名。
大致的代码如下
css
.homepage.vw-mode {
font-size: vw(14);
.com-width {
width: vw(1190);
}
.hp-header {
padding-top: vw(30);
// ...更多代码
}
// ...更多代码
}
js
this.resizeHandler = ()=> {
const clientWidth = document.documentElement.clientWidth
const clientHeight = document.documentElement.clientHeight
// 当长宽比为竖向比例时
const isVerticalRatio = clientWidth / clientHeight < 1370 / 890
homepageElem.classList[isVerticalRatio ? 'add' : 'remove']('vw-mode')
}
this.resizeHandler()
window.addEventListener('resize', this.resizeHandler)
最后的结果就是上面那个 GIF 效果图了。
Recommend
-
54
本文原文发表于2016年我的github，但是直到现在为止还有很多童鞋问我相关概念，于是整理下再分享一下。 原文链接：github.com/sunmaobin/s… 一、基础概念 在了解如何做H5页面适配前，大家都应该把移动端涉及的一些概念搞明白，比如：dp
-
5
宜家和响应式页面设计 没错，就是那个家具品牌宜家，看似和响应式页面设计毫不相干，但事实上IKEA却在官方站点上做了相当彻底的响应式——近期，宜家官网居然改版了，从之前的老站点换成了现在的全新设计的响应式页面，这不由的让我再次...
-
7
by zhangxinxu from http://www.zhangxinxu.com 本文地址：http://www.zhangxinxu.com/wordpress/?p=1937
-
11
改善页面性能 - 如何监控卡顿和响应延迟背景为了提供给前端者监控页面性能的能力，W3C 定义了一系列相关 API，在这里统称为 Performance API。目前使用较多的应该是 PerformanceTiming，但是除了该 API，新的 W3C 草案及 WICG 提案定...
-
7
StatusCodePagesMiddleware中间件与ExceptionHandlerMiddleware中间件类似，它们都是在后续请求处理过程中“出错”的情况下利用一个错误处理器来接收针对当前请求的处理。它们之间的差异在于对“错误”的认定上：ExceptionHandlerMiddleware中间件所谓的错误就是抛...
-
1
当我们把 Asp.Net Core 程序部署在 Nginx 后面时，通常来说，不会使用顶级目录，而是使用二级目录，访问方式类似：http://{DOMAIN}/{BASEPATH}/WeatherForecastNgix 配置假...
-
2
网页的设计的样式都由css控制, 我们的css大小单位,一般用 px,或rem,或vw,vh. 由px控制的大小是固定的,不具有响度式的. 响应式设计一般由两种方案实现. 一.rem方案. 实现方法 : 1.head中加
-
0
为了展示良好的页面效果，我们需要考虑页面适配的问题，如果你还在纠结页面适配规则如何选择，不妨看看本文关于页面适配给出的一些方法和选择，希望能给你一些启发。
-
6
1.何为页面适配及必要性页面适配，简单来说就是需要考虑页面在不同的屏幕尺寸中展示出来的对应效果。其最终目的，就是为了让我们设计的页面在每个屏幕尺寸下，都有比较良好的显示效果。如果不考虑页面适配，最终的页面呈现效果就会大打折...
-
2
V2EX › 程序员 看了一圈显示器，还是 mbp16 单屏得了
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK