淘寶彈性布局方案lib-flexible研究

1. lib-flexible不能與響應式布局兼容

先說說響應式布局的一些基本認識：

響應式布局的表現是：網頁通過css媒介查詢判斷可視區域的寬度，在不同的范圍應用不同的樣式，以便在不同尺寸的設備上呈現最佳的界面效果。典型的例子是，有一個商品列表頁，應用響應式布局后，可能在pc上是用4列展示，在平板上用3列展示，在手機上只用1列展示。這種布局的最大好處就是節省人力、資源和時間，所以很多公司都喜歡用。而響應式布局有兩個必須的要求：

1）是viewport的設置，width跟initial-scale要采用如下配置，保證viewport的寬度與device width相同：

2）是要利用media query，針對不同的width范圍，編寫不同的css，比如bootstrap：

需要注意的是：第（1）個要求提到的device width與media query里面的device-width屬性表達的意思有些區別：第（1）個要求提到的device width在移動設備下指的是設備的寬度，但是在pc下指的是瀏覽器可視區域的寬度，比如下面這個網頁，我把瀏覽器窗口縮小，然后你看它viewport里盡管已經把width設置成了device-width，但是網頁大小卻不是我的桌面的分辨率寬度（設備寬度）：

media query里的device-width屬性，始終指的是設備的寬度。所以響應式布局的媒介查詢要用width屬性，不用device-width屬性，因為在桌面設備下，把瀏覽器窗口縮小的時候，device-width并不會發生改變，當調整瀏覽器窗口大小就看不到響應式的效果。

再來看lib-flexible的特點：

lib-flexible在適配的時候會修改viewport的initial-scale，導致viewport的width不等于device width。這是采用lib-flexible，在iphone6 plus下適配后，自動添加的viewport設置代碼：

在這個viewport的作用下，網頁的縮放系數為0.3333333333333333，iphone6 plus的device width為414個不縮放的css像素，經過縮放之后，viewport的width等于device width / 0.3333333333333333，為1242個縮放后的css像素，遠遠大于device width：

假如你的網頁想同時使用響應式布局和lib-flexible，然后你寫了一個媒介查詢，需要在1024px以上的分辨率（桌面設備）呈現某個特殊樣式（代碼僅僅是為了舉例）：

會發現這個頁面在iphone6 plus下也會應用到該媒介查詢的樣式：

究其原因是：iphone6 plus下的網頁由于lib-flexible的作用，導致頁面的width與實際物理分辨率的寬相等，也就是1242個像素，完全達到了該媒介查詢的范圍。

所以，在使用lib-flexible的項目里很難再實現響應式布局，要是有人有這種綜合兩者一起使用的想法，可得注意了。實際上，這兩個方案本質性的東西就不相同，適用的場景也不相同。響應式布局的目的是一套代碼，能夠在手機平板和pc上都能良好展現，適用于網站類的項目，而lib-flexible解決的是手機端網頁的適配問題，壓根不管平板和pc的情況，適用于web app類的項目。

2. 1px邊框在lib-flexible下如何處理

web app有時候會設計出一些特別細的線條或者邊框，如果我們直接通過css設置邊框為1px：

結果會發現這種邊框在手機里看起來的效果，顯得特別地粗，之所以會有這個效果，原因很簡單，因為現在大部分手機的分辨率很高，一個css像素，比如上面代碼中的1px，可能相當于2個甚至3個物理分辨率像素，而不像pc，一個css像素始終等于1個物理分辨率像素，所以手機里看到的1px會比實際的粗。

為了解決這個問題，你可能會想到用0.5px來代替1px，不過這個是解決不了問題的，而且帶小數的像素在不同的瀏覽器下絕對是一個坑，千萬要盡量避免。

那么通常在web app下顯示1px的做法是怎樣的呢，前陣子在weui的源碼中看到了一個很好的辦法，值得分享：

這個辦法并不是利用border屬性來顯示邊框，而是利用了偽類和transform，最妙的是這個transform，0.5px辦不到的事情，它卻辦得到。

由于lib-flexible在適配的時候，會縮放網頁，導致css代碼中的1px等于物理分辨率的1px，這樣子這個1px邊框的問題在經過lib-flexible適配的設備下就很好解決了，直接應用border: 1px solid；即可。但是lib-flexible現在只適配了iphone設備，安卓設備壓根沒適配：

導致在安卓設備下，1px的邊框問題依然存在。所以為了在lib-flexible的項目里解決1px的問題，就得綜合兩種做法了：

這個做法，我做過測試，在我devicePixelRatio為3的meilan note上，顯示出的線條非常細膩，看起來很舒服，iphone的效果也不錯，借別人的機子測試過，所以有興趣的人可以借鑒使用，有問題盡管提出，看看能不能有更好的辦法解決。這是我用魅藍note做測試的截圖：

第1根線是上面的mixin效果；第二根線是直接使用border: 1px solid的效果。

注：以上提到的這個1px邊框的做法有三個缺點，在使用的時候需要注意：

1）它會占用掉before偽類

2）沒法做圓角

3）很難實現多條邊框，除非嵌套，或者再利用上after偽類。

盡管如此，以上這個做法還是非常有用的做法，因為這種細線邊框屬于比較特殊的設計要求，并不是每處邊框都得做成這樣，在開發webapp的時候用這個方法保證特殊線條的設計要求，其它的邊線，我覺得直接用border并沒有關系，你可以直接用你的手機打開bootstrap的官方頁面，看它里面的按鈕邊框，效果都還不錯。

3. lib-flexible如何處理retina屏下的background-image

幾年之前，retina屏，也就是所謂的高清屏，還不像現在這么普遍，12年我買的第一個安卓機是華為u8825d，分辨率只有480*800，而且當時市面上大部分安卓機基本上都是這個分辨率，像iphone4 那種640*960級別的機子很少，為了解決普通背景圖片在iphone4下顯示模糊的問題，基本都是采用這種做法：

估計當時應該是320的設計稿，img_1x.png是在320設計稿下切出的圖，然后img_2x.png是在320設計稿矢量放大2倍后切出的圖，高清屏顯示img_2x.png，這樣就能解決當時iphone4背景圖片模糊的問題。

時至今日，手機都是走高配置，低價格的發展路線，480*800這種級別的機子，市面上越來越少，大部分手機的分辨率級別都達到了iphone4的標準，比iphone4的清晰級別更高的手機也越來越多，一個800塊的魅藍note，它的devicePixelRatio都已經達到了3，原先解決background-image問題的方法，需要調整一下才能適用于現在：

代碼中的2x和3x是相當于320的設計稿而言的，2x代替了原先的1x，3x代替了原先的2x。現在的設計稿也不再是320，而是640，2x就是在640下切出的圖，3x是在640基礎上矢量放大1.5切出的圖。在這個代碼的作用下，分辨率在640以下的設備都會顯示2x的圖，由于2x的圖本身是在640的設計稿切出的，所以這些設備下不會有模糊的現象，在640以上的分辨率，會顯示3x的圖，由于3x的圖是在960的分辨率下切出的，所以這種圖在分辨率小于960的設備下都不會模糊。以前1x的情況根本不用再考慮了，以后不會再有需要1x圖的設備，說不定過幾年，市面上的手機全是devicePixelRatio在2.5以上的標準時，連2x的情況也不用考慮了。

lib-flexible在iphone6推出之后，把設計稿的尺寸提高到了750，切圖時還是按2x和3x的方法來切，這樣的話，經過lib-flexible適配的設備，分辨率在750以下都會顯示2x的圖，肯定不會模糊；分辨率在750以上的設備，會顯示3x的圖，也不會出現模糊。不過由于lib-flexible只適配了iphone的問題，所以我上篇博客中提到的用data-dpr來顯示不同的圖片的做法是錯誤的，因為有些安卓機，比如我的魅族node，devicePixelRatio是3，打開app頁面，看到的圖片卻仍然還是2x的，顯然達不到適配的要求，所以不能用data-dpr去適配，而應該采用下面這個做法：

這個代碼的最終效果是：

1）devicePixelRatio大于等于2.5的設備都會應用到3x圖

2）其它設備都會應用到2x的圖。

這個方法，在chrome的模擬器里測試過很多機型，效果不錯，不過它只適用于不使用雪碧圖的背景圖片，如果要在lib-flexible的項目里使用雪碧圖作背景圖片，同時又要考慮retina屏的話，需要將上面這個方法稍微改動一下。

首先看下不使用lib-flexible時，雪碧圖背景在retina下是怎么做的，以騰訊的一個活動頁面來說明http://qzs.qq.com/qzone/qzact/act/qzapp/qzone5.0/mobile/index.html，這是它在使用1x的雪碧圖時某個元素的background的樣式：

這是它在使用2x的雪碧圖時某個元素的background的樣式：

總結下它這個做法：

1）先把設計稿切出的圖，合并成一張雪碧圖，騰訊這個例子的設計稿是320的，所以它的切圖都是1x的，這張雪碧圖也就是1x的，大小為643 * 152

2）設計稿放大2倍，切圖合并成一張2x的雪碧圖，大小為1286 * 304

3）普清屏下只應用background-image和background-position屬性，設置1x雪碧圖作為背景，代碼參考截圖

4）高清屏下除了應用background-image和background-position屬性，還要應用background-size屬性，并且這個background-size的大小要設置為1x雪碧圖的大小，background-position的值要與（3）里配置的值相同，代碼參考截圖。

如果把它做成一個mixin的話應該是類似這樣的：

考慮到1x不會再有的情況，上面這個mixin可以再調整一下：

默認用2x的圖，devicePixelRatio大于等于2.5的設備用3x的圖。這個調整后的mixin就是lib-flexible下，使用雪碧圖背景的方法，應用舉例：

sprite.png用750設計稿的切圖合并后的大小是414 * 232，.btn-android這個按鈕的position為0 –64px。

盡管這個方法看起來完美，但是不建議使用，因為它的適配效果不好，這是iphone6下的效果：

看起來不錯，那是當然的，因為這就是它默認沒有任何縮放的效果。然后看iphone6 plus的效果：

有點差異，但好像還能接受。再看看nexus6的效果：

這就不能忍了，樣式差的離譜。造成這個差異的原因也很簡單，就是rem的副作用，騰訊的頁面里所有position,size都是不帶小數的數值，而且2x跟1x之間是整數的翻倍，而不是3x跟2x之間的1.5倍，lib-flexible會導致大部分的設備下position和size都是小數數值，所以很難保證背景圖片縮放后還能通過position顯示到正確的位置：

從網頁優化的角度來說，減少請求數，減少請求數據大小是兩個基本的思路，雪碧圖就是一個減少請求數但是不能減少請求數據量的方法。lib-flexible不能使用兼容3x屏的雪碧圖的情況看起來是它一個大的缺陷，但實際上也并非如此：雪碧圖如果用不了，就采用別的思路來優化，我能想到的更好的就是圖片的延遲加載和懶加載，在app頁面里控制好默認只加載首屏的圖片，并且采用延遲和懶加載的方式，避免阻塞頁面的加載，也能有極好的用戶體驗，打開手機淘寶的頁面給人的感覺就是如此，而且你去看看手機淘寶的應用會發現它根本就沒有用雪碧圖，但是速度還是很快。