響應式設計的概念

響應式設計的概念最早由Ehan Marcotte在2010年5月份的文章 <響應式網頁設計>中提出。 他強調：頁面可以根據用戶的設備環境，包括系統，分辨率，屏幕尺寸等等因素，進行自發式調整，提供更適合當前環境的閱讀和操作體驗，對已有和未來即將出現的新設備有一定的適應能力。可以說響應式設計能夠完美解決文章開頭提到的問題，小到智能手表的屏幕，大到電視顯示屏，只需要一套代碼就能夠完美兼容，實用且高效。

當我們搜索有關響應式設計的資料時卻發現大多數教程都是針對前端開發工程師撰寫的，有著許多難懂的專業名詞，讓人望而卻步。

以下筆者通過案例，簡單介紹有關響應式設計的技巧。

響應式設計的技巧

Ehan Marcotte的文章中提到了三個概念：流動布局（Fluid grids）、媒介查詢（Media queries）和彈性圖片（Scalable images）。這些概念原本指的是實現響應式的一些技術手段，從設計師的角度，我們可以簡化為以下兩點。

一、分段響應

通過拖動瀏覽器的寬度，我們會發現響應式網頁會隨寬度的改變自動調整布局方式。

需要注意的是，每當瀏覽器達到一個寬度節點，網頁布局就會相應發生較大變化，這就是分段響應。這里我們又需要注意兩個要點：

– 寬度節點應該如何確定？

– 達到寬度節點時頁面布局應該如何變化？

1.寬度節點應該如何確定？

寬度節點來源于前文提到的媒體查詢（Media queries），是前端工程師用簡單的方法，來獲取不同設備的特征，例如設備的寬度/高度，窗口的寬度/高度，設備的手持方向，分辨率等。設計時也可以采用相同的思路，參考網站用戶的設備分辨率數據，比如手機尺寸、平板電腦尺寸及桌面顯示器尺寸，確保常見設備寬度能夠落入到某一設計范圍之內。

2.達到寬度節點時頁面布局應該如何變化？

頁面布局的變化可以簡單歸納為三點：內容增減、布局調整、樣式調整。

內容增減–當瀏覽器寬度較大時，有足夠的空間展示更多的頁面內容。隨著瀏覽器寬度的減小，為了使有限的頁面不至于擁擠，就不得不對原有內容進行部分隱藏以滿足整體布局的合理性。

布局調整–如同前文提到的，當頁面空間被壓縮時，其布局方式也需要相應變化，最常見的就是布局的行列數發生改變。

樣式變更–頁面中的有些模塊，例如導航欄等不能簡單的只隱藏部分內容來適應瀏覽器的變化，這時就需要調整其樣式，將整個模塊變更為其他形式展現，以方便小尺寸設備的使用體驗。

總的來說，分段響應就是頁面針對不同的瀏覽器寬度展示不同的布局方式。每個組件都可以根據具體使用場景應用不同的變化類型。

二、動態布局

解決了分段響應的規則后，接下來需要制定瀏覽器在寬度節點之間變化時，組件該如何變動，即動態布局。

這里再次搬出Ehan Marcotte的文章所提到的流動布局的概念，原特指以百分比為度量單位的布局技術實現方式。這里就不對如流動布局、彈性布局、流體柵格等各種概念做一一說明。筆者就此統為一個大的概念：在響應式設計的布局中，不再以像素（px）作為唯一單位，而是采用百分比或者混合百分比、像素為單位，設計出更具靈活性的布局方式。

三、其他需要注意的點

首先，要注意的是什么情況下適合采用響應式設計？一切設計的最終目的都應該圍繞著產品體驗這一核心。為了做響應式設計而做響應式設計，往往得不償失。

其次，在搞清楚產品本身的核心用戶體驗之后，選取你的用戶群體所使用的硬件設備，這個時候你應該了解每種設備所使用的場景，設備使用的環境和場景是設計的重要依據。

最后，并非所有的內容都符合不同設備的使用場景，比如智能手表就不適合展示大量的文本內容。你的產品所覆蓋的設備組當中，每種設備的使用場景不同，應該匹配的用戶體驗也不一樣。比如移動端用戶和桌面端用戶的需求就是不同的，場景差異也很大。

以上就是關于響應式設計的分享，希望對你有用。

國外網站使用這種布局方式較多，經過調研，結合嘗試后，本文梳理了響應式設計的方法流程，記錄問題與思考，幫助以后類似的項目開展更快。

什么是響應式布局

響應式布局常常和自適應布局搞混。其實通過下面的動圖我們很容易能理解兩者的區別。

△ 響應式和自適應的區別，來源網上資料

• 響應式布局：容器大小隨窗口大小而變化。
• 自適應布局：容器大小不隨窗口大小而變化，邊距隨窗口大小而變化。

響應式布局優勢

調研中我們發現，國外幾個內容網站，YouTube、Spotify、Netflix 和Behance，都使用了「內容墻」的設計方式，以突出內容的豐富度。

由于這種設計通常會保持容器之間的間距不變，這就需要容器大小變化以適應窗口大小變化了。響應式的布局思路，很好地幫助完成內容墻的設計。

△ 滿屏的內容突出了內容豐富度

響應式布局的設計要點

在以往的開發合作中，設計提供切圖和尺寸標注給開發就行了。

而響應式頁面中的容器大小是動態的，我們可以提供一個表格，告訴開發在不同的頁面寬度區間，對應的布局應該是怎么樣的。這些區間的臨界點，就是「斷點」。

我們以容器多，情況比較復雜的視頻首頁模擬一次確定斷點的流程。

△ 響應式布局的設計思路

首先，斷點是反映頁面發生突變的情況的，如邊距開始發生變化、容器數量開始發生變化等。本例中，我們固定了側邊欄a、邊距b、間距d。據下圖公式，容易得知容器數量和容器寬度有著明確的數量關系。因此，尋找斷點，需要我們先確定容器寬度(c)。

△ 容器數量和容器寬度有著明確的數量關系

容器寬度和容器內容相關。本例中，我們規定正常情況下容器寬度最小300px，以保證封面圖和標題文字還能被看清。當容器寬度被壓到300px時，容器數量減少一個。

有了容器的最小尺寸，那么我們可以輸出給開發的「頁面寬度-容器數量對應表」。從下表可以讀出，瀏覽器寬度在1284-1595px之間時，側邊欄展開為288px，放3個容器，瀏覽器會自動把容器寬度算出來。

△ 頁面寬度與容器數量關系表

斷點選擇的技巧

從上面的案例我們知道，確定斷點和容器數量、容器大小有關。那么，斷點的選擇其實是體現了，設計師對頁面信息呈現方式的理解。

1. YouTube的小心機

調研的過程中，我們發現YouTube 選擇 1143-1966px 作為4個容器的前后斷點。這個頁面寬度區間很大，達到了824px（遠超5個容器的跨度335px）。

△ YouTube的網頁斷點情況

我們猜想：

• YouTube認為1行4個視頻是用戶瀏覽的最好數量；
• 他們想把這種布局覆蓋主流的(約66.25%)屏幕寬度 1280-1920px。

2. 關注高分屏的實際效果

需要特別注意的是，橫向分辨率達到3840px 的PC高分屏中，主流瀏覽器會按照2倍圖展示內容。此外，Windows系統下有系統縮放，推薦的是1.25倍，導致3840px的屏幕寬度，瀏覽器認為只有1536px (3840px÷2÷1.25)。所以有時候會出現在分辨率很高的屏幕下，響應式頁面展示的內容反而更少了的情況。

寫在最后

響應式的布局方法能很好地支持越來越流行的「內容墻」的設計。找好斷點，設定好不同屏幕分辨率的布局策略，是響應式設計的關鍵。

原文：騰訊GLDesign

去年上半年，我開始著手推動項目中響應式設計的落地。以官網優化需求為契機，主動去做了響應式的頁面設計，也說服了產品、設計和開發的相關同事一起把它上線落實，但不幸的是，由于各種方面的原因，比如，生搬硬套的PC模塊，無差異化的設計使得移動端閱讀不佳，導航兼容性有限等等原因，上線幾個月后又悄然下線。我不禁反思，項目中是否應該推行響應式？今年年初重新啟動了全站響應式項目，從產品、交互、視覺到開發，各個角色全方面參與了響應式項目，最終門戶的頁面實現全面響應式。在項目過程中有技術沉淀，也有不少的思考，也就有了以下的文字。文章的內容圍繞四個方面，響應式的概念，實踐方法，一些案例，以及一些看法。

概念

Ehan Marcotte 為A List Apart寫過一篇介紹型的文章 <響應式網頁設計> 。文中講到響應式的概念源自響應式建筑設計，即房間或者空間會根據其內部人群數量和流動而變化。

[最近一門新興的學科“響應式建筑(responsive architecture)”開始在探討物理空間根據流動于其中的人進行響應的方法。建筑師們通過把嵌入式機器人與可拉伸材料結合的方法，嘗試藝術裝置和可彎曲、伸縮和擴展的墻體結構，達到根據接近人群的情況變化的效果。運動傳感器與氣候控制系統相結合，調整圍繞人們周圍的房間的溫度以及環境照明。已經有公司制造了“智能玻璃技術”，當室內人數達到一定的閥值時，它可以自動變為不透明狀態，為人們提供更多隱私保護。]

Web響應式設計的概念與之也非常相似。在如今技術飛快發展的時代，一向是以快論英雄，設備和分辨率日新月異，就以分類相對明晰的iPhone為例，就有多達4種的分辨率和屏幕尺寸，更別提廠商蓬勃發展的安卓機領域。因此，為每種設備或者特定設備分辨率制定相應的獨立版本是非常費時費力的事情。

Web響應式設計的理念，應當是，頁面可以根據用戶的設備環境，包括系統，分辨率，屏幕尺寸等等因素，進行自發式調整，提供更適合當前環境的閱讀和操作體驗，對已有和未來即將出現的新設備有一定的適應能力。

實踐

有了概念，一定要談談實現的方法。類似于響應式建筑，Web頁面也有對應關鍵因素。

• 可彎曲、伸縮、擴展的墻體結構——可擴展的布局；
• 運動傳感器——MediaQuery；
• 氣候控制系統——柵格；
• 藝術裝置——css等等。

以上給了我寫文章的脈絡結構靈感，于是先從最基礎的布局談起。

可擴展的布局

有一種流體布局的概念在早起web興起的時，就開始盛行了。它的概念是說頁面會根據瀏覽器窗口的變化進行更改，網站可以通過維護一套代碼，保質一致性的設計。我這里強調的可擴展的布局也是基于這個概念，只是現在的方法多種多樣，因此要強調頁面布局的可擴展性。

可擴展的布局途徑有很多，比如常見的百分比布局，以及一直未成為標準的柵格布局等等。

• 框架

就從這框架來說，以一個常見的可擴展的三欄布局為例，就有數十種方法，這里拋磚引玉舉幾個例子。

方法1：

Demo1

方法2：

Demo2

方法3：

Demo3

方法4：

Demo4

方法5：

Demo5

方法6：

Demo6

方法7：

Demo7

方法8：

Demo8

方法9：

Demo9

除了上述總結的幾種，還有更多更多的方法。兩欄布局同理就不贅述。

此外W3C也有一個柵格化布局（Grid Layout）的規范，這個布局是基于兩維柵格系統設計的，可以輕松按照我們的意愿改變頁面的設計。它與Flexbox配合效果更佳。但目前仍處于草案階段。翻看了W3C的最新草案內容，對Grid Layout的使用方法和原理簡單介紹下。

1）定義grid：

首先在grid item外的父級容器上定義display: grid.

Values：

• grid – 定義block-level的柵格；
• inline – 定義 inline-level的柵格

2）一些相關概念：

• grid lines – 是橫向和縱向劃分grid的線，它可以一朝數字順序被指定，也可以用用戶制定的名字被指定。

• grid tracks – 指的是一個grid列或者行之前的區域，換而言之是兩個相鄰的grid lines之前的空間。下圖是第二行和第三行之間的grid tracks。

• grid cells – 一個grid cell指的是grid中最小的單位。

• grid areas – 是用來展現一個或多個grid item的邏輯空間。它被四條grid line包圍。

3）grid item 屬性

了解了一些基本概念后，就可以更加絨里理解相關的grid item屬性。

• grid-column-start
• grid-column-end
• grid-row-start
• grid-row-end

這四個屬性中，grid-column-start和grid-row-start指明區域起始線，grid-column-end和grid-row-end指明區域結束線。這四個屬性均有以下四個值可取。

Values：

• <line> – 可以是一個數字，代表的是 grid line
• span <number> – 該項會橫跨所提供的數字個grid tracks
• span <name> – 該項會橫跨直到碰到下一個指定名字的grid line
• auto – 自動或者默認屬性

舉個例子：

代表的區域就是：

除以上提到，grid還擁有更多的屬性，使之可以定義grid item的寬高，間隙，內部自適應的方式，對齊方式等等。更多屬性可以參考W3C文檔。

4）瀏覽器支持：

令人遺憾的是，瀏覽器的支持度還未盡人意，未來在UA上獲取更多支持才是Grid發展的根本。

框架搭建好，才僅僅是響應式的開始。但是俗語有云：Well begun is half done.  響應式從做好的布局開始。

原文鏈接: ISUX

譯前言：2015年響應式設計趨勢的延續，也將帶來更多的爭議和思考，此文所引論據較為客觀，點出了響應式概念的初衷和近年來跨屏設計的狀況，并提供了解決思路和可參考的具體方法，原文下的評論也有諸多爭議，有興趣可以移步一覽。 
原文：http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/ 
作者：Maximiliano Firtman

你臉上掛著微笑心情愉悅地縮放著瀏覽器窗口時，認為網站達成了移動端友好體驗的目標。在探討之前我要提前推論：如果你只是把響應式網頁設計定為終極目標并且是唯一的移動端方案，是在流失用戶，也許還有金錢。幸運的是我們能夠修正這些錯誤。

這篇文章的內容將涉及移動網頁與響應式設計的關系，始于如何提供靈巧的響應式設計，及移動端的性能為何如此重要、響應式設計何以不能視為網站的目標，并止于技術本身的性能爭議，以便輔助理解問題的真正所在。

2000年起，設計師和開發者就已對移動端存在的問題過分簡化，而現在有些人則認為響應式網頁設計是一切難題的銀彈。我們需要正視的是，達到移動網頁的輕快體驗應蓋過其他任何目標。向所有移動設備傳送一個快速可用并全兼容的體驗是一個挑戰，在實施響應式技術時也是如此。而在一開始便關注性能將協助我們更易達成目標。

響應式網頁設計非常優秀，但它不是銀彈。如果把它當作移動端的唯一法寶，那么也許會有性能問題將對轉化率造成阻礙。現約有11%的網站是響應式的并且這個數字每個月都在上升，討論它的時機到了。

根據Guy Podjarny的調查，72%的響應式網站統一傳送相同數量的字節，而不依據屏幕尺寸區分處理，甚至在使用速度較慢的移動網絡連接也是如此。但并非所有的用戶都會耐心等待網站的加載。

實際上只需對問題有基本理解，我們就可以讓損失降到到最低。

移動網站由來已久

我并不是說不該讓設計做到響應式，或者建議應該采用一個m.*的子域名。事實上，社交分享已無所不在，不區分設備讓每一個文件指向同一個URL是明智的。但這并不意味著單一的URL應該總是傳送同一文件，或者說是所有的設備應該加載同一個資源。

引用創造“響應式網頁設計”術語的Ethan Marcotte的一句話：

最重要的是，響應式網頁設計不是特意為移動網站提供的一個替代解決方案。 
（譯補Ethan Marcotte原文：“我認為響應式設計是設計哲學的一部分，也是前端開發策略的一部分。而作為后者，應依實際項目所需評估其可行性。”）

響應、移動、快速

移動端的性能保證與響應式設計可以同時實現，只要用上一些其他技術。響應式網頁設計從不意味著去制造性能問題，這也是我們無法歸罪于這項技術本身的原因，而許多人相信它能解決一切問題才是錯誤的根源。

讓設計響應式化的重要性在于，我們需要處理從臺式機到手機的大區間viewport尺寸。但是只考慮屏幕尺寸低估了移動設備，臺式機與手機的分界線正在變得模糊，不同類型的設備也趨于提供多樣化功能。顯然我們已無法再只依賴于使用媒體查詢這一功能。

有些評論者稱之為“負責任的響應式網頁設計”，雖然其他人把它叫做現代化的響應式網頁設計。撇開兩種叫法語義上的差別，我們確實需要理解并意識到問題所在。

不存在銀彈也沒有可以一勞永逸的方案，我們能做的是使用組合技巧提升現有的響應式方案并且力求性能的最優化：

• 提供相同URL及內容，但針對不同設備結構不同；
• 在立項規劃階段便需遵循移動優先原則；
• 使用display: none時進行真機測試驗證資源加載，而非依賴于桌面瀏覽器模擬；
• 在瀏覽器提供更好的解決方案（如srcset）之前，使用JavaScript分發響應式圖片；
• 移動端初始viewport的文件內嵌，或者優先加載首屏內容。
• 提供更智能的響應式方案如：按需加載、分組響應式、服務器端的自適應處理。

按需加載

CSS媒體查詢無法讓設備區分加載和解析，這意味著移動端的手機會下載和解析為更大屏幕提供的CSS。再者，蜂窩網絡下CSS的分區渲染浪費的毫秒十分寶貴，有必要避免全依賴于此。

正如我們知道的，iPhone不會動態轉換為iPad的尺寸，采用JavaScript 的matchMedia查詢方法替代CSS媒體查詢，則能夠保證不同設備顯示內容的統一性并且只加載它們各自所需要的CSS。

使用特征檢測工具可以做到更好，如Modernizr可以構建更智能的UI和功能定義，而不是只依賴于屏幕尺寸。

分組響應式

基于單HTML頁面為所有屏幕進行響應式設計時，為臺式電腦和智能手機傳送同樣的HTML結構是糟糕的，原因再次回歸到移動端的性能問題。

即使服務器端存儲同一個文件，基于設備分組也可以實現對終端的按需發送。舉例來說，為6英寸及更大尺寸的屏幕提供大的浮動式菜單，而為小于6英寸的屏幕提供一個小的漢堡包菜單。響應式技術可以基于分組實現不同情境的適配，如橫豎屏模式的轉換、不同型號的iPhone（寬為320像素）、各式5英寸的安卓設備（寬為360像素）及平板（寬為400像素及以上）。

服務器端層面

更智能的響應式解決方案的最后一個選項是服務器，對移動網頁來說服務器端進行特征檢測及定義并不新奇，市面上早有諸如WURFL和Device Atlas之類的工具庫。

把響應式設計與服務器端組件聯合同樣也有前例，已被知曉的有響應式設計+服務器端組件(RESS)，或被稱為自適應設計，保障每個終端代碼簡約性的同時，提高了響應式的速度與可用性體驗。

不幸的是，在過去幾年里這些技術沒有在社區里獲得太多的推動，只需看看有多少為開發者提供的博客或雜志將“RESS” 與“自適應” 和“響應式”相提并論便可一知。其一原因在于：我們是前端工程師，任何涉及后端的內容都是個令人頭疼的難題。

一部分情況是前端設計人員可以控制的是服務器上的腳本；另一部分情況是有遠程開發團隊管理，設計師并不想在每次需要調整UI時都與他們打交道，這種情形下的心情我能夠理解。

這也是為何在大項目里頭應該考慮新的架構層：一種不需要動用后端，只通過前端工程師就能夠對服務器端架構進行操作的方式。Node.js是一種卓越的作為前后端之間流通架構的平臺，這個架構方式下，前端工程師可以基于內部的流通性進行調整而不需要涉及后端架構，從而實現為所有設備提供輕快的響應式和可用性體驗。

響應式設計、性能和技術數據

對這篇文章你可能抱有一些置疑，接下來我們將對技術細節進行重新審視以減輕你的疑慮。

響應式設計通常會為所有設備傳送相同的HTML文件，再采取媒體查詢的方式加載不同的CSS和image文件，這一點有的人可能不太同意，但很多情況下都是如此實施的。

你也可能會認為如今移動網絡速度的提升已足夠實現良好的體驗，畢竟4G非常快，設備也運行得更為流暢，那么在下結論之前我們來看一些數據吧。

蜂窩連接

4G網絡還沒有廣泛覆蓋，而即便是全世界范圍內都能夠使用4G網絡，可能也會有一些超出預期的狀況。只論US地區的4G用戶數量約為22%，而其中的40%并非隨時處于4G連接狀態，除外地區則只有不到3%的手機使用4G連接。

移動網絡速度受限于帶寬，3G可以達到5Mbps，4G可以達到50Mbps。但移動網頁體驗通常面臨的最重要的現狀是：消耗于接收大文件（如YouTube視頻）的帶寬越多，大批量小文件的并行下載越不順暢，并會伴有確定性的高發延遲。延遲是設備對每個數據包的首字節發起請求接收的往返時間。

蜂窩網絡比其他連接方式延遲更多。雖然US的家庭DSL連接延遲為20~45ms，3G網絡 
卻可能達到150~450ms，4G網絡則為100~180ms。這也就意味著蜂窩連接的延遲比家庭網絡要高出5~10倍。

尚有其他延遲方面的問題如無線電廣播引起的變動：當手機進入休眠狀態后打開收音機頻率需要獲取更多數據而導致滯時；設備平均可用內存越低也就意味著電池和CPU消耗越多。

蜂窩網絡下的響應式設計

一個實例：Keynote是一家提供性能解決方案的公司，發布了2014超級碗頂尖廣告的網頁性能數據。這份報告里陳述：在wired或Wi-Fi連接下加載時間為1~10s區間，而在蜂窩連接下加載時間為5~60s的區間。實在難以想象超級碗上投放的廣告是需要加載整整一分鐘的網頁。

同樣的報告顯示有43%的網站提供了移動專屬版本，平均體積為862KB；50%實行響應式方案的平均體積在3211KB（超出將近四倍）；另外7%對移動設備提供的則是桌面版，這基本可以認為響應式網站比移動專屬網站的體積更大。

當然，響應式網站可以有不一樣的表現，但不幸的是，這份報告之外的響應式網站的表現也基本與超級碗廣告相似。

基于云技術的瀏覽器

如果對移動端網頁的性能仍存有疑慮，想想看基于云技術開發瀏覽器的廠商正為用戶做的——包括Opera Mini、基于亞洲的UC瀏覽器（根據statcounter的統計，其市場占有率為11%），Amazon Fire的Silk瀏覽器和目前的 Google Chrome（通過選項設置）。

這些廠商在云端壓縮所有的網站和資源，隨后瀏覽器下載優化過的版本到移動端，而他們如此做的理由是認識到了性能服務于用戶的意義。

移動端的網頁被低估

網絡社區通常會低估移動瀏覽器的重要性，我曾聽到人們說現今的移動端網頁只有iOS的Safari和Android的Chrome瀏覽器，對響應式設計，我們只需顧及320像素寬的viewport。但實際情況比這復雜得多。

如今有不下于10個瀏覽器的市場占有率超過1%，就算只需考慮iOS和Android的默認瀏覽器也并不容易。大致情形來說，在移動端瀏覽網頁的用戶中，iOS占50%，Android占38%，Windows Phone占3%，Opera Mini占5%（包括各類操作系統），剩余4%則為其他平臺。

而如今的Android平臺有64%的用戶使用自帶瀏覽器，這是一個與Google Chrome存在差異并且本身具有多個版本的瀏覽器。此外，最新的三星Galaxy中有一些設備所提供的Android瀏覽器是自定義引擎的版本。

根據viewport的尺寸，僅Android系統的智能手機，如今我們需要處理的像素寬度就包括320、360、400、540。那么我要建議的是，不要低估移動端的網頁，并去了解它那些獨一無二的特征。

1秒內完成首屏內容的加載

在移動設備中，我們把在1秒或是更少時間完成首屏內容（即不需滾動直接顯示的內容）渲染的網站視作是快的。我知道1秒鐘看起來十分快速——特別是考慮到至少有一半的情形是要在蜂窩網絡下來達到的——但這已被證實是可能的。1秒響應可保證用戶聚焦于內容，從而提升轉化率及減少流失。

達到1秒響應時間，首屏內容需要在傳輸控制協議（TCP）的單次往返時間中完成——不能忽略的是普遍的3G網絡幾乎存在半秒的延遲。由于TCP被稱為“慢啟動”，首次響應不能超過14KB以避免二次打包。這意味著首屏內容的HTML和CSS至少必須符合14KB的單次HTTP響應。如果我們做到這個，那么也就達成了1秒加載時間的感官體驗。

這條規則并沒有被明確列出，且要視實際需要而有所調整。然而，由于移動屏幕的首屏內容顯示通常無法達到與桌面屏幕一致的效果，使用響應式設計達到1秒的目標是非常艱難的，但實現的難度是可以通過多種技術的結合降低的。

一個HTML服務所有平臺

一個典型的響應式設計是對所有設備發送單一的HTML文件：電視、桌面、平板、智能手機及其后的所有手機。這聽起來很贊，但我們生活的世界有蜂窩網絡和其他的各種問題。移動設備下你的響應式HTML可能會正確渲染，但它不夠快，本來它應該是可以更快的，這也在影響你的轉化率。

一旦有display: none出現在CSS中，你的站點就會開始變慢。一個從零開始為語義設計的站點，響應式的超載會讓一切工作幾近化為無用；一個站點的HTML里包含的40個外部JavaScript里的絕大多數jQuery插件和功能庫都是為大屏服務的，響應式超載會讓一切崩潰。使用同一HTML，就等同于在所有設備加載同樣的外部資源。

這并不是說不能做單一的響應式設計，只是站點不會自行進行優化。如果你已經留心到了性能，那么你的響應式方案將會不同尋常。

我們來審視一番星巴克的站點，它的主頁是響應式的并且在我們測算的三種viewport下（屏幕截圖見下）看起來都很贊。但查看結構之后，我們發現所有版本都加載33個外部JavaScript文件和6個CSS文件。使用3G延遲網絡的移動設備需要加載到39個外部文件只為顯示這樣一個頁面么？

你可能會認為，“啊，干嘛怪技術應該怪實現”，這是對的。這篇文章并不是和響應式網頁設計作對，它駁斥的是瞄準了響應式卻實現得很糟糕，它駁斥的是以響應式為目標而不顧性能，正如星巴克一般。

若你的響應式站點存在性能問題，那根源可能是出于你所定的目標。若為響應式設計實施規劃，也必須為性能實施規劃。

資源加載

媒體查詢有多種應用方式，通常采用如下中的一種：

• 單獨CSS文件添加多樣的@media聲明；
• 通過link標簽的media屬性為頁面引入多樣的CSS文件。

第一種情形中，只會產生一個CSS文件，故所有設備都會加載全平臺的CSS，數百個無用的選擇器都會被瀏覽器轉譯和解析。

你可能會認為多樣的外部文件是更好的方式，因為瀏覽器會基于斷點加載不同的資源，這是我們在各種博客、雜志、書和培訓課程中得到的信息。

<link rel="stylesheet" href="desktop.css"
media="(min-width: 801px)">
<link rel="stylesheet" href="tablet.css"
media="(min-width: 401px) and (max-width: 800px)">
<link rel="stylesheet" href="mobile.css"
media="(max-width: 400px)">

好吧，你完全錯了。所有的瀏覽器會不分環境地把所有的外部CSS一并加載。下面的屏幕截圖顯示iPhone下載了所有頭部引用的CSS文件， 包括與它無關的。

為何瀏覽器會下載所有的CSS文件？現在假設有一個CSS文件是為豎屏提供的另一個則為橫屏提供。我們不希望瀏覽器在橫豎屏切換時飛快地切換CSS，為防止其間出現頁面裸奔（無CSS的裸HTML頁），我們希望的是瀏覽器提前把所有文件都加載好。而這正是你基于屏幕尺寸定義媒體查詢會發生的一切。

那么可以調整移動瀏覽器的尺寸么？目前基本上不行，但廠商正在準備推出可以像桌面瀏覽器一樣調整的移動瀏覽器，這也是瀏覽器會不顧媒體查詢的寬度匹配規則不分情境加載所有聲明的CSS的原因。

尚沒有任何移動設備具有可伸縮的viewport（目前為止），但某些情形下viewport會被重置：

• 某些瀏覽器的屏幕旋轉；
• viewport聲明被動態更改；
• onload添加了內容導致偏移；
• 支持外部鏡像；
• 某些三星的安卓機同時運行多個app（多窗口模式下）。

在上述變動下瀏覽器會最優化加載可能會需要的所有資源。而不遠的將來瀏覽器對此會更智能，但此時我們尚有問題存留：我們傳送了比實際需要超出得多的資源，從而讓用戶遭受無妄之災。

真正的問題：以響應式設計為目標

正如Lyza Danger Gardner在“當我們談論‘響應式’時我們在談論什么”里所說的，設計師為“響應式”下的定義并不一致，從而會導致溝通誤差。

追本溯源來看，這個術語首次出現是在2010Ethan Marcotte的文章里，隨之而來是同名書籍。Ethan定義其為：以流體網格、彈性圖片和媒體查詢三種技術為多區間的設備屏幕提供最佳顯示體驗。

這并沒有什么不對，問題出現在我們只把它視之為站點效果，而沒有理解其背后更寬廣的更需要達成的目標。

當以響應式設計效果為目標，會變得容易迷失在觀念中。你 真正試著去解決的問題是什么？響應式化有問題么？也許沒有。但你是否把“響應式化”理解為“兼容移動端”？如果是這樣，那你也許犯了一些錯誤。

一個站點的終極目標應該是“服務用戶”，從而實現更多形式的轉化，不論是讓訪客傳播文字、提供信息還是產生消費。沒有高性能的站點就沒有滿意的用戶。

性能在轉化上，尤其是移動端方面的直接影響，已被多次證實。如果這是你第一次聽聞，只要隨便翻閱一本 Steve Souders關于網頁性能優化的專業書就可一知詳細。

知曉目標，決定用何種工具和技術以最佳方式實現。這就是你分析在哪里、如何用響應式方法時應該做的。你使用響應式設計——卻沒有領會它。

響應式與用戶

紐約時報在幾個月前以保持“符合你的預期”為目標重新設計了網站，同時有上千家大型企業驕傲地推出了他們新的響應式版的網站。

紐約時報以有別尋常的方式進行響應式設計，但有一些人對它并非基于相同HTML進行適應性布局而是采取專門的移動站點抱以不滿，甚至有一篇文章冠以“新版的紐約時報WebApp缺失響應式設計的核心”的標題聲討。

沒有人說過響應式設計意味著使用同一HTML去適配所有屏幕尺寸，而這顯然已被當作普遍定義。但這條規則并沒有在任何地方被明確規定，只是我們試圖簡化問題所造成的。

近幾個月內，數家公司都在宣揚著這樣的臺詞：“我們提供了一個新的響應式版網站，讓移動端轉化得到了100%的提升。”但轉化的提升確實是因為站點進行了響應式化么？還是用戶意識到了它是響應式的而更愿意使用？

人們轉化更多僅是因為在移動設備上得到了更快更好的體驗，而無關于采取了何種有別以往的方案（不論它是移動端版本還是桌面版本的縮影）。以此說來，響應性沒有任何優于采用傳統移動方案實現的特別之處，而相同設計下的獨立移動站點若輔以其他技術形成更明智的方案，也能夠達到相同的轉化甚至更佳。

結論

“用戶才不鳥你的站點用上了什么響應式” —— Brad Frost

Brad Frost相當正確，用戶想要的是快速易用，他們并不老去調整瀏覽器窗口，也不需要理解“響應式”的含義。

這是沉重的事實，也并非是所有網站都會面臨的狀況，但也好過總想著“我們做了響應式兼容移動端沒有后顧之憂了。”某些時候，甚至不需要考慮情境地把響應式設計稱之為“性能破壞者”也是有利的，因為這將有助于讓人們關注到性能的重要性。

紐約時報是對的：以用戶為核心，而非工具或技術，甚或是當作設計師們的狂歡。

延伸閱讀

• “遺失核心的響應式設計”Brad Frost
• “RESS: 響應式設計 + 服務器端組件,” Luke Wroblewski
• “當我們談論‘響應式’時我們在談論什么” Lyza Danger Gardner, A List Apart
• “再好的運營也無法回避性能問題” Aaron Rudger, Keynote
• “二度驗證：實境下的響應式設計性能” Guy Podjarny
• “技術本無過錯，執行決定成敗” Tim Kadlec
• “稱之‘響應式設計=性能破壞者’于性能有益” Tim Kadlec

譯文鏈接

響應式設計方法對開發者非常有用，因為它使我們的內容在各種設備上廣為傳播。不用保留幾個獨立版本的網站，也可以摒除諸如縮放和流式布局這些方法的弊端。

本文重點討論設計師遇到最多的3個響應式設計問題，也會提供一些規避錯誤的策略。

縮放、流式布局與響應式

這些術語容易造成混淆，設計師常常錯誤地交替互用。實際上，每個都是布局技巧的顯著進化過程，像技術演進那樣逐一顯現。

縮放布局，旨在相對縮放每一個元素。它們會隨著窗口大小變化動態縮放內容，就這方面而言，它們是響應式的。布局本身保持靜止，通過改變每一個元素來保持一致的表現。

上圖：不同分辨率下縮放布局的例子，這種設計為了統一犧牲了易讀性。

流式布局就不一樣，因為它們隨著窗口尺寸縮放容器元素。通過em這類相對單位可以做到這點，克服了縮小文字的問題。用戶主動縮放時，設計就被破壞了。

上圖：不同分辨率下流式布局的例子，這種設計為了易讀性犧牲了統一。

響應式設計不會縮放任何東西。相反，它會根據窗口尺寸決定顯示哪些內容。

上圖：不同分辨率下響應式布局的例子。

災禍1：菜單折行

如果在頁面頂部使用了導航欄，當頁面展現在小屏幕上時，響應式設計通常會把它“掰”成更緊湊的格式，但這并非總是有效，如果顯示區域比斷點更寬，又不足以在一行顯示所有菜單項的話。結果會導致菜單的折行。

有些方法可以解決這個問題。其一，減少導航欄中橫排菜單項的數量，將它們分門別類。然后選中某類時，你可以通過下拉菜單來顯示子類。

其二，減少斷點的數值。應該以導航欄開始出問題的實際數值為準，而非具體設備尺寸。

其三，不同設備使用不同方式，例如滑動抽屜。

災禍2：使用固定寬度圖片

內容區域通常都隨窗口尺寸變化。所以當固定寬度圖片超出顯示區域時，圖片就被裁剪了。

上圖：糟糕的固定寬度圖片例子，它太大了。于是出現了滾動條，內容被推到屏幕之外。

通過給圖片設定相對單位，可以避免這個問題。或者使用支持響應式的框架（比如Bootstrap），使用響應式圖片class名來控制（例如class="img-responsive"）。

上圖：同樣的元素，用響應式圖片class名的方式，滾動條就不見了。

災禍3：元素的扭曲

這有點晦澀難懂，但本質上，布局顯示在小窗口上的時候，所有未經處理的列都會以行的形式呈現。這是個問題，因為內容的扭曲會不經意地改變設計的層級。

上圖：列變成了行，扭曲了內容。

解決方法顯而易見，但令人驚奇的是，仍有很多人在糾結它：只要明確地設定元素的寬度、高度、內邊距。如果它移出所處位置，蓋住了其他元素，可以通過將它包裹在div容器中，設置外邊距，迫使它回到原本的地方。

規劃有助于避免問題

本文只討論了3種最普遍遇到的響應式設計災禍，還有很多其他途徑會毀了一個好的設計。預防錯誤并不難。現代瀏覽器都有內置的響應式布局測試，好好規劃設計，多做測試。

翻譯:可樂橙

原文鏈接

作者信息：
EMMA GRANT
Emma Grant is a professional freelance content writer from Ireland. Over the past three years she has travelled the world while running her business from her laptop. You find her at www.florencewritinggale.com More articles by Emma Grant

Material Design

2011年，Gmail郵箱的按鈕變得更加扁平化。2012年，Google引入分層的卡片設計，使用更多的空白和精心設計的層次排版結構。經歷了幾年的迭代和提煉，Google尋找到了一種可以貫通的理論體系，即把系統內的各種設計都規范成一種變形的紙片，并套用現實中紙墨的物理模型進行交互，這就是2014年Google I/O大會隆重發布的Material Design。

Material Design提出了平面像素的Z軸概念，通過紙片在物理世界中形態的抽象和提煉，定義了各種信息層級和常用狀態的表達方式，并詳細講解了各個細節的處理方法，就像一本考試大綱，囊括了產品中常用的UI細節，甚至一些UX細節。這里并不贅述，想看詳細的Design Guide請點擊這里（要搬梯子），翻譯版的點擊這里。

如果說UX和UI的展現，是連接產品與用戶的紐帶，那么產品的UX以及UI應從產品的核心邏輯延展并且推演而來。如果說產品的核心邏輯或者技術的實現難易會成為設計展現的限制，那么UX和UI應是在各種限制下所權衡出的最優解。而Material Design則像是架橋說明或者權衡出的通用解，對于眾多產品做以參考。

既然是通用大綱，那么拋開產品僅談設計，難免會停留于“通用”層面，而利用Material Design進行實戰的案例，網上也多是app的一些設計嘗試。恰好在近期的工作學習中，接手一個響應式web站點的改版設計，筆者參考Material Design總結以下三點分享如何實現復雜響應式站點的Material Design。

一、清晰輕量的產品邏輯

奧卡姆剃須刀法則同樣在產品架構設計中適用，越簡單的架構越有利于產品的生長。清晰輕量的產品邏輯，會減少用戶的負擔感，從而提高交互上的效率和愉悅感。

分析Material Design，會發現Google歸納了兩類復雜內容信息的層級關系，分別是Card和Tile（List 以及其他相似定義屬于同類的內容信息層級），其他定義多用于UI結構及細節。其中，Google定義Card是一種多功能信息的聚合入口，信息層級應較高，體現在Z軸應高于其他信息，視覺上有陰影表現并加以圓角處理。而tile（或同類信息列表）則是（同類或相關）信息的模塊展現，信息層級應較低，體現在Z軸應略低于其他信息，視覺上應無陰影表現不加圓角處理。其結果是從視覺層面讓產品對象更高效、更簡單，同時也更具物理世界的“真實感”。

最近接手的項目是Gekec.com的全站改版。Gekec（革客）是Geek和Maker交集，喜歡革新，喜歡技術范兒、新潮的科技消費品，喜歡自己動手創造產品，Gekec.com也就是這類人的聚集地，整個產品囊括電商、資訊（或h5宣傳）、拆機、以及社區討論等各種功能，改版前邏輯復雜，功能繁多。改版開始之初，筆者了解到革客群體時，便認為理性加濃重Geek味道的Google風格或許是最適合Gekec.com的視覺體系，然而復雜的產品邏輯不能給用戶帶來高效的交互體驗和愉悅的使用感受，視覺上也并不能很好的通過Material Design推演并且變化，所以梳理出清晰、輕量且方便視覺統一的產品邏輯成為第一任務。

Gekec.com的產品全功能在此并不贅述，Product Feature全部為達成宜家式的體驗式設計，經過梳理可以歸納成三層，首層為體驗層（多入口的首頁封面）、第二層為貨架層（包括商城模塊、拆機模塊、體驗模塊）、第三層為詳細、操作層；

如上圖，輕量的產品結構即可方便設計的推演。例如其中第一層可以通過H5靈活排版做產品全方位體驗，第二層與第三層的關系即可利用Material Card和Tile表現。Card表達了全部信息的聚合和入口，tile則表現同類信息的羅列。從card跳轉到最終頁應有一種卡片展開的體驗。

二、適宜UI推演的響應辦法

在產品邏輯清晰簡潔的基礎上，一套適宜Material Design變化的全尺寸響應辦法就成為復雜響應式網頁設計的核心內容，響應辦法能夠直接決定功能模塊的響應邏輯以及UI的變化。實際操作中，響應辦法的確定主要就是確定柵格和占比。

1）柵格

網頁柵格系統是從平面柵格系統中發展而來。對于網頁設計來說，柵格系統的使用，不僅可以讓網頁的信息呈現更加美觀易讀，更具可用性。而且，對于前端開發來說，網頁將更加的靈活與規范。柵格系統的具體含義以及使用方法在此不再贅述，感興趣的朋友可以參考淘寶UED的一些文章：

網頁柵格系統研究（1）：960的秘密

網頁柵格系統研究（2）：蛋糕的切法

網頁柵格系統研究（3）：粒度問題

網頁柵格系統研究（4）：技術實現

在Gekec.com的項目中，經歷產品功能模塊的梳理，筆者使用了12柵格系統，目的是能夠滿足2、3、4、6的頁面等分。注：具體柵格系統的建立應因產品和設計所決定，柵格系統并不是萬能的，而確定的柵格系統可以為整個響應式設計做規范性參考。

2）占比

A.占比

如上文說，12柵格約束網頁的內容區，而網頁的內容往往并不占據屏幕的全部寬度，而是在兩側留有間隙，營造空間感。由于屏幕的限制，這種空間感在移動端設備顯得更加重要，如圖，然而強加固定的margin pixel會使得12柵格占比不定，難以控制設計效果。

所以占比應是12柵格寬度對應屏幕的比值，即：

12柵格寬度X占比=屏幕寬（臨界點）

優秀而巧妙的占比確定可以讓網頁設計呈現在各個主流屏幕上均是100%像素。

這里簡單解釋一下，若一個200px寬的元素在1200px寬的屏幕上，其占比為16.67%，同樣的邏輯，到1024px的屏幕上這個占比16.67%的元素即占據了170.67px，這樣的情況下，某一個物理像素無法占據100%，在完美主義的設計師眼里，是無法接受的事情。而巧妙的占比，可以讓元素在各個主流屏幕占據100%像素，完美展現設計意圖。

B.臨界點

臨界點（breakpoint）是指響應式網頁發生布局變化的關鍵點，如“當屏幕寬度小于480px時加載…樣式，當寬度在480px- 600px之間時加載…樣式”。響應式網頁理論上有無數種尺寸，我們不可能也沒有必要為每個尺寸都去做設計，需要做的是選定幾個臨界點做設計，在兩個臨界 點之間是延續上一個臨界點的布局。

臨界點確認總體目的就是為了保證頁面在手機（屏幕很小）、平板（屏幕中等）、PC（屏幕大）上加載相應的樣式，然而經驗較少的設計師往往會苦惱一個問題，那就是高像素的手機屏幕和低像素的平板屏幕應如何處理。例如設計師會擔心1080p的手機加載大屏幕頁面，或者720p的平板加載小屏幕頁面。

但需要注意的是，響應式網頁不同于APP的屏幕適配。網頁是沉浸于瀏覽器的產品，瀏覽器所啟動的屏幕像素才可以被認為是臨界點的參考點，為此，筆者做了一些測試，如下表，可以看出不少1080p手機在瀏覽器中僅啟動360px，而神奇的ipad無論是不是retina屏幕，無論是不是mini，均顯示1024x768px 。

從上表可以看出，許多擔心其實并不需要。綜上，在Gekec.com的項目中，筆者為達到多數主流屏幕100%像素的追求，即需達到內容區在主流屏幕臨界點的占比可以被12等分，進而獲得12柵格，即：

12的公倍數X占比=主流屏幕尺寸

項目中經歷了一些測試和取舍，最終確定占比為93.75%，臨界點為1280px、1024px、768px和320px。

具體為：

1280px<=screen，占比93.75%，12柵格在典型屏（1280px）寬1200px；

1024px<=screen<1280px，占比93.75%，12柵格在典型屏（1024px）寬960px；

768px<=screen<1024px，占比93.75%，12柵格在典型屏（768px）寬700px；

320px<=screen<768px，占比93.75%，12柵格在典型屏（320px）寬300px；

如上圖的占比劃分，頁面元素可以完成靈活、規范的響應。可以以此作為整個產品的響應辦法，在此基礎之上，可以對Material Design進行全面的推演。

三、精雕細琢的頁面細節

如果說產品邏輯是整個網站的骨架，那么精雕細琢的頁面細節則可以比喻為網站的氣質靈魂。有輕量級的產品構架和明確靈活的響應式辦法后，即可通過Material Design的官方說明進行全面設計。在Material Design的說明中，已經詳細解釋了各個狀態的約束和細節，在此并不贅述，筆者僅挑選一些典型的細節。

1）css動畫

Material Design中開篇第一章節便講述了動畫給用戶的直觀感受，說明感知一個物體有形的部分可以幫助用戶理解如何去控制它。一些細節位置的動畫能給用戶體驗上的驚喜。然而在web端實現動畫效果并不像app里那樣的容易，大量JS也會影響頁面加載速度甚至影響頁面其他代碼。所以筆者選擇利用CSS對頁面一些細節加以動畫效果。

A.點擊按鈕

Material Design給出了一種ripple button，抽象了人用手觸碰卡片的漣漪效果，給用戶一種全新的使用體驗，歡迎來Gekec.com點擊嘗試。

B.輸入框

簡單的Description和一條橫線，抽象了實體文字卡片的填寫過程，可以幫助用戶對輸入區域有實體化的理解，歡迎來Gekec.com點擊嘗試。

2）文字樣式

Material Design中強調“同時使用過多的字體尺寸和樣式，可以輕易的毀掉布局”，并約束了常用的基本樣式就是基于12sp、14sp、16sp、20sp的字體排版。

熟悉Android的朋友可能對sp的概念并不陌生，sp：Scale-independent pixels，它是安卓的字體單位，以160PPI屏幕為標準，當字體大小為 100%時， 1sp=1px；然而響應式的網頁并不是安卓，網頁更需要物理像素的尺寸約束，所以筆者在所劃分的臨界點計算了一下所測試屏幕的瀏覽器PPI，如下：

iphone5: 320x568px/4英寸/PPI=162.95

榮耀6：360x640px/5英寸/PPI=146.86

ipad：1024×768/7.9英寸/PPI=131.96

ipad mini：1024×768/7.9英寸/PPI=162.03

從上面的數據可以看出，大多瀏覽器啟動像素所產生的PPI大約在160左右，所以某段文字在PC端約束的物理像素尺寸，直接同樣尺寸應用于移動端時，應該也可以產生不錯的體驗效果，所以設計時可以直接將Material Design的字體sp尺寸轉化為px來使用。Gekec.com的項目中，筆者只約束一套字體樣式，在方便前端開發的同時，完成了不錯的響應式效果。

3）顏色

Material Design Guide中給出了若干明亮鮮艷的顏色，并且指定了顏色的主要展現和層級變化，可供設計師選擇。

在實際操作中，通過商品內容的分類，筆者直接選擇Material Design中的顏色，作為每類商品的主要顏色，而在一些重要的操作入口，顏色應與主要顏色有明顯區別。筆者應用色環在Material Design Color基礎上，配合內容建立整個網站的顏色體系：

A.主體顏色以及層次根據內容確定，直接參考Material Design Color

B.應用色環分析整體補色間色

將所有主體顏色步在色環上，可以分析出補色位置應為上方紅框位置，應用于有明顯區別的重要入口，如“加入購物車”、“砸￥1元參與”，“結算”等等；而間色位置應為下方紅框位置，應用于不明顯的細節變化，如文字hover，文字鏈接等；

4）間距

Material Design Guide中已經嚴格約束了各個元素狀態下的間距，但為了滿足全站響應式布局在主流屏幕展現，筆者仍然使用了8px原理對一些間距進行了調整；在很多設計師研究8px原理并進行設計的同時，筆者仍然需要強調，響應式web的設計應基于瀏覽器的像素尺寸，并不是基于ios和android的屏幕尺寸。具體可以參考上面已經分享的表格進行實驗。

這里分享一些8px的文章，感興趣的同學可以看一看：

一切為了程序猿！詳析手機端的8PX原理

一張圖解釋手機適配8px原理(原創)

總結：

Material Design已經給出了詳細的設計細節和原則，但不一定適合每一款產品，設計師需要弄清自身的產品是web還是app，邏輯是什么樣，才可以進行細化的設計工作；深入了解產品邏輯的基礎上，確定的一套響應辦法和頁面細節，能夠保障設計的展現并帶來不錯設計效果。Material Design作為即蘋果、微軟之后最新推出的設計語言，充滿了濃郁的Google風情，能夠給用戶提供新鮮的視覺體驗，希望有越來越多的設計師會嘗試用Material Design進行設計。