有時候前端實現(xiàn)的頁面跟設(shè)計稿的差別會比較大？而致使這種情況的原因是什么呢？前端實現(xiàn)效果好不好，真的是碰運氣么？

記得很久之前與我同住的室友經(jīng)常加班到半夜三更才回家，我很是不解。后來閑聊才得知她們公司的設(shè)計師待前端開發(fā)完畢之后需要一點點的對稿走查，非常浪費時間。而且設(shè)計這邊不但需要標注好給開發(fā)，然而開發(fā)照著做完依然存在諸多問題。

我也曾對接過幾個前端卻都沒有出現(xiàn)過這種前端與設(shè)計稿相差很大的問題，不需要標注也無需怎么走查，即便發(fā)現(xiàn)問題也是非常稀少。以至于我一度以為僅僅是開發(fā)與開發(fā)之間水平差異的問題，也非常慶幸自己沒有遇到過那種實現(xiàn)效果差的開發(fā)。

然而好景不長，就在前段時間我對接了一位前端開發(fā)，落地效果非常不理想。讓我比較困惑的是前端實現(xiàn)效果好不好，真的是碰運氣么？

那我們來探討一下有什么方式能夠在面對不同的前端開發(fā)來規(guī)避這些問題，首先我們需要了解為什么前端實現(xiàn)的頁面跟設(shè)計稿的差別那么大呢？

一、前端實現(xiàn)與設(shè)計稿差異背后的問題

H5相對于APP在設(shè)計上的區(qū)別：

設(shè)計師相較于前端來講是最接近產(chǎn)品用戶體驗的人，但是畢竟APP原生系統(tǒng)界面設(shè)計跟H5頁面設(shè)計還是存在很多差異性的。所以很多不太熟悉H5技術(shù)限制的設(shè)計師還是很容易犯一些錯誤的。

為了更直觀的對比APP與H5的頁面設(shè)計差異，下面我們來舉個栗子：

天貓APP與H5的頁面對比

（1）功能的簡化

我們通過對比發(fā)現(xiàn)天貓H5的首頁功能比APP的首頁功能減少了很多，例如：掃一掃的和消息功能以及底部導(dǎo)航都沒有了。同類的banner廣告布局也沒有這么復(fù)雜，只是簡單粗暴的大banner下方放幾個功能入口。

（2）突出基本功能

例如天貓的App端商品類別放置在第二屏，而H5的商品分類在首頁頂部原掃一掃圖標的位置，點開就是一個抽屜式彈窗，更簡潔直觀的功能更有利于增強H5的操作體驗。

（3）頂部navigationBar不可更改

H5的頂部navigationBar是不可更改的，不管任何軟件打開H5，其頂部顯示的始終是原打開此H5頁面app的navigationBar。所以一般如果需要設(shè)計頂部導(dǎo)航的時候，我們是基于navigationBar的下方再放置一個navigationBar的。這里也就是如上圖右側(cè)所示顯示了雙層navigationBar的效果。

（4）常使用頂部返回按鈕

h5頁面較長的情況下經(jīng)常會使用頂部返回按鈕，這個類似與pc網(wǎng)頁端的交互形式。目前多數(shù)h5已然淘汰了此交互功能，以頂端自帶的返回按鈕來替代。目前天貓也僅在首頁使用，因為如果沒有這個按鈕的話點返回會退出天貓。所以，具體使用與否還需視情況而定。

（5）加載進度條

每進入一個新的h5頁面頂部都會顯示加載進度條，如果是原生系統(tǒng)內(nèi)嵌的H5頁面注意這里是可以自定義進度條樣式的。

二、為何設(shè)計師盯著改還是不滿意？

那么基本上了解了以上H5與APP設(shè)計上的基本差異，我們在查看某些前端開發(fā)后期實現(xiàn)效果的時候，還是需要花費大量的時間校對。有些問題甚至能改個2，3遍還是不太滿意。

（1）設(shè)計師的苦惱

那么我們先來看下我們身邊普遍存在的真實情況，以下為某公司設(shè)計與產(chǎn)品的對話：

我曾經(jīng)詢問過身邊的幾個設(shè)計朋友，她們都坦言工作中經(jīng)常會花費不少時間與前端校對落地稿。有的設(shè)計師朋友甚至說：

（2）H5算法不同，真的沒辦法特別精確么？

那么H5相較與IOS和安卓真的就這么特殊么？到底是哪里出現(xiàn)了問題呢？

那么接下來我們先來看看目前市面上web app屏幕適配的不同方法。

三、rem在web app中的廣泛應(yīng)用

1. 流式布局

百分比布局，也叫流式布局，因為寬度是百分比，但是高度是按px來寫的?？梢院唵蔚睦斫鉃楦叨裙潭ǎ瑢挾炔还潭?。

使用流式布局的產(chǎn)品在市面上還是較為常見的，我們這里就以亞馬遜為例。如上圖所示750和640的 尺寸下不同模塊的高度都是一致的，且字體大小和圖標尺寸也是相同的。只有橫向間距發(fā)生了變化。我們可以觀察到在750尺寸下頂部亞馬遜的LOGO和登錄按鈕以及購物車，都不處于頁面的上下居中位置，也就是說他們均發(fā)生了偏移。

這是為什么呢？

因為流式布局都是通過百分比來定義寬度的，但是高度往往是固定不變的PX參數(shù)，所以在大屏幕的手機下顯示效果會變成有些頁面元素寬度被拉的很長，但是高度還是和原來一樣，實際顯示非常的不協(xié)調(diào)。有的個別元素還會產(chǎn)生偏移。這就是流式布局的最致命的缺點。

往往只有幾個尺寸的手機下看到的效果是令人滿意的，很多設(shè)計師是無法接受這樣的顯示結(jié)果。

況且流式布局并不是最理想的實現(xiàn)方式，通過大量的百分比布局，會經(jīng)常出現(xiàn)許多兼容性的問題，還有就是對設(shè)計有很多的限制。因為他們在設(shè)計之初就需要考慮流式布局對元素造成的影響，只能設(shè)計橫向拉伸的元素布局，設(shè)計的時候存在不少局限性。

2. 固定寬度的做法

還有一種是固定頁面寬度的做法，早期有些網(wǎng)站把頁面設(shè)置成320的寬度，超出部分留白。我們可以理解為我們在做PC網(wǎng)頁端的時候，采用的是這種固定寬度的方面。這樣做視覺，前端都挺開心，視覺在也不用被流式布局限制自己的設(shè)計靈感了，前端也不用在搞坑爹的流式布局。

但是這種解決方案也是存在一些問題，例如：在大屏幕手機下兩邊是留白的，還有一個就是大屏幕手機下看起來頁面會特別小，操作的按鈕也很小，手機淘寶首頁起初是這么做的，但后來棄用了才方法，采用了rem。

3. 響應(yīng)式設(shè)計

響應(yīng)式設(shè)計在布局的寬度達到某些闕值時，改變其布局結(jié)構(gòu)，適應(yīng)不同終端，當然不僅限于移動端。相信大家對響應(yīng)式設(shè)計并不模式，這里我就不進行過多闡述，可以看下圖這個例子會比較直觀。

響應(yīng)式設(shè)計的優(yōu)點就是能夠適用于多平臺，多種不同的終端。但是在國內(nèi)卻很少有大型企業(yè)的復(fù)雜性的網(wǎng)站在移動端用這種方法去做，其主要原因是工作大，維護性難，所以一般都是中小型的門戶網(wǎng)站或者個人博客會采用此方法。這樣反而可以節(jié)約成本，不用再專門為自己的網(wǎng)站做一個web app的版本。

4. rem能等比例適配所有屏幕

上面講了一大堆目前大部分公司主流的一些web app的適配解決方案，接下來講下rem是如何工作的。

rem（font size of the root element）是指相對于根元素的字體大小的單位。簡單的說它就是一個相對單位，也就是說rem是通過根元素進行適配的。網(wǎng)頁中的根元素指的是，html我們通過設(shè)置html的字體大小就可以控制rem的大小。

舉個例子：

左圖的字體大小為20px,此時的按鈕邊框大小為120px*60px，當我們改變字體大小為40px的時候，那么按鈕邊框的大小則變?yōu)?40px*120px。我們可以看到圖二的寬高比圖一的寬高大了2倍，其實我們只改變了字體的大小。

我們可以看下天貓750尺寸和640尺寸下不同顯示效果，圖三是750等比縮小到640的尺寸，基本上跟640手機上顯示的沒多大差別。那么以此類推不管在任何分辨率下，采用rem的頁面排版都是按照等比例進行切換，并且布局并不會產(chǎn)生錯亂。

5. rem與px之間的換算

那么我們接下來來了解一下rem與px之間是如何換算的。首先瀏覽器默認為16px，如果前端開發(fā)在寫代碼之前沒有設(shè)定一個默認值方便計算的話那么當前默認值就為16px，即1rem=16px。

當然多數(shù)開發(fā)是會把默認值設(shè)定為普遍較為通用的14px的，即1rem=14px

那么此時當字體大小為12px的時候，若設(shè)計稿為320*580即1倍大小，則換算方法為：12/14=0.86rem

如果不能被整除，則小數(shù)點保留到后2位，四舍五入。

6. 百分之80的設(shè)計都被前端忽悠了

那么問題來了當我們知道如何換算之后，如何確定我們的前端開發(fā)采用的默認值是多少呢？

當時開發(fā)在我反復(fù)詢問時說他設(shè)置的默認大小為14px，然后我就建議他按照我給的字體大小通過上述計算方式換算，然而開發(fā)一直說這樣算的話字體還是很大。然后又抱怨說之前的代碼太亂了，自己也不曉得怎么算了。這個時候千萬不要被開發(fā)的話迷惑，而放棄求解。

下一步我們需要要求開發(fā)將某個字的字體大小改為1rem,然后在手機上截圖，再挪到軟件上測量顯示的實際px大小是多少。當時我測量的1rem的字體大小為100px，也就可以斷定我們的前端開發(fā)將默認值設(shè)置為了100px, 即1rem=100px。

有的設(shè)計可能還會遇到這種情況，把設(shè)計稿做成了2倍大小的，那這個時候我們并不需要重新出1倍大小的圖，而是將原有的參數(shù)都除以2進行換算。還是以1rem=100px為例，當字體大小為12px時的換算公式為：12px/2/100=0.06rem。

另外：rem常用于字號和邊距，邊先無需用rem，都統(tǒng)一要求前端改為1px即可。

我們在設(shè)計驗收的時候還需要看下安卓跟IOS的不同顯示效果差異，通常IOS的顯示效果會比安卓顯示的效果好很多，所以這個時候我們還需要重點對安卓手機進行設(shè)計驗收。

掌握了以上換算方式，安卓的驗收就不難了，還需要設(shè)計師們更加耐心。

總結(jié)

我們這里主要針對設(shè)計師在進行H5頁面驗收的時候，存在的種種問題進行了深入剖析。

首先從了解前端實現(xiàn)與設(shè)計稿差異背后的問題入手，到分析目前市面上采用的幾種適配方式，并針對主流的適配方式進行了講解，給出相應(yīng)的應(yīng)對方案幫助設(shè)計師能夠更有效的進行前端驗收工作。

那么其實在實際工作過程中，當我們遇到實現(xiàn)效果不佳的前端開發(fā)，我們要學(xué)會分辨到底哪些是真的不好改，還是其實好多能改，只是他們懶得改就會騙設(shè)計不好實現(xiàn)。

好了嘮叨了這么多希望本文對你有幫助，這些可都是設(shè)計師和前端之間不能說的小九九哦！

參考鏈接：

https://www.cnblogs.com/xiangqianjin/p/6515546.html

http://www.cocoachina.com/webapp/20141224/10746.html

作者：角馬X? ?口袋理財UED設(shè)計經(jīng)理? 公眾號：海鹽社

本文由 @角馬X 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議