淘宝弹性布局方案lib-flexible研究

1. lib-flexible不能与响应式布局兼容

先说说响应式布局的一些基本认识：

响应式布局的表现是：网页经过css媒介查询判断可视区域的宽度，在不一样的范围应用不一样的样式，以便在不一样尺寸的设备上呈现最佳的界面效果。典型的例子是，有一个商品列表页，应用响应式布局后，可能在pc上是用4列展现，在平板上用3列展现，在手机上只用1列展现。这种布局的最大好处就是节省人力、资源和时间，因此不少公司都喜欢用。而响应式布局有两个必须的要求：

1）是viewport的设置，width跟initial-scale要采用以下配置，保证viewport的宽度与device width相同：

+ View code

 

2）是要利用media query，针对不一样的width范围，编写不一样的css，好比bootstrap：

+ View code

 

须要注意的是：第（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设置代码：

+ View code

 

在这个viewport的做用下，网页的缩放系数为0.3333333333333333，iphone6 plus的device width为414个不缩放的css像素，通过缩放以后，viewport的width等于device width / 0.3333333333333333，为1242个缩放后的css像素，远远大于device width：

假如你的网页想同时使用响应式布局和lib-flexible，而后你写了一个媒介查询，须要在1024px以上的分辨率（桌面设备）呈现某个特殊样式（代码仅仅是为了举例）：

+ View code

 

会发现这个页面在iphone6 plus下也会应用到该媒介查询的样式：

究其缘由是：iphone6 plus下的网页因为lib-flexible的做用，致使页面的width与实际物理分辨率的宽相等，也就是1242个像素，彻底达到了该媒介查询的范围。

因此，在使用lib-flexible的项目里很难再实现响应式布局，要是有人有这种综合二者一块儿使用的想法，可得注意了。实际上，这两个方案本质性的东西就不相同，适用的场景也不相同。响应式布局的目的是一套代码，可以在手机平板和pc上都能良好展示，适用于网站类的项目，而lib-flexible解决的是手机端网页的适配问题，压根无论平板和pc的状况，适用于web app类的项目。

2. 1px边框在lib-flexible下如何处理

web app有时候会设计出一些特别细的线条或者边框，若是咱们直接经过css设置边框为1px：

+ View code

 

结果会发现这种边框在手机里看起来的效果，显得特别地粗，之因此会有这个效果，缘由很简单，由于如今大部分手机的分辨率很高，一个css像素，好比上面代码中的1px，可能至关于2个甚至3个物理分辨率像素，而不像pc，一个css像素始终等于1个物理分辨率像素，因此手机里看到的1px会比实际的粗。

为了解决这个问题，你可能会想到用0.5px来代替1px，不过这个是解决不了问题的，并且带小数的像素在不一样的浏览器下绝对是一个坑，千万要尽可能避免。

那么一般在web app下显示1px的作法是怎样的呢，前阵子在weui的源码中看到了一个很好的办法，值得分享：

+ View code

 

这个办法并非利用border属性来显示边框，而是利用了伪类和transform，最妙的是这个transform，0.5px办不到的事情，它却办获得。

因为lib-flexible在适配的时候，会缩放网页，致使css代码中的1px等于物理分辨率的1px，这样子这个1px边框的问题在通过lib-flexible适配的设备下就很好解决了，直接应用border: 1px solid；便可。可是lib-flexible如今只适配了iphone设备，安卓设备压根没适配：

致使在安卓设备下，1px的边框问题依然存在。因此为了在lib-flexible的项目里解决1px的问题，就得综合两种作法了：

+ View code

 

 

 

这个作法，我作过测试，在我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下显示模糊的问题，基本都是采用这种作法：

+ View code

 

估计当时应该是320的设计稿，img_1x.png是在320设计稿下切出的图，而后img_2x.png是在320设计稿矢量放大2倍后切出的图，高清屏显示img_2x.png，这样就能解决当时iphone4背景图片模糊的问题。

时至今日，手机都是走高配置，低价格的发展路线，480*800这种级别的机子，市面上愈来愈少，大部分手机的分辨率级别都达到了iphone4的标准，比iphone4的清晰级别更高的手机也愈来愈多，一个800块的魅蓝note，它的devicePixelRatio都已经达到了3，原先解决background-image问题的方法，须要调整一下才能适用于如今：

+ View code

 

代码中的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去适配，而应该采用下面这个作法：

+ View code

 

这个代码的最终效果是：

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的话应该是相似这样的：

+ View code

 

考虑到1x不会再有的状况，上面这个mixin能够再调整一下：

+ View code

 

默认用2x的图，devicePixelRatio大于等于2.5的设备用3x的图。这个调整后的mixin就是lib-flexible下，使用雪碧图背景的方法，应用举例：

+ View code

 

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页面里控制好默认只加载首屏的图片，而且采用延迟和懒加载的方式，避免阻塞页面的加载，也能有极好的用户体验，打开手机淘宝的页面给人的感受就是如此，并且你去看看手机淘宝的应用会发现它根本就没有用雪碧图，可是速度仍是很快。