手淘 flexible.js 分析
October 05, 2016
flexible是手淘移动端自适应的方案，github地址： https://github.com/amfe/lib-flexible flexible.js源码： https://github.com/amfe/lib-flexible/blob/master/src/flexible.js
在网易实习的时候主要开发的项目是网易有钱h5项目，一直在用flexible做移动端自适应。在开发中我查看了flexible的源码，结合项目里遇到的一些坑，在这里总结一下这个框架的优缺点。
一、源码结构
1.meta名称为viewport的标签设置了scale时，将根据scale手动设置dpr(dpr用于实现flexible其他功能)。 2.meta名称为flexible的标签存在时，手动设置dpr(本来没有这个标签，flexible源码添加了这个API并解析这个标签的属性，详见文档)。 3.根据js获取到的devicePixelRatio设置dpr及scale，scale是dpr的倒数。(ios系统根据dpr的值设置为1、2、3，Android统一设置dpr为1)。 4.添加meta标签，设置name为viewport，content根据scale设置缩放比(默认、最大、最小缩放比)。 5.resize事件与pageshow事件延时300毫秒触发fontSize的重置(这里用了防抖函数，防止resize事件被高频触发可能引起的性能问题) 6.为body设置fontSize，值为12*dpr+”px” 7.扩展一些方法：获取页面dpr，获取rem基准值，rem与px相互转换，重置dpr，这些方法可以在引入flexible.js之后调用，使用方式参考api文档。
以上是源码整体的结构，实际上我们在使用的时候很多功能用不到，比如手动设置scale和dpr、flexible标签、扩展方法等等。因此在默认设置的时候，flexible核心的操作如下： 1.为html添加data-dpr属性和style属性，style添加font-size作为1rem的基准值。 2.改写meta标签，根据dpr设置设备的缩放比。
二、flexible优点
1.可以适配众多不同终端的设备。 2.使用简便，只需引入flexible.js即可。 3.由手淘团队维护，相对稳定。
三、flexible缺点
1.不是纯css的移动适配方案，需要引入js文件。 2.高宽比变化引起呈现变化，一般公司里的UI设计稿是以iphone6的屏幕为画布，高宽比为16:9，flexible的rem长度本质上是基于设备宽度的百分比长度，因此在设备高宽比非16:9的时候将会不再是设计稿希望呈现的布局比例。(较常见的非16:9高宽比的场景有ipad的4:3、魅族16:10、手机横屏显示，如果需要在PC上访问高宽比更是多样化) 比如一个新闻列表，竖屏的时候可以一页显示六条新闻，ipad上只能显示四五条新闻，竖屏可能只能显示两三条。 一般限制主体内容区域的最大宽度，使之在屏幕高宽比变小的时候不至于字号、图片过大影响用户体验。
3.吃像素问题，浏览器的渲染，最小的单位就是像素，不可能一个像素出现多种颜色。而通过rem计算后的距离值经常出现小数，浏览器会对这部分小数进行四舍五入，从而按照整数渲染颜色。有可能会导致元素边缘被“吃掉”一部分。
四舍五入吃像素的细节参见：rem产生的小数像素问题。
4.兼容性问题，安卓4.3及2以下版本系统不支持viewport缩放。
5.webview限制，webview作为原生开发的一个组件，移动客户端可以限制这个组件的大小。在webview大小被限制的时候，使用flexible使得比例难以计算。
6.不支持响应式设计方案，响应式设计需要用到css3媒体查询，根据查询到的设备宽度使用不同的css样式。而引入flexible的页面会根据dpr进行缩放，css3媒体查询得到的是缩放前的宽度而不是缩放后的宽度。
四、后记
在去哪儿网第二轮面试时遇到了杜瑶大神，在面试中交流了很多移动适配和响应式设计的细节。
去哪儿网内部使用Yo作为移动UI框架，是纯css方案，且支持响应式。在入职前要求自学这个框架，后面我会仔细研究，另发日志记录这个方案。