作為專業的頁面構建工程師，除了在專業技能上有很高的要求以外，還需要具有一定的對設計圖的審稿能力。審圖，并非是意味著追求跟PSD一模一樣，甚至耗費大量時間截屏跟PSD去“對像素”。在我的理解中，審圖是通過對UI設計稿的分析，充分理解UI設計師的意圖，再結合UE的交互狀態，從中做到真正的“還原設計稿”。

　　事例一：有取有舍，方是領悟

　　比如，在這樣一張設計稿中

　　設計師的意圖：

　　這個話題列表的行高19px，每個單條話題下面是有4px邊距的。而話題標題與其自身的描述文字之間沒有間距。

　　頁面構建工程師的分析過程：

　　由于該模塊對行高的重置，已經“約定”好了，文本規范的行高是18px。通過溝通，設計師認可將本段落的行高由19px改為18px。但這僅限于標題與描述文字之間的行距。而標題與標題之間4像素下邊距，從構圖上說明了單條話題之間的段落關系，不能一味的用18px行高解決。因為通過我們對設計稿的理解，設計師用這4像素，拉大了標題之間的間距，從視覺上形成了段落感。所以對于重構來講，這4像素萬萬不能忽略，不然從視覺呈現的角度，設計師就不能容忍了。所以，有取有舍，方是領悟。

　　在這個模塊的制作中，還發生了一個小插曲。如下圖：

　　設計師的意圖：

　　這是11號的細明體，因為是點綴，又是提示性圖片，所以小于前面標題的宋體12號字。

　　頁面構建工程師的分析過程：

　　起初，重構組的同學在討論設計稿時，都提議把它們做成活文字，就是宋體12號。彩色圓角塊用CSS3寫，擴展性特好。因為這個模塊是運營團隊負責，在未來也更能夠滿足隨時更換文字的需求。萬一以后再來個“驚爆”、“頭條”啥的呢?每張圖都重新切、重新拼么?

　　但是，站在理解視覺設計的角度，這種小tag講究的就是精致。如果做成文本文字，雖然面臨將來的需求變更時，會有一定程度上的成本，但是與正文區別太小，就突出不了小tag的感覺，也顯得沒有那么精致了。所以在各種糾結權衡下，我最終選擇把它們做成了圖片。

　　事例二：麻煩的CSS寫法能換來更好的視覺效果

　　再舉另外一個例子，我們有這樣一個模塊。

　　設計師的意圖：

　　頭像與名稱頂端對齊，微群等級圖標與微群名稱底部對齊。

　　頁面構建工程師的分析過程：

　　因為微群等級圖標的尺寸是16×16，高于文字本身的高度，為了在各瀏覽器下都保證這個對齊效果，我采用了這樣一種思路。

　　按視覺稿百分百還原，做出來左圖的效果，雖然css代碼看起來有點兒麻煩。但是如果怎么簡單怎么寫，做出來的頁面效果，卻沒有這樣做的實際效果好。

　　事例三：頁面構建細節上多處理一點點，用戶體驗提升一點點

　　還有這樣一個模塊：

　　頁面構建工程師的分析過程：

　　通常遇到這樣子的模塊，我們會這么劃分結構

　　由于用戶頭像只有30px正方的大小，所以算來用戶名稱只能顯示2—3個漢字，其實很難讓用戶直觀的區分出這個人究竟是誰。如果通過傳統的思路來做，產品和設計估計都不會滿意。那么，頁面構建的過程中，我們就要想辦法擴大用戶名稱的顯示區域。

　　于是，我采用下面這個切圖思路，在不改變HTML結構的情況下，只通過改變css，達到了擴大用戶名稱顯示區域的目的。

　　給用戶頭像名稱模塊定寬，然后利用margin的負數值，讓vs向左偏移。蓋住部分頭像1的區域。最終效果，可以顯示4個漢字。

　　重構組的實習生同學，由于沒有項目經驗，導師講什么就是什么，于是一聽到導師說“對像素”，就真的去專注于此，萬一設計稿本身有些問題，也不會判斷一下，結果把自己搞的挺為難。有時候，拍屏靜態頁面的呈現效果與設計稿去對像素，其實沒相差幾個像素，但靜態頁面看著就不跟設計稿感覺不一樣。這時候總是需要不斷的修改、截屏、對像素、再修改…這樣的重復勞動，在快節奏的開發中不但浪費時間，更有可能由于不得要點，在數據的裝載后越發“不是那么回事兒” 了。還不如靜下心來，先去細細的審圖，和設計師充分的溝通，有取有舍，聰明判斷，然后再去做具體開發，出來的頁面不需要這么焦頭爛額的打補丁對像素，也許能更好得達到設計師設計的初衷呢。

　　文章來源：微博UDC