摘要：業務環境是決定整體項目的適配方案的核心因素。而淘寶的主站和類似，分為移動端頁面和端頁面，端頁面同樣有著左右的留白，這也是為了讓用戶能夠在寬屏的時候將注意力集中在中間區域。

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

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

業務環境是決定整體項目的適配方案的核心因素。一套代碼到底需要兼容多少環境是在項目開始架構的時候就需要確定的。

程序員交友網站，github主站可以明顯的看到，所有的內容都被限制到了一個980像素的內容區域里面。

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

而淘寶的主站和github類似，分為移動端頁面和PC端頁面，PC端頁面同樣有著左右的留白，這也是為了讓用戶能夠在寬屏的時候將注意力集中在中間區域。

當前大部分站點都采用UA來判斷用戶的設備，然后定向到PC或者H5頁面。

兩者的唯一不同點在于：淘寶會更加嚴格地將頁面直接重定向到另外一個鏈接，而github則是加載了一個不同的CSS文件進行渲染。當然，這兩種方案其實沒有本質的差別，而多帶帶的H5頁面可以在客戶端站內進行更好地復用。

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

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

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

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

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

考拉團隊的這篇blog寫的已經非常清楚了，感謝考拉的小伙伴給我們提供了便宜的海淘還有這么好的文檔產出lol：

桌面瀏覽器中，正常的視口寬度就是整個瀏覽器的窗口寬度，會隨著瀏覽器窗口的伸縮而縮放。默認情況下HTML標簽會占滿整個視口，如果沒有設置HTML的靜態width的話。

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

在手機上，視口與移動端瀏覽器的寬度不再關聯，而是完全獨立的了。我們稱其為布局視口。

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

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

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

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

Ideal Viewport其實是上面兩者的結合，當我們將Layout Viewport的寬度設置成屏幕的寬度，就保證了頁面中CSS像素點的恒定。

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

這個標簽可以保證在移動端設備中，頁面的寬度與屏幕寬度相同。

在手機上進行放大的時候，頁面中的CSS像素不變，但是可見視口的像素比例發生了變化，但是禁用縮放會導致某些用戶的體驗較差。保持縮放比例在一定范圍之內比較合適。

基于如上所述的內容，結合目前的業務內容--主要針對移動端設備進行適配，采用設置最大寬度，并且在meta標簽中設置理想視口，可以保證在移動設備以及PC上面的整體布局效果。

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

百分比，所有需要動態調整的元素寬高采用百分比，字號固定像素。

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

vw，根據當前設備的Visual Viewport寬度作為100vw，然后得出單位vw的寬度，所有元素按照vw為單位進行樣式排布。

Media Query：通過斷點來進行不同寬度區間的設備樣式適配。

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

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

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

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

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

為了解決em存在的問題，標準中還有rem這個單位來幫助排版。所有的元素大小都用rem來作為單位，然后在頁面的根元素中，我們為根元素的font-size進行確定化地賦值，這樣所有的rem單位都是同一個明確的基準了。當屏幕進行適配的時候，只需要調整這個基準值，就可以保證每個元素的大小自動按照比例調整。

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

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

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

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

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

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

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

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

而這樣存在的問題就是僅僅適用于移動端，并且不能夠進行橫屏適配，因為橫屏之后，頁面的寬度發生了變化，但是基準值卻還保持著原本綁定到根節點上面的基準值。

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

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

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

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

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

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

vw實現的同樣適配頁面

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

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

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

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

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

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

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

長遠考慮這個問題，vw在僅進行移動端訪問的情況下效果拔群，因為不考慮兼容，只需要考慮適配問題。工程中到底使用哪個方法進行，取決于大部分業務需要兼容的環境。