V-SW 多终端Web 全适配开发技术研究

吴 睿

(安徽农业大学 经济技术学院，合肥230011)

传统的Web 开发领域发生了多次技术演进，从早期朴素的单网页开发为主，到后来出现了针对不同设备的自适应布局技术、流式布局技术等。 直至响应式开发的提出及流行，基本满足了大多数Web 适配开发的需求。 但主流的响应式多终端Web 适配技术，仍存在诸多的问题及改进空间，针对这些问题，本文进行了深入研究，最终探索出V-SW 组合适配技术来改进当前主流的多终端Web 响应适配技术。

1 当前面临的多终端适配问题

所谓响应式页面设计(Responsive Web Design 简称RWD)，就是在Web 开发时分别为不同的屏幕分辨率设置断点区间，使用media query 媒体查询技术来指定各自不同布局的技术[1]，即页面及其内部元素的宽度，能够随着浏览器窗口的大小自动缩放适配。 如图1 所示。

目前，响应式页面设计(RWD)已然成为最成熟可靠的Web 开发多终端解决技术，当前响应式页面设计的主流就是使用相对字体单位rem 来定义各种元素的尺寸大小以及位置距离，配合float 浮动布局或flexbox 伸缩盒模型来合理排布页面，最后使用media query 媒体查询来作布局自动适配和调整[2]，本项目中简称这种技术为R-MQ 响应式多终端适配技术。

然而这种当前主流技术也并非没有缺陷，这种技术的Web 页面的布局及内容只会在到达临界点时，发生突然的布局、元素尺寸、字体大小的改变。 当拉伸浏览器的时候，会感受到阶段性的变形效果，无法达到顺滑渐变缩放效果，用户体验不是很好。更重要的是，随着各种设备的层出不穷，适配断点的不断增多和变化，使得页面的适配维护成本仍然很高。

图1 响应式页面设计

2 基于vw 视区相对单位布局技术

2.1 基于vw 视区相对单位布局的可用性分析

由于rem 单位的响应式布局存在着大量的适配问题难以解决，与此同时，CSS3 草案中推出的vw 以及viewport 视区相关单位随着时间的迁移和浏览器兼容性的提升，当前使用vw 单位进行Web 设计开发已然变得可行和具有实际意义。 vw 系列视区相关单位，在2012 年查询到的各浏览器完全支持的兼容性仅为27.97%，然而，2019 年通过CSS 属性可用性查询网站caniuse.com 给出了的查询结果，如图2 所示。

从图2 统计数据可以看出完全支持的占93.41%，已完全达到可用和通用的状态。 视区相对单位就是相对于浏览器viewport 尺寸的单位，具体包括vw：视区宽度的百分比值；vh：视区高度的百分比值等具体单位[3]。 视区viewport 所指为浏览器内部的可视区域大小，不包含任务栏标题栏及底部工具栏的浏览器区域，由此可知，100vw 就是整个浏览器视区的宽度。

图2 vw 视区单位兼容性图

2.2 基于vw 视区相对单位布局的适配优势分析

使用vw 单位与使用百分比单位区别在于使用百分比单位时，元素的宽度是相对浏览器宽度计算的，但是元素的高度是无法使用百分比单位的，定义元素的高度也可以使用视区宽度vw 为单位，这样元素的宽高尺寸便可以跟随浏览器宽度发生相应的变化，这正是解决响应式设计中重点难题的关键所在。

与此同时，屏幕越大，文字也应当越大，页面内字体元素以及图片宽度高度也可以使用vw 相对视区单位，这样页面中的文字内容以及图形图像便可以跟随浏览器宽度自动缩放，满足用户的可读性。 因此在Web 开发中使用相对视区单位，具有其特殊的优势：可以实现跟随浏览器宽度变化的等比例缩放图形，并且可以实现完全自动缩放的网页布局及内容[4]。 使用vw 视区相对单位来开发模型页面，关键代码如下：

测试基于vw 视区宽度单位的模型在桌面端1 024∗768 分辨率下显示效果，如图3 所示。

图3 基于vw 单位的模型在桌面端1 024∗768 分辨率下显示效果

然后来测试该基于vw 视区宽度单位的模型在桌面端1 366∗768 直至2 560∗1 440 高分辨率下显示效果，如图4 所示。

图4 基于vw 单位的模型在桌面端2 560∗1 440 分辨率下显示效果

通过模型分析测试，使用了全新的vw 视区单位在常见的桌面端设备及分辨率仿真测试下，随着桌面显示设备屏幕分辨率的加大，即使是上升到1080 p 高清屏乃至2K 甚至4K 超高清屏，页面显示会随之等比例缩放，可以始终看到完整的页面布局及信息，有较为完美的显示效果。 因此使用vw 相对视区单位在桌面端分辨率下，几乎不需要作任何媒体查询适配，使用了极少的代码便完成桌面端的多设备显示适配，工作量大幅减少。 与此同时页面主体使用100 vw 布局能够在各种分辨率下保持浏览器近乎全屏的显示效果，这样便大大增强了用户的Web 浏览访问体验。

同样在移动端使用vw 视区相对宽度单位相比使用px 像素单位及rem 相对字体单位，无须再计算确定不同规格分辨率下的内部元素尺寸，只需划定大致的移动端及桌面端的断点区间即可，没有响应式断点的过渡问题，后期多设备维护量也大大减少，基本实现了后期适配工作的零维护，减少了开发的工作量和代码书写量，优化了Web 页面的加载速度。

3 基于screen.width 的设备查询适配技术

使用基于rem 媒体查询响应式多终端适配技术，媒体查询media query 无疑是当前最为主流的适配技术选择，其主要工作方式是：

media query 媒体查询给Web 开发带来了质的飞跃，使得可以开发响应式页面，无需重复开发多个页面来适配不同的屏幕显示分辨率[5]。 但是研究发现，media query 媒体查询技术也有许多自身的缺陷。

(1)桌面端用户可以通过拉伸浏览器尺寸访问到移动端界面

使用桌面浏览器访问Web 页面时，由于桌面平台用户可以使用鼠标手动拉伸和缩小浏览器尺寸，有些用户在缩小浏览器时访问到临界点以下，但是Web 开发者并不希望用户在桌面端访问到移动端的响应界面，这是由于桌面端和移动端往往使用不同分辨率及尺寸的元素缩略图[6]。 然而，当桌面用户在响应式的桌面端和移动端临界点来回拉伸浏览器尺寸，势必造成高清和低清资源的加载冗余，浪费资源，影响浏览器的工作效率。

而且，桌面端和移动端往往有很多不同的JavaScript 交互逻辑，如桌面端使用click 鼠标点击事件来响应用户的点击行为触发接下来的动作，而移动端使用touch 触摸事件来响应用户在移动设备屏幕上的滑动行为[7]，当桌面用户在响应式的桌面端和移动端临界点来回拉伸浏览器尺寸时，对应加载的JS 文件或代码也要跟着切换，势必造成JS 资源的过多加载和浪费，影响浏览器的工作效率。 并且很容易出现同一个行为对象的click 鼠标点击事件与touch 触摸事件冲突的现象，可能导致出现页面bug 或卡顿延迟响应等不良的用户体验。

(2)移动端浏览器横屏显示时往往会适配到桌面端显示模式

同样地，当使用media query 媒体查询来作响应式适配时，移动端用户访问也有一定的不便。 由于＠media 适配的是屏幕分辨率中的宽度，比如使用＠media screen and (max-width：500 px){...}来适配屏幕宽度在500 像素以下的各种主流移动设备，如一台iPhone6 的屏幕尺寸是375∗667，在用户正常持握下media query 会自动提供给用户500px 以内的移动端显示资源。

然而现在的移动设备往往具备屏幕自动旋转功能，一旦用户在躺卧或其他特殊情形下使用横屏观看的Web 页面，media query 又会自动响应提供给用户500 px 以上的桌面端显示资源。 测试使用media query 媒体查询时移动端横屏显示效果，如图5 所示。

图5 基于media query 适配的模型在移动端375∗667 分辨率横屏显示效果

经过测试，模型在各种移动端分辨率的横屏下显示效果亦保持一致。 此时在移动端横屏模式下加载的资源包括桌面端高清的图像、桌面端的交互JavaScript 文件代码等，这势必造成各种资源的过度加载和用户手机流量的浪费，影响浏览器的工作效率，甚至导致事件冲突、页面bug、卡顿延迟响应等不良的用户体验出现，更重要是在较小的手机屏幕上显示如此多的内容和局部元素，用户很难看清页面的内容，造成不良的用户体验。

所以，当前流行的media query 媒体查询也并非十分完备的响应式解决技术。

screen.width 所指的是设备屏幕的硬件宽度数值，无论浏览器软件被如何拉伸缩放，设备的screen.width始终是保持不变的[8]。 目前，通过screen.width 可以查询获得屏幕宽度，其兼容性已经得到充分保障，如图6所示。

图6 screen.width 兼容性图

通过上述图表分析可知，几乎市面上所有的主流浏览器都是完全支持screen.width 获取屏幕宽度数值的。 使用screen.width 获取的屏幕宽度，与＠media 媒体查询中使用的屏幕分辨率的宽度，如＠media screen and (max-width：500 px){...}方法有着很大的区别和优势。 这种区别主要体现在screen.width 获取的屏幕宽度是设备的屏幕硬件宽度，一台显示器还是一部手机，出厂时已经默认了设备的宽和高，比如一部手机的硬件屏幕宽度就是人们单手握持时的那两边之间的距离，当人为地旋转手机屏幕时，改变的是内置系统和浏览器软件的宽高位置，而设备自身的硬件屏幕参数并未发生改变。 正是由于这种特性，当用户使用移动设备屏幕自动旋转功能时，一旦用户使用横屏观看的Web 页面，media query 会自动响应计算，提供给用户新的显示资源，而使用screen.width 加以判断则不会出现这种问题。

既然使用screen.width 的诸多特性可以很好地适用于移动端的响应式开发，那么下面研究究竟应该如何剔除media query 媒体查询，转而使用screen.width 加以设备判断。 首先，需要加载一段JavaScript 代码来替代＠media 媒体查询作逻辑判断：

这里使screen.width ＜500 的全部默认为移动设备，对于这些移动设备场景，将其内部元素全部生成一个CSS 的class 组别命名为'Mobile'代表移动端来进行识别和加载。 其次，再编写出名为'Mobile'的class 组别下对应的CSS 移动端布局代码：

这样便在使用screen.width 屏幕宽度完成了对于桌面端和移动端的响应式适配工作。 下一步，使用screen.width 设备屏幕宽度代替主流的media query 媒体查询来进行移动端适配。 这样便利用screen.width 设备屏幕宽度属性替代主流screen.width 媒体查询来完成了Web 的桌面端及移动端响应适配工作。

测试使用了screen.width 设备屏幕宽度适配在移动端的横屏显示效果，如图7 所示。

图7 基于screen.width 适配的模型在移动端375∗667 分辨率横屏显示效果

例如一台iPhone6 手机设备的屏幕尺寸是375∗667，在用户设备自动旋转的横屏模式下，media query 会自动错误地提供给用户667 px 附近的桌面端显示资源，而使用screen.width 加以逻辑判断则判定当前仍处于500 px 宽度移动窄屏设备下，保持正确的移动端显示视图和资源加载。

这样便在大量缩减代码量的同时，规避了加载桌面端高清的图像、桌面端的交互JS 文件代码等，从而避免了各种资源的过度加载和用户手机流量的浪费，使得用户浏览Web 页面时不会由于横竖屏的切换影响浏览器的工作效率，从而有效避免了JS 事件冲突、页面bug、卡顿延迟响应等不良的用户体验出现，所以说使用screen.width 来做响应式开发设备适配，其优越性和可靠性远高于目前主流的media query 媒体查询技术。

4 结论

通过上述研究及测试，发现使用基于vw 视区相对单位开发Web 页面来自动适配桌面端页面，再使用screen.width 来判断适配移动端更为完善的显示，它能够自动适配当前几乎所有的桌面端及移动端设备包括移动端横屏的显示，这套完整的由vw 与screen.width 共同构成的整合技术可以将其称之为V-SW 响应式多终端Web 全适配开发技术。

V-SW 多终端Web 全适配开发技术弥补了主流响应式开发技术的一系列难以克服的问题，几乎不需要做任何媒体查询适配，便可完成桌面端的多设备显示适配，没有响应式断点的过渡问题，可以实现后期零维护，能够在多设备上保持全屏的浏览体验，与此同时还能够规避主流响应式开发带来的一系列移动端错误加载和不良用户体验等问题，具有较高的应用价值。