說到響應(yīng)式設(shè)計(jì)，首先要提及的是其核心技術(shù)Media Queries。記得還是在我10年前上大學(xué)的時(shí)候，看著書本中描述響應(yīng)式設(shè)計(jì)的愿景仿佛還如同昨日，如今隨著Media Queries受到瀏覽器廣泛支持而早已成為現(xiàn)實(shí)。我最早寫的關(guān)于Media Queries的CSS3 Media Queries 詳解一文，發(fā)布于2010-08-23，距今已然6年，并且Media Queries Lv3也已經(jīng)在2012年成為W3C推薦標(biāo)準(zhǔn)——也正是2012年，算是響應(yīng)式設(shè)計(jì)的爆發(fā)之年。

于是這些年來各種設(shè)計(jì)精巧的響應(yīng)式頁面便層出不窮，雖然國內(nèi)老牌網(wǎng)站鮮見(業(yè)務(wù)和瀏覽器的各種因素)，卻在國外遍地開花。雖然使用的算不上多，但這些年的一些思考需要整理一下，本文就是我近年來對響應(yīng)式設(shè)計(jì)的實(shí)踐以及一些粗淺經(jīng)驗(yàn)和建議，分別從設(shè)計(jì)和代碼角度來看響應(yīng)式頁面。

響應(yīng)式設(shè)計(jì)

響應(yīng)式設(shè)計(jì)(Responsive web design，以下皆簡稱RWD)致力于提供跨設(shè)備的好體驗(yàn)。但說到底，RWD做的再好終究是無法同單一設(shè)備優(yōu)化的頁面相比的，RWD的優(yōu)點(diǎn)并非是體驗(yàn)本身，而是基于一套代碼的適應(yīng)性的體驗(yàn)改良——從大多數(shù)意義上講，實(shí)際是指盡可能減少相同的頁面在移動(dòng)端的縮放，平移和滾動(dòng)。

因?yàn)楦采w面更廣，RWD的設(shè)計(jì)里多出了許多額外需要權(quán)衡的取舍，這對設(shè)計(jì)和前端都有所要求，所以如果設(shè)計(jì)和前端是分開獨(dú)立運(yùn)行，那么務(wù)必需要更為緊密的溝通。很多時(shí)候?yàn)榱藢で笤O(shè)計(jì)和實(shí)現(xiàn)的平衡點(diǎn)，分工過于明確的團(tuán)隊(duì)會(huì)額外消耗大量的溝通時(shí)間。

個(gè)人是贊同前端自己來設(shè)計(jì)RWD的，如果只一人操作RWD，那么還是加修設(shè)計(jì)的前端更合適一些，因?yàn)閺脑O(shè)計(jì)出發(fā)常常妨礙RWD的初衷——設(shè)計(jì)的內(nèi)容無法用一種結(jié)構(gòu)來描述的話，RWD意義就不大了。如果是設(shè)計(jì)師主導(dǎo)設(shè)計(jì)頁面結(jié)構(gòu)，那么一個(gè)簡單的原則，就是將內(nèi)容切割分塊然后像堆積木一樣來倒序擺放。

適用范圍

RWD并非萬能，相反其適用面其實(shí)相當(dāng)有限。廣義的RWD是需要自適應(yīng)到手機(jī)屏幕的，對于4-6寸巴掌大小的屏幕，信息承載能力自然有限。雖然從PC端自適應(yīng)的過程中可以做減法，但頁面核心內(nèi)容還是被嚴(yán)格地限制著。所以復(fù)雜頁面不可能適合RWD——一個(gè)簡單的衡量標(biāo)準(zhǔn)是，頁面上需要表達(dá)的點(diǎn)一般不超過10個(gè)。實(shí)際上互聯(lián)網(wǎng)絕對多數(shù)的站點(diǎn)業(yè)務(wù)并不復(fù)雜，所以其實(shí)RWD還是很有市場，特別是對于展示類網(wǎng)站，RWD幾乎都是選。無奈國內(nèi)小而美的戰(zhàn)點(diǎn)相對較少，所以RWD也就相對要少很多。

移動(dòng)web設(shè)計(jì)

這幾年移動(dòng)影響Web設(shè)計(jì)的趨勢已經(jīng)越發(fā)明顯，簡單列舉一些常見的模式轉(zhuǎn)變：

滾動(dòng)加載替代分頁，對應(yīng)手機(jī)端的滑屏。 基于矢量的扁平化設(shè)計(jì)，高PPI屏幕清晰度和性能的需求 內(nèi)容尺寸放大，開始以拇指觸碰的精度設(shè)計(jì)交互組件 縮減hover的使用，使得移動(dòng)端和PC端交互一致 更為明顯的交互態(tài)，例如Button，受限于無法hover，那么人們必須第一眼就識(shí)別出交互組件的外觀 漢堡圖標(biāo)和抽屜式頁面，這些都是APP的標(biāo)準(zhǔn)交互形式，現(xiàn)在已經(jīng)不僅僅出現(xiàn)在移動(dòng)端頁面里，甚至直接出現(xiàn)在PC端。

這些改變，使得我們漸漸一眼就能看出一個(gè)頁面是否是RWD——大尺寸交互元素配上簡單空曠的頁面風(fēng)格。

RWD模式

既然移動(dòng)影響了相當(dāng)多的PC端設(shè)計(jì)，那么也一定有相當(dāng)多的固有套路，比如：

通欄：總是最有效的突出內(nèi)容且易于RWD控制的形式。 抽屜：多種類型屏幕里，彈窗的伸縮性往往受到更多限制。 折疊：屏幕的變換會(huì)使得定位元素的定位管理變得麻煩，當(dāng)我們需要一個(gè)more info，往往不是彈窗不是定位浮層，而是向下展開更多內(nèi)容。 自然換行：和下面要講的多語言更有關(guān)些。 多語言

RWD配上多語言，使得原本復(fù)雜的頁面更顯得麻煩。但是相比普通頁面，RWD和多語言的相性卻并不差。實(shí)際上寬松的頁面結(jié)構(gòu)加上原本就為不同屏幕設(shè)計(jì)自適應(yīng)布局，多語言化的話反而要更為順利一些，當(dāng)然前提是設(shè)計(jì)之初就已經(jīng)有了相當(dāng)多的考慮。于是就會(huì)常常遇到“自然換行”，這種自然換行卻恰恰也是需要設(shè)計(jì)的一部分，一個(gè)頁面如果能保證大部分內(nèi)容自然換行都不會(huì)影響頁面整體的話，才是成功的RWD。

響應(yīng)式代碼

一般的認(rèn)知是RWD因?yàn)橐惶捉Y(jié)構(gòu)的關(guān)系，所以比較節(jié)省開發(fā)資源。但實(shí)際節(jié)省下來的后端開發(fā)，與額外增加的前端工程以及設(shè)計(jì)上的制衡相互抵消。一個(gè)項(xiàng)目是否真的節(jié)省了資源最終還是要看項(xiàng)目本身的復(fù)雜度，不過從大的范圍來看，相對節(jié)約資源是正確的，當(dāng)然付出的代價(jià)就是一種平庸，因?yàn)槿诤隙忠龅襟w驗(yàn)的極致是相當(dāng)困難的。

Media Queries是RWD實(shí)現(xiàn)的基石，而寬度則又是RWD的核心維度（我們還是一如既往的不怎么關(guān)心高度～）。

設(shè)備

雖然我們常常為了某個(gè)設(shè)備制作RWD頁面，但真正的RWD頁面需要應(yīng)對的并不是某某設(shè)備，而是頁面內(nèi)容本身——針對內(nèi)容做響應(yīng)式設(shè)計(jì)，而不是針對某個(gè)設(shè)備。當(dāng)然實(shí)際情況，大多數(shù)人還是會(huì)偏向?qū)帉戓槍υO(shè)備斷點(diǎn)的代碼，比如下面這個(gè)是我以前為了一個(gè)團(tuán)隊(duì)分享所畫的斷點(diǎn)圖示：

雖然已經(jīng)是一年多以前的圖，但近幾年移動(dòng)端變化已經(jīng)減緩所以依舊可以看看。針對設(shè)備做優(yōu)化的好處是直接有效，成本低可控制。如果當(dāng)真對頁面內(nèi)容做RWD，單一語言還比較好控制，多語言總是會(huì)遇到各種奇葩問題，可能在各種妥協(xié)下頁面的整體設(shè)計(jì)就一團(tuán)糟了。

性能

就目前的流量和網(wǎng)絡(luò)來說，RWD還是顯得太笨重。之前我做過一些頁面的簡單對比，相同頁面平均速度要差3-4倍，相當(dāng)可觀。分析原因主要還是因?yàn)镻C的重量連帶給RWD后，拖慢了整體頁面的加載速度，無法與傳統(tǒng)的單一優(yōu)化的H5頁面相比。這些問題等到未來網(wǎng)速加快會(huì)漸漸顯得不能刺眼，不過當(dāng)前還不能忽視。

代碼特點(diǎn)

RWD的核心代碼關(guān)鍵詞是普通流（或稱常規(guī)流，normal flow）。普通流是最能保證自適應(yīng)的CSS定位機(jī)制，清晰的文檔上下文秩序，在這個(gè)基礎(chǔ)上運(yùn)用浮動(dòng)和有限的定位，是RWD的主流做法。在這過程中有一些常見的編碼問題需要注意：

嚴(yán)格限制的position，z-index，overflow:hidden。雖然正常情況下這些CSS屬性也是需要一定限制的，但在RWD中顯得更為重要。 避免line-height垂直居中。由于無法確定在某種特定狀況下發(fā)生換行而使得頁面非常難看，除非能保證內(nèi)容完全無折行可能，不然調(diào)整行高是毫無必要。 字體問題。傳統(tǒng)PC有一些奇技淫巧，比如字符箭頭，在RWD里容易出問題。曾經(jīng)我們可能只需要考慮桌面環(huán)境（并且往往是windows為主），而現(xiàn)在需要面對的則是更為復(fù)雜的客戶端環(huán)境。使用的字符比以往更容易受到系統(tǒng)和設(shè)置的影響而出現(xiàn)錯(cuò)位，應(yīng)該盡力避免。 定寬的絕對定位。絕對定位常常用在寬度恒定的地方，比如icon。在多語言的情況下，如果能用定寬icon替代文本，那么應(yīng)該優(yōu)先考慮通用的圖形。這讓我想起來宜家家居的安裝說明書——如果你仔細(xì)看過他們的說明書的話，就會(huì)發(fā)現(xiàn)安裝說明只有圖示沒有任何文字出現(xiàn)。

值得一提的是，表格處理絕對是RWD的煩人問題之一。當(dāng)需要把一張又長又寬的表格塞進(jìn)手機(jī)里的時(shí)候，會(huì)發(fā)現(xiàn)真的非常無奈。目前對于這種情況往往有3種處理方式：

添加容器，并使得整個(gè)表格在容器中截?cái)?，在移?dòng)端用滾動(dòng)條查看。所有表格都能搞定，體驗(yàn)蛋疼。 以display:table，display:table-cell等樣式模擬顯示PC端的表格，到移動(dòng)端再將表格打散重新排布 。缺點(diǎn)是無法真正模擬復(fù)雜表格，對跨單元格的結(jié)構(gòu)也無能為力，表格內(nèi)容超長時(shí)也不如表格穩(wěn)定，并且在移動(dòng)端打散表格后常常會(huì)因?yàn)闆]有th而使表格變得意義不明。

重慶網(wǎng)站建設(shè)

通過巧妙地隱藏和展示部分表格單元，讓表格在一定意義上變形為適合移動(dòng)端的形式。這種方式通常只適合一些不太復(fù)雜的表格 兩個(gè)或更多表格做切換，不是真正意義上的RWD～這里只是列一下。 響應(yīng)式與React

當(dāng)前前端領(lǐng)域，React如火如荼，但React的響應(yīng)式目前做起來就不那么方便。由于HTML由JS接管，反倒是出現(xiàn)了連結(jié)構(gòu)也根據(jù)不同屏幕變化的做法，已經(jīng)與傳統(tǒng)的響應(yīng)式完全不同甚至是背道而馳的。

總結(jié)

響應(yīng)式強(qiáng)迫性地精簡了頁面，是一場輕內(nèi)容的戰(zhàn)斗。未來我們可能面臨更多未知的設(shè)備，響應(yīng)式能否繼續(xù)發(fā)展取決于這些新設(shè)備適用度。就目前來說，RWD已經(jīng)是非常成熟的一種套路，使用前只需確定業(yè)務(wù)是否合適即可。目前，無論是微軟，Google，Apple，他們的不少頁面都有相當(dāng)不錯(cuò)的體驗(yàn)。

當(dāng)前題目：【成都網(wǎng)站建設(shè)】響應(yīng)式設(shè)計(jì)實(shí)踐手札
文章網(wǎng)址：http://jinyejixie.com/news7/224907.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、品牌網(wǎng)站制作、定制開發(fā)、Google、電子商務(wù)、網(wǎng)站設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)