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 全適配開發技術彌補了主流響應式開發技術的一系列難以克服的問題，幾乎不需要做任何媒體查詢適配，便可完成桌面端的多設備顯示適配，沒有響應式斷點的過渡問題，可以實現后期零維護，能夠在多設備上保持全屏的瀏覽體驗，與此同時還能夠規避主流響應式開發帶來的一系列移動端錯誤加載和不良用戶體驗等問題，具有較高的應用價值。