摘要：業(yè)務(wù)環(huán)境是決定整體項(xiàng)目的適配方案的核心因素。而淘寶的主站和類似，分為移動端頁面和端頁面，端頁面同樣有著左右的留白，這也是為了讓用戶能夠在寬屏的時候?qū)⒆⒁饬性谥虚g區(qū)域。

移動端適配方案是一個老生常談的話題，但是對于不同的項(xiàng)目、不同的業(yè)務(wù)場景可能會需要不同的適配方案來進(jìn)行移動端適配，向下兼容的baseline也需要提前訂好。

其實(shí)移動端適配就和下面的玩具一樣，對應(yīng)的形狀塞到對應(yīng)的容器里面就好了。但是有點(diǎn)小小的問題，就是這些積木的大小可能和容器不太一樣，對于前端來說，這些積木不是用木頭做的，而應(yīng)該是用橡皮泥做的。

業(yè)務(wù)環(huán)境是決定整體項(xiàng)目的適配方案的核心因素。一套代碼到底需要兼容多少環(huán)境是在項(xiàng)目開始架構(gòu)的時候就需要確定的。

程序員交友網(wǎng)站，github主站可以明顯的看到，所有的內(nèi)容都被限制到了一個980像素的內(nèi)容區(qū)域里面。

而其移動端也也很明顯的是一個多帶帶的布局方式，整體寬度不再限制，即使到了iPad Pro這種寬度到達(dá)1024像素的設(shè)備上，仍然會占滿整個屏幕。

而淘寶的主站和github類似，分為移動端頁面和PC端頁面，PC端頁面同樣有著左右的留白，這也是為了讓用戶能夠在寬屏的時候?qū)⒆⒁饬性谥虚g區(qū)域。

當(dāng)前大部分站點(diǎn)都采用UA來判斷用戶的設(shè)備，然后定向到PC或者H5頁面。

兩者的唯一不同點(diǎn)在于：淘寶會更加嚴(yán)格地將頁面直接重定向到另外一個鏈接，而github則是加載了一個不同的CSS文件進(jìn)行渲染。當(dāng)然，這兩種方案其實(shí)沒有本質(zhì)的差別，而多帶帶的H5頁面可以在客戶端站內(nèi)進(jìn)行更好地復(fù)用。

所以，如果有足夠的開發(fā)人員，開發(fā)適用于兩種設(shè)備類型的頁面是比較友好的方案。如果你的移動客戶端是基于webview開發(fā)的話，那么H5頁面還可以直接嵌入到webview中作為展示。

對于整體寬度，正常移動設(shè)備的寬高比都比較協(xié)調(diào)，而像iPad這種設(shè)備，其寬度過大，導(dǎo)致了正常的H5頁面在上面顯示會有比較奇怪的效果。比如淘寶的主站在iPad上的顯示效果，可以看到上下兩塊的navigator被拉長了很多，導(dǎo)致了效果不好。但是如果考慮到成本問題，iPad用戶更多地會使用APP來進(jìn)行訪問，所以H5頁面的樣式重要性就被縮減了。而github移動版對于寬屏設(shè)備的適配就會做得更好。

有興趣的話，可以去看看淘寶的H5頁面，這個頁面有一個很有趣的地方，這個地方后文會講到，這里先提一下：

除了寬度仍舊占滿屏幕寬度的方案，設(shè)置屏幕的最大寬度可以保證在寬屏設(shè)備上的顯示效果，但是留白的部分就需要考慮處理方案。

由于有了固定最大寬度，僅僅需要對于超過寬度的具有留白的設(shè)備進(jìn)行特殊處理（可以是背景、功能按鈕等），中間具有最大寬度的部分就可以進(jìn)行代碼復(fù)用。

考拉團(tuán)隊(duì)的這篇blog寫的已經(jīng)非常清楚了，感謝考拉的小伙伴給我們提供了便宜的海淘還有這么好的文檔產(chǎn)出lol：

桌面瀏覽器中，正常的視口寬度就是整個瀏覽器的窗口寬度，會隨著瀏覽器窗口的伸縮而縮放。默認(rèn)情況下HTML標(biāo)簽會占滿整個視口，如果沒有設(shè)置HTML的靜態(tài)width的話。

如果采用之前所述的，PC端頁面設(shè)置最大寬度的話，那么當(dāng)視口在最大寬度之外的時候縮放的話，不會影響可見區(qū)域的顯示效果，但是如果縮小到比最大寬度小的時候，原頁面的布局方案就很重要了。彈性布局和百分比的布局方式能夠在頁面縮小的時候，保證頁面的布局不會崩潰。

在手機(jī)上，視口與移動端瀏覽器的寬度不再關(guān)聯(lián)，而是完全獨(dú)立的了。我們稱其為布局視口。

整個頁面可能會變得很大，然后只有一部分顯示在設(shè)備的可見區(qū)域內(nèi)，整個頁面的大小叫做Layout Viewport。這個大小可以通過document.documentElement.clientHeight/clientWidth來獲取。

PPK這篇很早的文章對于視口進(jìn)行了非常清晰的描述。

上圖可見，Layout Viewport的寬高其實(shí)是可變的，當(dāng)通過手勢縮放頁面的時候，Layout Viewport就會發(fā)生變化，當(dāng)頁面縮放到和設(shè)備的可見區(qū)域大小一致的時候，Layout Viewport就剛好等于Visual Viewport了。

Visual Viewport其實(shí)很好理解，就是整個屏幕的可見區(qū)域大小。由于設(shè)備的物理像素，也就是CSS中的pt單位是固定的，頁面在移動端被縮放了之后，頁面中的CSS像素分布在設(shè)備上也發(fā)生了變化。

Ideal Viewport其實(shí)是上面兩者的結(jié)合，當(dāng)我們將Layout Viewport的寬度設(shè)置成屏幕的寬度，就保證了頁面中CSS像素點(diǎn)的恒定。

這里就用到了移動端適配常用的

這個標(biāo)簽可以保證在移動端設(shè)備中，頁面的寬度與屏幕寬度相同。

在手機(jī)上進(jìn)行放大的時候，頁面中的CSS像素不變，但是可見視口的像素比例發(fā)生了變化，但是禁用縮放會導(dǎo)致某些用戶的體驗(yàn)較差。保持縮放比例在一定范圍之內(nèi)比較合適。

基于如上所述的內(nèi)容，結(jié)合目前的業(yè)務(wù)內(nèi)容--主要針對移動端設(shè)備進(jìn)行適配，采用設(shè)置最大寬度，并且在meta標(biāo)簽中設(shè)置理想視口，可以保證在移動設(shè)備以及PC上面的整體布局效果。

目前對于移動端適配的內(nèi)容布局效果是這樣的：

百分比，所有需要動態(tài)調(diào)整的元素寬高采用百分比，字號固定像素。

rem，通過計(jì)算或者JavaScript獲取到設(shè)備像素/CSS像素的比例，確定根元素的字體像素，然后所有單位根據(jù)根元素字體像素進(jìn)行rem設(shè)置，確定大小。而基礎(chǔ)rem會根據(jù)設(shè)備變化而變化。

vw，根據(jù)當(dāng)前設(shè)備的Visual Viewport寬度作為100vw，然后得出單位vw的寬度，所有元素按照vw為單位進(jìn)行樣式排布。

Media Query：通過斷點(diǎn)來進(jìn)行不同寬度區(qū)間的設(shè)備樣式適配。

以上幾個方法各自都有各自的好處，我們可以看一下實(shí)際應(yīng)用時候的效果：

使用百分比作為內(nèi)容大小的標(biāo)準(zhǔn)，在大部分條件下是可行的，百分比可以很好地讓元素乖乖呆在自己的位置，無論屏幕的寬度大小。

但是文字就存在非常大的問題了，由于文字是固定大小，在屏幕dpr變化的時候，文字的CSS像素不變，就導(dǎo)致了文字在頁面中的占位發(fā)生了變化。這樣的結(jié)果就是，文字過多或者屏幕dpr過小的時候，會發(fā)生溢出；但是如果按照小屏幕為基準(zhǔn)，又會發(fā)生字體太小這種情況。

百分比在當(dāng)前移動端適配排版的時候，更多地會作為section級別元素的兼容排版。這個也要和設(shè)計(jì)稿中的效果相關(guān)，如果設(shè)計(jì)稿中要求一個元素定寬，那么就直接用px來保證寬度就可以了。

rem這個單位和之前常用的em有點(diǎn)類似，唯一的區(qū)別在于rem及基于根元素的font-size來進(jìn)行計(jì)算的一個相對值。em存在很多缺點(diǎn)，比如層層嵌套之后，可能就會忘記了上一層的font-size到底是多大?；蛘弑热缦瘳F(xiàn)在的模塊化開發(fā)，一個路由套在另一個路由里面，甚至找父元素都需要到其他文件中去找。

為了解決em存在的問題，標(biāo)準(zhǔn)中還有rem這個單位來幫助排版。所有的元素大小都用rem來作為單位，然后在頁面的根元素中，我們?yōu)楦氐?b>font-size進(jìn)行確定化地賦值，這樣所有的rem單位都是同一個明確的基準(zhǔn)了。當(dāng)屏幕進(jìn)行適配的時候，只需要調(diào)整這個基準(zhǔn)值，就可以保證每個元素的大小自動按照比例調(diào)整。

阿里的lib-flexible解決方案實(shí)際上就是利用了這個方式，通過給標(biāo)簽綁定font-size以及data-dpr屬性來進(jìn)行整個頁面的適配。

方案將整個頁面寬度分成100份，分成100份的原因可以看下面的另一個方案。每10個單位寬度作為1rem，也就是整個視覺稿的寬度會被分成10rem的100份，假如拿到的視覺稿是750px的，那么1rem就代表75px。這樣得到的比例系數(shù)就是75/750，也就是每次在進(jìn)行設(shè)計(jì)稿到CSS的轉(zhuǎn)換的時候，只需要對設(shè)計(jì)稿的像素值/10就可以得到對應(yīng)的rem值。

通過一個預(yù)先加載的JavaScript腳本，計(jì)算根節(jié)點(diǎn)的字體大小，document.documentElement.style.fontSize = window.innerWidth / 10 + "px";，然后我們在寫頁面代碼的時候只需要將原始的像素值/基準(zhǔn)值就可以得到對應(yīng)的rem單位了。當(dāng)然每次都要按計(jì)算器肯定是不行的。如果想方便使用的話，可以用less或者sass這種預(yù)處理器來處理頁面。

@function px2rem($px)
  // 這里將設(shè)計(jì)稿的px轉(zhuǎn)換為rem，
  @return ($px / $unit-px) * 1rem
// 根據(jù)設(shè)備的dpr進(jìn)行字體適配
@mixin font-dpr($font-size) 
    font-size: $font-size
    [data-dpr="2"] &
        font-size: $font-size * 2

除了元素寬高可以得到比較好的還原，對于文字大小的適配也比較重要，由于每個設(shè)備的dpr不同（這里尤其是iOS設(shè)備），直接導(dǎo)致了很多文字在iPhone6+上顯示正常，而在iPhone5上面卻文字過大，導(dǎo)致文字溢出，上面的less mixin就是進(jìn)行字體樣式適配的。

這種方法結(jié)合了sass的函數(shù)功能和rem的適配，再加上必要的百分比以及media query可以得到比較好的移動表現(xiàn)。

這是使用這種方法在iphone6上的顯示效果，具體的整體顯示效果可以戳這里，rem基準(zhǔn)樣式示例

如果對于文字在各種平臺上的顯示效果不滿意，可以通過上面說的sass的mixin來讓文字根據(jù)dpr進(jìn)行斷點(diǎn)渲染。

而這樣存在的問題就是僅僅適用于移動端，并且不能夠進(jìn)行橫屏適配，因?yàn)闄M屏之后，頁面的寬度發(fā)生了變化，但是基準(zhǔn)值卻還保持著原本綁定到根節(jié)點(diǎn)上面的基準(zhǔn)值。

首先看看vw的瀏覽器支持情況吧，can i use vw支持情況，使用這個單位意味著你放棄了IE11以下的PC用戶，在現(xiàn)在一個主要兼容移動端的世界里，并沒有太大的副作用（這里吐槽一句，其實(shí)PC端的兼容遠(yuǎn)遠(yuǎn)要比移動端來的方便。移動端奇奇怪怪的分辨率以及2x，3x的屏幕，還有苦逼的ipad、橫屏讓我每次做兼容的時候想一躍解千愁）。

vw自身將整個可見視口橫向分成了100份，每一個單位就是1vw，這個單位最大的優(yōu)勢就是在移動端的時候，無論是豎屏或者橫屏，vw永遠(yuǎn)都是針對于橫向的，比rem的方案好在當(dāng)屏幕大小發(fā)生變化（順便兼容了以后的可調(diào)節(jié)屏幕大小的移動設(shè)備[手動斜眼]）的時候，不會讓頁面崩掉。

對于移動設(shè)備來說，比如iphone6+的375pxCSS像素寬度，1vw就等于3.75px，通過這個單位可以解決上面的依賴于腳本綁定根元素font-size的問題，在豎屏和橫屏下面都有比較好的效果。

在通過vw解耦了CSS和JS之后，那么vw是否可以獨(dú)立解決所有問題呢？

// 首先，我司的設(shè)計(jì)稿目前都是以750px為寬度，實(shí)際為iPhone6+的375px為基準(zhǔn)
$w-base: 375px
$w-base-design: 750px
@function px2vw($px)
    @return ($px / $w-base-design) * 100vw

首先，上面的sass代碼可以根據(jù)你設(shè)計(jì)稿上面的px單位轉(zhuǎn)換為vw單位值。當(dāng)然最簡單的辦法還是直接按照視覺稿上面像素進(jìn)行輸入，然后直接輸出對應(yīng)的vw值啦。vscode和sublime當(dāng)然會有已經(jīng)做好的插件，但是個人并不是很喜歡這種方式，這樣你就沒辦法得到這個視覺稿原本的像素值了。在后期進(jìn)行維護(hù)的時候會增加很多很多很多麻煩。這就是寫起來爽，改起來火葬場吧。。。vw的效果可以看下面的codepen。

vw實(shí)現(xiàn)的同樣適配頁面

目前來說，vw是肯定不適合多帶帶使用的，畢竟頁面中還是有很多元素需要絕對的大小定位的。px永遠(yuǎn)是必不可少的，視覺不可能讓你所有的東西都自適應(yīng)。

那么vw能夠解決什么問題呢？首先是大部分取代%在CSS中的使用，百分比在CSS中存在很多歧義，對于寬度，上下邊距，左右邊距，內(nèi)外邊距的處理方式不盡相同。即使是老練的前端有時候也得思考一下當(dāng)前的百分比到底是根據(jù)什么確定的。而vw則是一個絕對的數(shù)值，僅僅根據(jù)一個不太可能變化的屏幕寬度來確定。

而百分比主要解決的彈性問題，就是vw著力解決的問題。

vw不能夠兼顧所有的情況，所以這個單位目前還并不是最終的解決方案，還是需要和其他單位合作來幫助頁面能夠更加優(yōu)雅地顯示出來。

雖然根據(jù)實(shí)現(xiàn)出來的效果，幾種方法可能沒有什么太大的效果差別，但是最大的問題在于，需要實(shí)現(xiàn)這種效果需要多么復(fù)雜的代碼呢。

CSS的兼容性不在于解釋器上，而是在于設(shè)備的屏幕上面。大部分時間不僅需要將頁面展示在用戶的面前，而是需要將頁面穩(wěn)定且優(yōu)雅地展示給用戶。

無論是百分比，rem還是vw，都是進(jìn)行局部容器元素定位的，作為最底層的葉子元素或者單元元素來說，更多時間還是會使用px來盡量還原視覺稿。

長遠(yuǎn)考慮這個問題，vw在僅進(jìn)行移動端訪問的情況下效果拔群，因?yàn)椴豢紤]兼容，只需要考慮適配問題。工程中到底使用哪個方法進(jìn)行，取決于大部分業(yè)務(wù)需要兼容的環(huán)境。