一、屏幕尺寸的快速變化,iphone爲320x480,分辨率在將來能夠繼續發展。
二、網速對於用戶的web使用體驗有着巨大的影響。
三、對於標準的支持。瀏覽器對於標準的支持也頗有限。
四、輸入的方式。觸屏設備,各類手勢操做。
五、使用的環境。設備在物理上和架構上的特性,並非咱們在針對設備進行設計時須要考慮的惟一因素。瞭解使用環境是從相應設備的Web到響應人的Web的關鍵。
響應式設計的提出是由 Ethan Marcotte提出的概念,css
根據Ethan Marcotte的定義:html
Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts.前端
簡單來講就是適配各類終端的網頁設計。這裏容易混淆的是自適應設計(adaptive web design),國內有些人把響應式設計也翻譯爲自適應設計,兩者有着一些差異。node
there are several distinct layouts for multiple screen sizes, and the layout used depends on the screen size used.ios
根據不一樣的屏幕寬度加載不一樣的結構。以下圖所示,上面的是響應式佈局,下面的是自適應佈局(自適應能夠是流式佈局,也能夠是固定佈局,而響應式佈局只能是流式佈局)
注:圖片來源於GEOFF GRAHAMweb
響應式設計要求更多的代碼,它可以很好地適應全部的屏幕尺寸。
自適應設計只是針對於某幾個特定的尺寸,一旦有新的屏幕尺寸出現,須要增長一些新的代碼。
更加詳細的解釋能夠看一下《What is the difference between responsive vs. adaptive web design?》chrome
The goal is ensuring content is optimized for our audiences no matter what device they're on.npm
--Garrett Goodman編程
如今都是把這兩種佈局混合起來使用,剛開始咱們是按照幾個主要的屏幕分辨率作出設計稿,在重構過程當中是按照響應式設計的特色,確保其可以在各類屏幕分辨率中都可以正常顯示。
折衷的方法,確保在主要的分辨率屏幕上的效果與設計稿徹底一致,可是在其餘比較次要的分辨率下,很難保持一致,特別是一些採用百分比的元素,因此這時候的對齊只能寄但願於左、右、居中對齊。bootstrap
適應全部設備,更容易管理。
一個URL:讓你的用戶在移動設備上更容易找到,並且不須要任何的重定向,這在較慢的網速下特別的有用。
容易作搜索引擎優化:不須要爲移動設備建立特定的內容,可讓移動設備使用桌面網站的搜索引擎優化的好處。
易於營銷:網站在移動設備上顯示,對於營銷部門來講不須要增長額外的工做量。
成本低:簡單的數學運算,一個網站比兩個網站要便宜吧。
一個網站:讓一個網站適配全部網站,對於你來講很容易,但不必定適合你的用戶。你須要在同一個頁面上展現不一樣的側重點,以便使用該平臺的最大優點,最大限度的提升你的轉化率。
技術:響應式設計他是一種較新的技術,在一些老的設備和瀏覽器中加載頁面速度過慢,甚至是徹底不支持。
用戶體驗:移動端和PC機上的用戶體驗是徹底不一樣的。因此一個網,甚至是響應式設計,在兩個平臺上都會損害您總體的UX。若是你試圖使用相同的界面來知足移動和桌面的兩個平臺的用戶使用,到最後可能誰都沒法知足。
若是把網站做爲一個單獨的網站,若是網站的內容與桌面版的內容相對缺乏,致使用戶回到桌面端的網站,google會記錄這種選擇,使搜索排名下降,國內百度就不知道會怎樣。
因爲存在不一樣的網站,因此有一個版本的問題,網站版本錯誤可能會致使遊客到以前的版本。
搜索排名能夠從移動端和桌面端雙端獲得很強的反向連接配置文件(搜索有關),有利於在搜索結果中獲得較先的的搜索排名。
一開始就構建完整的功能,而後再針對低版本瀏覽器進行兼容。
缺點:舊瀏覽器的用戶體驗會有誤差
針對低版本瀏覽器進行構建頁面,保證最基本的功能,而後再針對高級瀏覽器進行效果、交互等改進和追加功能達到更好的用戶體驗。
如今有兩種設計觀點,移動優先和桌面優先。
從桌面開始向下設計、 從移動端開始向上設計
兩種觀點主要因爲面向的主流對象的不一樣,優雅降級主要是面向pc端爲主流。如今工做室採用的就是優雅降級。
移動優先是從移動端開始,而後再逐漸向桌面端適應。
觸摸設備上的觸摸區域是否是足夠大
設計方案在什麼樣尺寸的屏幕上顯示摺疊菜單按鈕
人們與動態元素的交互有多複雜
增長一個斷點是否可以提高設計
是否能夠針對某一給定設備加強使用體驗
哪些微小的調整對於支持更大範圍的設備會有所幫助
關於響應式斷點的設置,一開始咱們要明確咱們的目的:
考慮全部設備的分辨率,保證任何分辨率都可以有良好的體驗
考慮主流屏幕分辨率的大小,確保這幾種分辨率下與設計稿有着良好的重合性,其它分辨率下沒有出現明顯的錯位和排版錯位就能夠了。
第2個目的實際上是第1個目的的子集,第1個目的對於應對將來分辨率的變化具備很強的適應性,但同時伴隨着技術要求的提升和工做量的增大。
根據百度流量研究院的統計近期6個月分辨率使用狀況,
bootstrap4.0斷點設置以下
1380px、992px、768px、544px
我所在團隊所設置的斷點
2k、1920px、1200px、960px、768px、450px
對於響應式設計稿,因爲設置了不少斷點,因此咱們須要作出多少份設計稿?咱們不可能把全部分辨率的設計稿都繪製出來。以我作過的響應式網站項目,設計稿可分爲:
>1200px 以1200px爲主體的1920px稿 >960px 以960px爲主體的1200px稿 480px~768px 768px稿(兩邊不貼邊,留5px左右) 手機 <720px(畫布大小爲720x1280,不貼邊)
歡迎你們一塊兒討論。
瀏覽器會涉及到兩種像素:設備像素和css像素
設備像素是物理概念,而CSS像素是WEB編程的概念
iPhone等設備上一個css像素實際上對應兩個設備像素,這也是二倍圖的由來。
<meta name="viewport" content="initial-scale=1,maximum-scale=1,user-scalable=no,width=device-width">
user-scalable=no
是禁止縮放的意思。
其他屬性都是爲了保持設計稿原來的大小,防止因爲手機自身瀏覽器渲染不一樣的緣由使網頁在不一樣手機瀏覽器中的效果不一樣。
<!-- 從桌面 icon 啓動 iOS Safari 是否進入全屏狀態(App模式) yes | no--> <meta content="yes" name="apple-mobile-web-app-capable"/> <!-- iOS Safari 全屏狀態下的狀態欄樣式 default | balck | black-translucent--> <meta content="black-translucent" name="apple-mobile-web-app-status-bar-style"/> <!-- iOS 設備上禁止將數字識別爲可點擊的 tel link --> <meta content="telephone=no" name="format-detection"/>
對於ios設備進行一些初始化操做。
@media的查詢類型: 10種類別,經常使用爲screen
更多Media類型參見:Media types
@media screen and (min-width: 1200px) and (max-width: 1920px) { .class { background: #fff; } }
< link rel ="stylesheet" type ="text/css" href = "index.css" media = "screen and (min-width: 1200px)" >
not: not是用來排除掉某些特定的設備的,好比 @media not print(非打印設備)。
only: 用來定某種特別的媒體類型。
all: 全部設備,這個應該常常看到。
咱們注意一下如下三種寫法的不一樣之處:
@media (max-width:1200px)
窗口小於1200px的時候應用後面的樣式
@media screen and (max-width:1200px)
識別爲screen設備,且窗口小於1200px的時候應用後面的樣式
@media only screen and (max-width:1200px)
對於only關鍵字,w3c的解釋爲
The keyword ‘only’ can also be used to hide style sheets from older user agents. User agents must process media queries starting with ‘only’ as if the ‘only’ keyword was not present.
意思是對於only,老的用戶代理會隱藏掉後面的樣式內容,而(可識別only)用戶代理在執行媒體查詢的時候,會忽略only.
stackoverflow有更多詳細內容,能夠參見下方的參考資料連接。
最爲常見
的實現方式。優勢是對於頁面擁有跟多的控制權。大屏幕的則會留不少空白,對於小的屏幕就會出現滾動條
採用百分比
,是頁面具備可變的特性,可避免出現的大片留白。可是有些文本的行款在大屏幕上看起來太寬,小屏幕上有太窄。
與流體佈局相似,可是採用em
做爲單位,em爲當前字體的大小。除了跟流體佈局相似的優勢外,用戶增大或減小字體,使用彈性佈局的元素的寬度也會等比例變化。也會出現水平滾動欄。
幾種佈局的集合。
無需考慮級聯
(父元素的字體大小對於子元素沒有影響),可是對於維護來講,當你想要改變全部字體的大小時,你得修改全部的(sass改變了這種現狀,由於sass擁有變量)
是級聯的,可是上下文環境若是變了,基準也會隨之而改變。
與em差很少,只有處於em直接與文本大小相關的考慮時,使用em才更有意義。
在IE中IE會誇大實際應當調整的字體大小,能夠設置
body{ font-size:100%; }
這樣就不會有誇大的問題了。
rem與em的區別在與rem的大小與根元素——HTML元素有關,可以避免發生在嵌套元素中的級聯問題
兼容性能夠看這個兼容性;更多的介紹能夠看響應式十日談第一日:使用 rem 設置文字大小.可使用sass進行自計算,爲了考慮兼容性,可使用下列代碼
span{ font-size:16px; font-size:1rem; }
若是在沒有css預處理工具以前,rem因爲考慮兼容性仍是要修改全部的像素,可是因爲相似sass之類的工具,這個問題就不會增長太多的成本,因此咱們能夠大膽的使用rem這個單位,可是並非全部的樣式都是適用rem。
詳見Responsive Images 101, Part 1: Definitions
A method for providing the browser with multiple image sources depending on display density, size of the image element in the page, or any number of other factors.
其餘的我建議閱讀一下這一系列文章:《響應式圖片101》
如何加快和優化響應式佈局網站的頁面加載速度
響應式設計的性能優化
比較方便快捷的一種方式,但有時與真機會有一些差異。
這個要安裝兩個軟件,比較麻煩,通常不建議
響應式網站開發跨平臺真機調試工具
重磅推薦Browsersync,很是的方便快捷,配合前端自動化流程工具,一修改代碼,全部設備都實時刷新。要確保處於同一區域網內。
如下是可能用到的命令:
npm install -g browser-sync browser-sync start --server --files="*"
性能
移動設備外部的樣式表和腳本會嚴重下降站點的性能,不會被緩存,雖然隱藏了內容,可是標籤和css仍會被下載。
使用環境
主要用戶的使用環境
內容協商
根據內容的重要性去從新組織或者重構你的站點的內容。
時間投入
響應式網站須要花費更多的時間,若是項目時間很緊的話,要好好考慮一下。可是多花費的時間會在維護成本中獲得彌補。
支持
瀏覽器支持,漸進加強和優雅降級
廣告
隨着現代瀏覽器市場份額的愈來愈多,hash操做的兼容性愈來愈好了,因此咱們能夠很方便的利用hash實現一個頁面的碎片化,好比同是www.example.com這個網址的頁面,我能夠把其分解成三個子頁面爲www.example.com#page=一、www.example.com#page=二、www.example.com#page=3,把數據的拉取交給hash值,而後在移動端單獨加載一個碎片頁面如www.example.com#page=1,而後採起跳頁面的方式轉到www.example.com#page=2等,而在桌面端則一次性把幾個hash值所控制的數據全都拉取下來在一個頁面上展現,這樣就用hash來操控桌面端與移動端的數據,使之更符合各自的狀況。
在客戶端每一次請求數據的時候,都會告訴服務端本身的身份,也就是所謂的UA了,客戶端JS能夠獲取UA值,服務端也能夠獲取UA值,利用UA值就能夠識別各類終端,而後作頁面跳轉的工做了,這裏能夠依賴node很好的作UA檢測與跳轉。其原理基本是:客戶端訪問咱們的URL,比方說www.example.com,用node獲取請求request,而後判斷其UA類型,根據UA瀏覽器再去後臺拉取數據,後臺數據返回給node,再由node返回給用戶,雖然多了一個node環節,可是操做的靈活性也就高多了,這樣對外只有一個URL,對內能夠存在多個api,如api-pad.example.com、api-phone.example.com,對於內部能夠是全數據的,而後再在node環節作UI封裝,鬼道也建議在桌面端直接返回頁面而在移動端返回數據,這樣使得移動端更加輕量。
想學響應式設計?來看史上最全的響應式設計資源庫
中國響應式網站分享