當咱們在作手機端H5網頁設計稿時(固然包含微信端的H5網頁設計),若是沒有作過相似的移動端的設計,UI設計師和前端工程師確定會糾結的。若是是app設計師,就不會那麼糾結啦。html
那麼多手機屏幕尺寸,設計稿應該按照哪個尺寸做爲標準尺寸。如今已經有2K分辨率的手機屏幕了,設計稿是否是也要把寬高跟着最大分辨率來設計。顯然不是。前端
請注意:(如下全部討論內容和規範均將viewport設定爲content=」width=device-width」的狀況下) 也就是咱們的H5頁面前端代碼裏面必須包含瀏覽器
<meta content="initial-scale=1.0,user-scalable=no,maximum-scale=1,width=device-width" name="viewport" />
<meta content="telephone=no" name="format-detection" />安全
根據目前市場流行的手機移動終端,統計他們的設備獨立像素。微信
在這裏,25學堂也跟你們分享一個羅列了當前最流行的手機的全部尺寸大小規範: http://screensiz.es/phone 值得你們好好細看的智能手機尺寸圖表。前端工程師
也只有iPhone6+採用了分辨率降頻處理。app
具體看下圖:iphone
有興趣的小夥伴能夠去嘗試不一樣的尺寸,好比1倍的、2倍的、3倍。最終得出的試驗結果是。H5的設計稿通常設計爲640x1136px便可。 既知足了顯示需求,又能下降用戶加載圖片須要的帶寬。工具
能夠用各類分辨率的移動智能手機查看咱們設計的H5頁面時,固然,也會出現以下的狀況,內容顯示不全,甚至一些重要內容和按鈕都會被遮擋。佈局
第一:背景圖片必須採用background-size:cover;來實現。
第二:咱們在進行H5頁面內容規劃佈局設計的時候,不能把重要內容放在太偏下的位置或者偏上,不然前端佈局時可能出現內容顯示不全的狀況。
經過對比可得:
除去將瀏覽器全屏顯示的狀況,幾乎全部狀況均會有頂部的狀態欄和導航欄。
iPhone的設計標準,狀態欄和導航欄的獨立像素高度分別爲40px和88px。
因爲Android系統能夠更改狀態欄和導航欄的高度,這裏能夠取默認值爲48px和100px(這些尺寸網上都可查)。
那麼就會把網頁內容往下擠,進入盲區(根據不一樣的佈局方式可能擠出視口,便可視區域之下,)。取這兩個系統者的最大值爲148(48+100),以下圖5,設計稿要儘可能保證單頁下面沒有重要內容。
圖5
那麼在全部屏幕大小上把重要內容顯示徹底,就要注意市面上存在的小尺寸手機屏幕,如今絕大部分智能手機分辨率都在640x960px(iPhone4分辨率)之上,因此只要把重要內容放在上圖5中的盲區之上便可。計算後的最安全高度爲812(960-148=812)。
在此總結,通常狀況下,以現有市場上流行的移動智能手機,單頁翻轉(非延伸向下的長頁面)設計稿尺寸爲640x1136,在高度爲812處設置一條安全線(參考線),將重要的內容佈局在這條安全線之上。
移動端H5頁面的設計稿尺寸大小規範內容以下:
一、像素是沒有寬高的(不要被Photoshop中的像素格欺騙),它只表明一個採樣的色值。
二、任何圖片做爲數據信息被保存在存儲盤中時,只有寬高像素數是有意義的,此時的ppi對於圖片來講時沒有任何意義,也並不能描述這個圖片有多少英寸的寬度或者高度,而只有在被打印出來後纔有ppi的意義,被打印出來才能夠描述這張圖片有多高多寬。
三、平時製做H5頁面時設計原型時,產品經理出的原型稿建議屏寬爲320px,用這個尺寸一是爲了瀏覽方便(如今不少手機的屏寬達到1440px,用這個尺寸去模擬顯然不現實),
二是以iPhone5s爲標準的手機屏寬較小,進行內容排版佈局時屏寬應該向下兼容。
四、製做設計稿時,設計師應該把原型稿上的全部尺寸進行2倍處理。這樣設計稿在移動設備上預覽即可保證清晰。而前端切片時,按照如今流行的作法,能夠直接使用原型稿上的尺寸,也就是設計稿上的1/2。
五、通常狀況下,H5頁面設計稿作成640x1136px是最爲穩妥的尺寸,在812px高度處增長一條安全線,重要內容在此線之上(網上有些文章說安全線是960px處,我的認爲不太準確)。既保證了在移動設備上顯示清晰,也保證了素材的最小尺寸。
最後在這裏,25學堂給H5工程師推薦2個不錯的圖片壓縮的工具。
一、騰訊智圖(http://zhitu.isux.us/)
智圖--圖片智能自動優化平臺,爲你的圖片智能選擇合適的圖片格式,爲你壓縮圖片以便節省帶寬優化體驗,爲你提供WebP圖片讓你的站點高大上
二、tinypng(手機APP設計必備圖片壓縮神器-TinyPNG),這裏的圖片壓縮仍是至關好用,能夠節省用戶很多帶寬。
以上部份內容來源:zikoman.lofter.com 感謝ZIKO的分享和實踐。