吳 睿

(安徽農(nóng)業(yè)大學(xué) 經(jīng)濟(jì)技術(shù)學(xué)院，合肥230011)

傳統(tǒng)的Web 開發(fā)領(lǐng)域發(fā)生了多次技術(shù)演進(jìn)，從早期樸素的單網(wǎng)頁開發(fā)為主，到后來出現(xiàn)了針對(duì)不同設(shè)備的自適應(yīng)布局技術(shù)、流式布局技術(shù)等。 直至響應(yīng)式開發(fā)的提出及流行，基本滿足了大多數(shù)Web 適配開發(fā)的需求。 但主流的響應(yīng)式多終端Web 適配技術(shù)，仍存在諸多的問題及改進(jìn)空間，針對(duì)這些問題，本文進(jìn)行了深入研究，最終探索出V-SW 組合適配技術(shù)來改進(jìn)當(dāng)前主流的多終端Web 響應(yīng)適配技術(shù)。

1 當(dāng)前面臨的多終端適配問題

所謂響應(yīng)式頁面設(shè)計(jì)(Responsive Web Design 簡(jiǎn)稱RWD)，就是在Web 開發(fā)時(shí)分別為不同的屏幕分辨率設(shè)置斷點(diǎn)區(qū)間，使用media query 媒體查詢技術(shù)來指定各自不同布局的技術(shù)[1]，即頁面及其內(nèi)部元素的寬度，能夠隨著瀏覽器窗口的大小自動(dòng)縮放適配。 如圖1 所示。

目前，響應(yīng)式頁面設(shè)計(jì)(RWD)已然成為最成熟可靠的Web 開發(fā)多終端解決技術(shù)，當(dāng)前響應(yīng)式頁面設(shè)計(jì)的主流就是使用相對(duì)字體單位rem 來定義各種元素的尺寸大小以及位置距離，配合float 浮動(dòng)布局或flexbox 伸縮盒模型來合理排布頁面，最后使用media query 媒體查詢來作布局自動(dòng)適配和調(diào)整[2]，本項(xiàng)目中簡(jiǎn)稱這種技術(shù)為R-MQ 響應(yīng)式多終端適配技術(shù)。

然而這種當(dāng)前主流技術(shù)也并非沒有缺陷，這種技術(shù)的Web 頁面的布局及內(nèi)容只會(huì)在到達(dá)臨界點(diǎn)時(shí)，發(fā)生突然的布局、元素尺寸、字體大小的改變。 當(dāng)拉伸瀏覽器的時(shí)候，會(huì)感受到階段性的變形效果，無法達(dá)到順滑漸變縮放效果，用戶體驗(yàn)不是很好。更重要的是，隨著各種設(shè)備的層出不窮，適配斷點(diǎn)的不斷增多和變化，使得頁面的適配維護(hù)成本仍然很高。

圖1 響應(yīng)式頁面設(shè)計(jì)

2 基于vw 視區(qū)相對(duì)單位布局技術(shù)

2.1 基于vw 視區(qū)相對(duì)單位布局的可用性分析

由于rem 單位的響應(yīng)式布局存在著大量的適配問題難以解決，與此同時(shí)，CSS3 草案中推出的vw 以及viewport 視區(qū)相關(guān)單位隨著時(shí)間的遷移和瀏覽器兼容性的提升，當(dāng)前使用vw 單位進(jìn)行Web 設(shè)計(jì)開發(fā)已然變得可行和具有實(shí)際意義。 vw 系列視區(qū)相關(guān)單位，在2012 年查詢到的各瀏覽器完全支持的兼容性僅為27.97%，然而，2019 年通過CSS 屬性可用性查詢網(wǎng)站caniuse.com 給出了的查詢結(jié)果，如圖2 所示。

從圖2 統(tǒng)計(jì)數(shù)據(jù)可以看出完全支持的占93.41%，已完全達(dá)到可用和通用的狀態(tài)。 視區(qū)相對(duì)單位就是相對(duì)于瀏覽器viewport 尺寸的單位，具體包括vw：視區(qū)寬度的百分比值；vh：視區(qū)高度的百分比值等具體單位[3]。 視區(qū)viewport 所指為瀏覽器內(nèi)部的可視區(qū)域大小，不包含任務(wù)欄標(biāo)題欄及底部工具欄的瀏覽器區(qū)域，由此可知，100vw 就是整個(gè)瀏覽器視區(qū)的寬度。

圖2 vw 視區(qū)單位兼容性圖

2.2 基于vw 視區(qū)相對(duì)單位布局的適配優(yōu)勢(shì)分析

使用vw 單位與使用百分比單位區(qū)別在于使用百分比單位時(shí)，元素的寬度是相對(duì)瀏覽器寬度計(jì)算的，但是元素的高度是無法使用百分比單位的，定義元素的高度也可以使用視區(qū)寬度vw 為單位，這樣元素的寬高尺寸便可以跟隨瀏覽器寬度發(fā)生相應(yīng)的變化，這正是解決響應(yīng)式設(shè)計(jì)中重點(diǎn)難題的關(guān)鍵所在。

與此同時(shí)，屏幕越大，文字也應(yīng)當(dāng)越大，頁面內(nèi)字體元素以及圖片寬度高度也可以使用vw 相對(duì)視區(qū)單位，這樣頁面中的文字內(nèi)容以及圖形圖像便可以跟隨瀏覽器寬度自動(dòng)縮放，滿足用戶的可讀性。 因此在Web 開發(fā)中使用相對(duì)視區(qū)單位，具有其特殊的優(yōu)勢(shì)：可以實(shí)現(xiàn)跟隨瀏覽器寬度變化的等比例縮放圖形，并且可以實(shí)現(xiàn)完全自動(dòng)縮放的網(wǎng)頁布局及內(nèi)容[4]。 使用vw 視區(qū)相對(duì)單位來開發(fā)模型頁面，關(guān)鍵代碼如下：

測(cè)試基于vw 視區(qū)寬度單位的模型在桌面端1 024?768 分辨率下顯示效果，如圖3 所示。

圖3 基于vw 單位的模型在桌面端1 024?768 分辨率下顯示效果

然后來測(cè)試該基于vw 視區(qū)寬度單位的模型在桌面端1 366?768 直至2 560?1 440 高分辨率下顯示效果，如圖4 所示。

圖4 基于vw 單位的模型在桌面端2 560?1 440 分辨率下顯示效果

通過模型分析測(cè)試，使用了全新的vw 視區(qū)單位在常見的桌面端設(shè)備及分辨率仿真測(cè)試下，隨著桌面顯示設(shè)備屏幕分辨率的加大，即使是上升到1080 p 高清屏乃至2K 甚至4K 超高清屏，頁面顯示會(huì)隨之等比例縮放，可以始終看到完整的頁面布局及信息，有較為完美的顯示效果。 因此使用vw 相對(duì)視區(qū)單位在桌面端分辨率下，幾乎不需要作任何媒體查詢適配，使用了極少的代碼便完成桌面端的多設(shè)備顯示適配，工作量大幅減少。 與此同時(shí)頁面主體使用100 vw 布局能夠在各種分辨率下保持瀏覽器近乎全屏的顯示效果，這樣便大大增強(qiáng)了用戶的Web 瀏覽訪問體驗(yàn)。

同樣在移動(dòng)端使用vw 視區(qū)相對(duì)寬度單位相比使用px 像素單位及rem 相對(duì)字體單位，無須再計(jì)算確定不同規(guī)格分辨率下的內(nèi)部元素尺寸，只需劃定大致的移動(dòng)端及桌面端的斷點(diǎn)區(qū)間即可，沒有響應(yīng)式斷點(diǎn)的過渡問題，后期多設(shè)備維護(hù)量也大大減少，基本實(shí)現(xiàn)了后期適配工作的零維護(hù)，減少了開發(fā)的工作量和代碼書寫量，優(yōu)化了Web 頁面的加載速度。

3 基于screen.width 的設(shè)備查詢適配技術(shù)

使用基于rem 媒體查詢響應(yīng)式多終端適配技術(shù)，媒體查詢media query 無疑是當(dāng)前最為主流的適配技術(shù)選擇，其主要工作方式是：

media query 媒體查詢給Web 開發(fā)帶來了質(zhì)的飛躍，使得可以開發(fā)響應(yīng)式頁面，無需重復(fù)開發(fā)多個(gè)頁面來適配不同的屏幕顯示分辨率[5]。 但是研究發(fā)現(xiàn)，media query 媒體查詢技術(shù)也有許多自身的缺陷。

(1)桌面端用戶可以通過拉伸瀏覽器尺寸訪問到移動(dòng)端界面

使用桌面瀏覽器訪問Web 頁面時(shí)，由于桌面平臺(tái)用戶可以使用鼠標(biāo)手動(dòng)拉伸和縮小瀏覽器尺寸，有些用戶在縮小瀏覽器時(shí)訪問到臨界點(diǎn)以下，但是Web 開發(fā)者并不希望用戶在桌面端訪問到移動(dòng)端的響應(yīng)界面，這是由于桌面端和移動(dòng)端往往使用不同分辨率及尺寸的元素縮略圖[6]。 然而，當(dāng)桌面用戶在響應(yīng)式的桌面端和移動(dòng)端臨界點(diǎn)來回拉伸瀏覽器尺寸，勢(shì)必造成高清和低清資源的加載冗余，浪費(fèi)資源，影響瀏覽器的工作效率。

而且，桌面端和移動(dòng)端往往有很多不同的JavaScript 交互邏輯，如桌面端使用click 鼠標(biāo)點(diǎn)擊事件來響應(yīng)用戶的點(diǎn)擊行為觸發(fā)接下來的動(dòng)作，而移動(dòng)端使用touch 觸摸事件來響應(yīng)用戶在移動(dòng)設(shè)備屏幕上的滑動(dòng)行為[7]，當(dāng)桌面用戶在響應(yīng)式的桌面端和移動(dòng)端臨界點(diǎn)來回拉伸瀏覽器尺寸時(shí)，對(duì)應(yīng)加載的JS 文件或代碼也要跟著切換，勢(shì)必造成JS 資源的過多加載和浪費(fèi)，影響瀏覽器的工作效率。 并且很容易出現(xiàn)同一個(gè)行為對(duì)象的click 鼠標(biāo)點(diǎn)擊事件與touch 觸摸事件沖突的現(xiàn)象，可能導(dǎo)致出現(xiàn)頁面bug 或卡頓延遲響應(yīng)等不良的用戶體驗(yàn)。

(2)移動(dòng)端瀏覽器橫屏顯示時(shí)往往會(huì)適配到桌面端顯示模式

同樣地，當(dāng)使用media query 媒體查詢來作響應(yīng)式適配時(shí)，移動(dòng)端用戶訪問也有一定的不便。 由于＠m(xù)edia 適配的是屏幕分辨率中的寬度，比如使用＠m(xù)edia screen and (max-width：500 px){...}來適配屏幕寬度在500 像素以下的各種主流移動(dòng)設(shè)備，如一臺(tái)iPhone6 的屏幕尺寸是375?667，在用戶正常持握下media query 會(huì)自動(dòng)提供給用戶500px 以內(nèi)的移動(dòng)端顯示資源。

然而現(xiàn)在的移動(dòng)設(shè)備往往具備屏幕自動(dòng)旋轉(zhuǎn)功能，一旦用戶在躺臥或其他特殊情形下使用橫屏觀看的Web 頁面，media query 又會(huì)自動(dòng)響應(yīng)提供給用戶500 px 以上的桌面端顯示資源。 測(cè)試使用media query 媒體查詢時(shí)移動(dòng)端橫屏顯示效果，如圖5 所示。

圖5 基于media query 適配的模型在移動(dòng)端375?667 分辨率橫屏顯示效果

經(jīng)過測(cè)試，模型在各種移動(dòng)端分辨率的橫屏下顯示效果亦保持一致。 此時(shí)在移動(dòng)端橫屏模式下加載的資源包括桌面端高清的圖像、桌面端的交互JavaScript 文件代碼等，這勢(shì)必造成各種資源的過度加載和用戶手機(jī)流量的浪費(fèi)，影響瀏覽器的工作效率，甚至導(dǎo)致事件沖突、頁面bug、卡頓延遲響應(yīng)等不良的用戶體驗(yàn)出現(xiàn)，更重要是在較小的手機(jī)屏幕上顯示如此多的內(nèi)容和局部元素，用戶很難看清頁面的內(nèi)容，造成不良的用戶體驗(yàn)。

所以，當(dāng)前流行的media query 媒體查詢也并非十分完備的響應(yīng)式解決技術(shù)。

screen.width 所指的是設(shè)備屏幕的硬件寬度數(shù)值，無論瀏覽器軟件被如何拉伸縮放，設(shè)備的screen.width始終是保持不變的[8]。 目前，通過screen.width 可以查詢獲得屏幕寬度，其兼容性已經(jīng)得到充分保障，如圖6所示。

圖6 screen.width 兼容性圖

通過上述圖表分析可知，幾乎市面上所有的主流瀏覽器都是完全支持screen.width 獲取屏幕寬度數(shù)值的。 使用screen.width 獲取的屏幕寬度，與＠m(xù)edia 媒體查詢中使用的屏幕分辨率的寬度，如＠m(xù)edia screen and (max-width：500 px){...}方法有著很大的區(qū)別和優(yōu)勢(shì)。 這種區(qū)別主要體現(xiàn)在screen.width 獲取的屏幕寬度是設(shè)備的屏幕硬件寬度，一臺(tái)顯示器還是一部手機(jī)，出廠時(shí)已經(jīng)默認(rèn)了設(shè)備的寬和高，比如一部手機(jī)的硬件屏幕寬度就是人們單手握持時(shí)的那兩邊之間的距離，當(dāng)人為地旋轉(zhuǎn)手機(jī)屏幕時(shí)，改變的是內(nèi)置系統(tǒng)和瀏覽器軟件的寬高位置，而設(shè)備自身的硬件屏幕參數(shù)并未發(fā)生改變。 正是由于這種特性，當(dāng)用戶使用移動(dòng)設(shè)備屏幕自動(dòng)旋轉(zhuǎn)功能時(shí)，一旦用戶使用橫屏觀看的Web 頁面，media query 會(huì)自動(dòng)響應(yīng)計(jì)算，提供給用戶新的顯示資源，而使用screen.width 加以判斷則不會(huì)出現(xiàn)這種問題。

既然使用screen.width 的諸多特性可以很好地適用于移動(dòng)端的響應(yīng)式開發(fā)，那么下面研究究竟應(yīng)該如何剔除media query 媒體查詢，轉(zhuǎn)而使用screen.width 加以設(shè)備判斷。 首先，需要加載一段JavaScript 代碼來替代＠m(xù)edia 媒體查詢作邏輯判斷：

這里使screen.width ＜500 的全部默認(rèn)為移動(dòng)設(shè)備，對(duì)于這些移動(dòng)設(shè)備場(chǎng)景，將其內(nèi)部元素全部生成一個(gè)CSS 的class 組別命名為'Mobile'代表移動(dòng)端來進(jìn)行識(shí)別和加載。 其次，再編寫出名為'Mobile'的class 組別下對(duì)應(yīng)的CSS 移動(dòng)端布局代碼：

這樣便在使用screen.width 屏幕寬度完成了對(duì)于桌面端和移動(dòng)端的響應(yīng)式適配工作。 下一步，使用screen.width 設(shè)備屏幕寬度代替主流的media query 媒體查詢來進(jìn)行移動(dòng)端適配。 這樣便利用screen.width 設(shè)備屏幕寬度屬性替代主流screen.width 媒體查詢來完成了Web 的桌面端及移動(dòng)端響應(yīng)適配工作。

測(cè)試使用了screen.width 設(shè)備屏幕寬度適配在移動(dòng)端的橫屏顯示效果，如圖7 所示。

圖7 基于screen.width 適配的模型在移動(dòng)端375?667 分辨率橫屏顯示效果

例如一臺(tái)iPhone6 手機(jī)設(shè)備的屏幕尺寸是375?667，在用戶設(shè)備自動(dòng)旋轉(zhuǎn)的橫屏模式下，media query 會(huì)自動(dòng)錯(cuò)誤地提供給用戶667 px 附近的桌面端顯示資源，而使用screen.width 加以邏輯判斷則判定當(dāng)前仍處于500 px 寬度移動(dòng)窄屏設(shè)備下，保持正確的移動(dòng)端顯示視圖和資源加載。

這樣便在大量縮減代碼量的同時(shí)，規(guī)避了加載桌面端高清的圖像、桌面端的交互JS 文件代碼等，從而避免了各種資源的過度加載和用戶手機(jī)流量的浪費(fèi)，使得用戶瀏覽Web 頁面時(shí)不會(huì)由于橫豎屏的切換影響瀏覽器的工作效率，從而有效避免了JS 事件沖突、頁面bug、卡頓延遲響應(yīng)等不良的用戶體驗(yàn)出現(xiàn)，所以說使用screen.width 來做響應(yīng)式開發(fā)設(shè)備適配，其優(yōu)越性和可靠性遠(yuǎn)高于目前主流的media query 媒體查詢技術(shù)。

4 結(jié)論

通過上述研究及測(cè)試，發(fā)現(xiàn)使用基于vw 視區(qū)相對(duì)單位開發(fā)Web 頁面來自動(dòng)適配桌面端頁面，再使用screen.width 來判斷適配移動(dòng)端更為完善的顯示，它能夠自動(dòng)適配當(dāng)前幾乎所有的桌面端及移動(dòng)端設(shè)備包括移動(dòng)端橫屏的顯示，這套完整的由vw 與screen.width 共同構(gòu)成的整合技術(shù)可以將其稱之為V-SW 響應(yīng)式多終端Web 全適配開發(fā)技術(shù)。

V-SW 多終端Web 全適配開發(fā)技術(shù)彌補(bǔ)了主流響應(yīng)式開發(fā)技術(shù)的一系列難以克服的問題，幾乎不需要做任何媒體查詢適配，便可完成桌面端的多設(shè)備顯示適配，沒有響應(yīng)式斷點(diǎn)的過渡問題，可以實(shí)現(xiàn)后期零維護(hù)，能夠在多設(shè)備上保持全屏的瀏覽體驗(yàn)，與此同時(shí)還能夠規(guī)避主流響應(yīng)式開發(fā)帶來的一系列移動(dòng)端錯(cuò)誤加載和不良用戶體驗(yàn)等問題，具有較高的應(yīng)用價(jià)值。