當你陪著家人嗑著瓜子，和家人一起看著春晚，順便拿著手淘參與春晚抽獎互動的時候，杭州還有兩百多程序員還奮戰(zhàn)在一線當中?，F在年也過完了，獎也抽了，紅包也拿了。也該好好回來工作的時候了。這次很榮幸，自己能參與手淘過年項目（紅包開光和春晚互動項目）的項目中，雖然僅僅參與其中的部分工作，但事后感覺有些東西還是應該總結總結的，為之后的項目做準備。那么簡單的來總結一下，我自己在參與項目中用到的一些前端技術。

這些技術其實也并不是什么鮮為人知的技術棧，因為這些技術點已經出現很久了，只不過大家習慣了自己的開發(fā)模式，加上項目時間緊，怕嘗試新的東西。事實上我自己也是如此，害怕使用這些技術點，給項目帶來其他的風險（本來項目時間就很緊），慶幸的是，接下來了到的一些東西，經住了項目的考驗，雖然當中踩過一些坑，但總算是無驚無險。

過年項目

手淘過年項目，事實上分為兩個，其中一個叫紅包開光，另一個是春晚抽獎的互動項目。

上面兩張圖分別是紅包開光和春晚互動的主界面視覺圖。如果你參與過手淘過年互動的活動中，這兩個界面應該對您來說并不會太陌生。

經過團隊同學一起討論，這次兩個項目都基于Vue來開發(fā)，Vue只是一個JavaScript庫而以，選擇他并不沒有太多的主要原因，而是想讓團隊在今后的項目開發(fā)的時候，JavaScript庫能趨于統(tǒng)一，從而慢慢在項目中有所沉淀與積累?；谶@個原因，我在其中主要做的事情，在這個腳手架中（也就是Vue-cli的基礎）添加了以下三個部分：

• PostCSS插件
• vw適配方案
• iPhone X 適配

PostCSS插件

在互動腳手架中，目前已配置的PostCSS插件主要有：

• postcss-import
• postcss-url
• postcss-aspect-ratio-mini
• postcss-cssnext
• autoprefixer
• postcss-px-to-viewport
• postcss-write-svg
• cssnano
• postcss-viewport-units

PostCSS插件的配置

Webpack項目的.postcssrc.js最終的PostCSS插件的配置:

對于這些PostCSS插件所起的作用和怎么配置，在其對應的GitHub上都有詳細的描述。這里簡要的描述一下，為什么在我們的項目中會采用這些PostCSS的插件：

postcss-import和postcss-url兩個主要是用于處理引入的文件和資源路徑的處理以及工作模式。如果你的項目也使用的是Vue，并且配置了vue-loader，并且配置了相關的參數，那就就具有類似的功能。

autoprefixer主要用來處理瀏覽器的私有前綴，這個已經是大家經常使用的一個PostCSS插件了。這里需要提出的是，如果你的項目中使用了postcss-next和cssnano，那么autoprefixer插件可以不引入，而且在postcss-next和cssnano兩者中選擇其一關閉autoprefixer，因為這兩個插件都集成了autoprefixer插件的特性。

postcss-cssnext其實就是cssnext。該插件可以讓我們使用CSS未來的特性，其會對這些特性做相關的兼容性處理。其包含的特性主要有：

有關于cssnext的每個特性的操作文檔，可以點擊這里瀏覽。

cssnano主要用來壓縮和清理CSS代碼。在Webpack中，cssnano和css-loader捆綁在一起，所以不需要自己加載它。不過你也可以使用postcss-loader顯式的使用cssnano。有關于cssnano的詳細文檔，可以點擊這里獲取。

注：由于cssnano的preset配置使用的是advanced，所以需要安裝npm install cssnano-preset-advanced --save-dev。另外cssnext和cssnano都具有autoprefixer的插件，因此在cssnano中將autoprefixer設置為false。

postcss-write-svg插件主要用來處理移動端1px的解決方案。該插件主要使用的是border-image和background配合SVG繪制的矢量圖來做1px的相關處理。后續(xù)將會專門花一節(jié)的內容來介紹postcss-write-svg或者說怎么能更好的使用SVG來處理移動端1px。

postcss-aspect-ratio-mini主要用來處理元素容器寬高比。在項目當中很多地方會使用img、object或者video，那么這個插件能更好的幫助我們完美處理寬高比的縮放。在實際使用的時候，具有一個默認的結構：

在實際使用的時候，你可以把自定義屬性aspectratio和aspectratio-content換成相應的類名，比如：

我個人比較喜歡用自定義屬性，它和類名所起的作用是同等的。結構定義之后，需要在你的樣式文件中添加一個統(tǒng)一的寬度比默認屬性：

如果我們想要做一個188:246（188是容器寬度，246是容器高度）這樣的比例容器，只需要這樣使用：

有一點需要特別注意：aspect-ratio屬性不能和其他屬性寫在一起，否則編譯出來的屬性只會留下aspect-ratio的值，比如：

編譯前的CSS如下：

編譯之后：

主要是因為在插件中做了相應的處理，不在每次調用aspect-ratio時，生成前面指定的默認樣式代碼，這樣代碼沒那么冗余。所以在使用的時候，需要把width和background-color分開來寫：

這個時候，編譯出來的CSS就正常了：

這個現象也算是一個天坑吧。而這個坑是該插件自己帶來的，上面的處理方式只是治標而不能治本。所以在使用該插件的時候，需要特別注意這個細節(jié)。

目前采用PostCSS插件只是一個過渡階段，在將來我們可以直接在CSS中使用aspect-ratio屬性來實現長寬比。當然，如果你對cssnext熟悉的話，可以給其添加這樣的一個PR,將CSS原生的aspect-ratio屬性添加到cssnext特性當中，這樣只要你使用postcss-next就可以忽略這個插件了。

剩下的postcss-px-to-viewport和postcss-viewport-units兩個PostCSS插件主要是用于vw適配方案，算是這次項目中必不可少的PostCSS插件。其中，postcss-px-to-viewport插件主要用來把px單位轉換為vw、vh、vmin或者vmax這樣的視窗單位，也是vw適配方案的核心插件之一。

在配置中需要配置相關的幾個關鍵參數：

目前出視覺設計稿，我們都是使用750px寬度的，那么100vw = 750px，即1vw = 7.5px。那么我們可以根據設計圖上的px值直接轉換成對應的vw值。在實際擼碼過程，不需要進行任何的計算，直接在代碼中寫px，比如：

編譯出來的CSS：

在不想要把px轉換為vw的時候，首先在對應的元素（html）中添加配置中指定的類名ignore或hairlines(hairlines一般用于設置border-width:0.5px的元素中)：

寫CSS的時候：

編譯出來的CSS:

上面解決了px到vw的轉換計算。

由于瀏覽器對vw還具有一定的兼容性，其在Android 4.4之下和iOS8以下的版本都存有一定的問題。為了讓vw、vh、vmin和vmax這些viewport單位能更好的使用。其兼容方案就是使用viewport的polyfill：Viewport Units Buggyfill。

而在采用Viewport Units Buggyfill的時候，需要手動給使用viewport單位的樣式中添加其對應的Hack代碼，比如：

如果每一個都這樣來做，那么將是災難性的。幸運的是，可以使用postcss-viewport-units。其主要是給CSS的屬性添加content的屬性，配合viewport-units-buggyfill庫給vw、vh、vmin和vmax做適配的操作。

另一個坑，使用postcss-viewport-units將會給具有content屬性的元素造成一定的影響，比如你的項目中使用偽元素::before、::after或者偽類:before、:after之類。那么使用該插件，會自動替換你原來的content內容，為了避免該現象，需要在content的屬性值末尾添加!important。

上面這些PostCSS插件是在這次項目中使用的，也將會在后面的項目中繼續(xù)使用，使用其主要原因是幫助我們解放雙手能更好的擼?；蛟S你對其中一些插件有更好的使用心得，歡迎和我們一起分享，如果你有更好的插件，能幫助我們解放雙手，也歡迎分享給我們。

vw適配方案

vw適配方案，主要是用于解決移動端布局的問題。事實上，在手淘，甚至到目前為止都還在使用Flexible的布局方案，用于適配移動端的各種終端。在15年雙11之后，寫了一篇《使用Flexible實現手淘H5頁面的終端適配》博文，將此方案分享給業(yè)內，而且該方案在業(yè)內快速的被復用和修改（原理是一樣的）。

Flexible的適合方案，在那個時期是非常強大的，想出這個方案的大神讓我膜拜已久。當然，事物是兩極的，他非常強大，但他也有自己的不足之處，特別是在vw得到更多的支持的時候，我覺得Flexible應該退出其歷史的使用（這是我自己YY的）。所以在17年年初我開始在探討vw在移動端中的使用，經過一段時間的探討和嘗試，我寫下了《再聊移動端頁面的適配》一文。

使用vw可以看到測試用例得到了眾多設備的支持：

大家看到眾多，或許會生疑，那么還有不支持的將會是怎么？特別是老板跟我說，這次過年項目咱們使用vw來做適配布局吧。其實聽到這個消息，我自己是非常高興的，畢竟學習過的技術方案有較大的項目來驗證。心里是美的，但也略感壓力，就害怕又會折騰出新的妖蛾子。想想都怕怕（^_^）。

眾所周知，瀏覽器對vw 還具有一定的兼容性，其在Android 4.4之下和iOS8以下的版本都存有一定的問題。為了讓vw、vh、vmin和vmax這些viewport單位能更好的使用。需要考慮viewport單位在不支持的瀏覽器（或設備）做相應的處理。

為了能讓項目更安全，在決定過年項目中采用vw布局方案的時候，我就又再一次做了一個技術驗證，這次是基于Vue的Vue-cli腳手架的上來做的，畢竟我們的項目也要有Vue嘛。在這個腳手加上，我將上面介紹的PostCSS插件配置進去，特別是postcss-px-to-viewport和postcss-viewport-units兩個PostCSS插件和Viewport Units Buggyfill讓我完美的解決了vw兼容問題。而且讓開發(fā)者無感知。他們不需要考慮怎么處理兼容，只需要按著設計稿前行。

當然，完成這個技術方案的驗證，其中還是碰到一些坑的，幸好能像打老怪一樣，一個一個Fix。這里就不闡述整個過程，如果你感興趣可以閱讀《如何在Vue項目中使用vw實現移動端適配》一文。接下來簡單的介紹一下vw兼容方案處理方式。

vw兼容方案

移動端使用vw布局，其兼容方案就是使用viewport的polyfill：Viewport Units Buggyfill。使用viewport-units-buggyfill主要分以下幾步走：

引入JavaScript文件

在你的HTML文件，比如index.html中的</head>或</body>

引入下面的JavaScript文件：

調用viewport-units-buggyfill的方法

同樣在HTML文件中調用viewport-units-buggyfill的方法，比如：

Flexible項目無縫過渡到vw

在前面發(fā)布的博客當中，有同學提到一個問題，如何能快速的將使用Flexible布局的項目無縫過渡到vw布局，剛好借這次項目的機會做了一個小測試。實現這個也并不復雜。簡單的描述一下其過程：

第一步

將Flexible項目中的flexible.js和flexible.css刪除，并使用下面的vw的兼容腳本：

第二步

在<head>標簽添加meta標簽：

為了兼容iPhone X的適配，在meta標簽中添加了viewport-fit="cover"參數處理。有關于這方面的可以閱讀《iPhone X的缺口和CSS》和《iPhone X的Web設計》。

第三步

添加前面提到的PostCSS插件的配置，當然，你可以只添加處理px轉vw和vw配合Viewport Units Buggyfill的兩個PostCSS插件：postcss-px-to-viewport和postcss-viewport-units。

PostCSS插件配置有一個強大之處，不管你使用的是什么腳手架，他的配置都非常的靈活，支持流行的配置工具，比如Webpack,gulp等。所以你不用擔心不好配置。因為在使用Flexible時，也需要px2rem的PostCSS插件配置。

第四步

重新編譯你的代碼，并在瀏覽器中驗證一下編譯后的頁面。為什么要這么做呢？主要是因為postcss-px-to-viewport和postcss-viewport-units兩個插件會對::before(:before)、::after(:after)、img中的content做覆蓋。如果你的項目中有使用到具有content屬性的元素，需要做一定的清理工作。目前這部分沒有較好的方式，我也咨詢過這兩個插件的作者，他們反饋也沒找到更好的方案，只能人肉處理，或者變相不使用::before和::after這樣的東東，添加額外的元素標簽來替代。如果你嘗試之后，發(fā)現有更好的方案，歡迎把你的方案分享給我們。

iPhone X 適配

自從蘋果出了iPhone X的設備，對于前端開發(fā)的同學而言，避免不了對其適配處理。而且這部分適配的處理相對而言是較為繁鎖的。我也一直在探尋從設計開始就能規(guī)避一些常規(guī)的適配問題。這部分內容正在整理，當其成熟之后再與大家分享。下面簡單的羅列一下自己對iPhone X適配的處理思路。

蘋果對于iPhone X上H5頁面的適配，提供了特殊屬性支持，包括meta標簽的viewport屬性值中加入viewport-fit和加入constant(safe-area-inset-*)和env(safe-area-inset-*) ，這些屬性是與iOS11以上的所有iPhone機型（不僅僅包括iPhone X）都相關的，故以iOS版本為區(qū)別具體分析一下全屏下的H5頁面：

• 針對iOS11.0以下系統(tǒng)：將不識別H5頁面meta標簽下的viewport-fit及constant(safe-area-inset-*)／env(safe-area-inset-*)屬性。
• 針對于iOS11.0-iOS11.1的系統(tǒng)：當設置了viewport-fit="cover"，H5頁面會覆蓋頁面安全區(qū)域全屏展示，但是這樣會帶來頁面元素會被“劉海兒”和底部Home Indicator遮擋問題，所以蘋果提供在CSS中設置constant(safe-area-inset-*)距離來規(guī)避遮擋問題。另外，頁面不加viewport-fit="cover"默認viewport-fit="contain/auto"，也就是我們看到的頁面不能覆蓋安全區(qū)域的情況，此時constant(safe-area-inset-*)的值都為0。所以在meta標簽的viewpoint中加viewport-fit="cover"時iOS10和iOS11下constant(safe-area-inset-*)值的表現是不一樣的。
• 針對iOS11.2及iOS11.2以上的系統(tǒng)：constant()改成了env()。另外，iOS11.2新增了CSS function: min()和max()。例如：padding-left: max(12px, env(safe-area-inset-left));。在env(safe-area-inset-left)值因為Webview變化時值也可以做出相應變化，取12px和env(safe-area-inset-left)的較大值。

總結如下圖：

通過媒體查詢針對 iPhone X采用個性化樣式處理：

總結

最后感謝您花時間把這篇文章閱讀完。上面介紹的內容就是我自己在手淘過年項目中采用到的部分前端技術，稍作整理與大家分享。如果其中有不對之處，煩請路過的大嬸斧正。如果您在自己的項目中將采用上述提到的一些技術方案，踩到任何坑也歡迎一起探討。