在过去的几年时间里，移动端web野蛮生长，智能机的Android阵营和IOS阵营分庭抗礼，随之产生了多个系统版本（系统版本多样）；五花八门的屏幕尺寸、屏幕展示技术（如大名鼎鼎的Retina技术屏）层出不穷（屏幕尺寸、技术多样），还是CSS的W3C标准在各式各样的移动端浏览器上落实得也是七零八落（浏览器兼容多样）。

 

　　细看下来移动端Web开发工作面临着很多的多样性，可想而知在这样的不确定性下去开发一个完善的项目会有多大的阻力，因此，移动端Web亟需一个完善成熟的适配方案来磨平这些多样性之间的差异和不足，提供一个相对稳定、可控的开发环境。

 

　　本文只介绍CSS样式布局的适配方案，至于HTML5和JavaScript的适配方案，其实现在已经有了一些成熟的解决方案，如Babel，各种polyfill等，并且搭配Webpack使用更香。

 

　　Flexible方案主要是借助JavaScript控制的能力，使用模拟的特性从而达到适配目的的一套解决方案。

 

　　Flexible方案的实现涉及并使用到了很多PC端开发很少接触到的概念，其实无论是怎么样的适配方案都是建立在梳理和管理这些概念之上的，因此，这些概念对我们理解和探究移动端适配的深层原理尤为重要（具体概念讲述请见《深入浅出移动端适配》）。

 

　　是相对于元素的来做计算的计算属性值。

 

　　通过设置的属性值就可以统一整个页面的布局标准。

 

　　如上代码所示，Flexible将整个页面的宽度切成了10份，然后将计算出来的页面宽度的设置为节点的，也就意味着，之后我们在当前页面的节点的子节点上应用为单位时都是按照页面比例来计算的。

 

　　设置的为，改变浏览器（布局视口和视觉视口）的默认宽度为理想视口宽度，从而使得用户可以在理想视口内看到完整的布局视口的内容。

 

　　等比设置的、、的值，从而实现，以适配高倍屏的显示效果（就是在这个地方规避了大家熟知的“1px问题”）

 

　　Flexible使用了作为统一页面布局标准的布局单位，且把页面宽度等分为了10份，那么我们在书写css代码时就需要去计算当前的单位在当前设计稿上对应的值应该是多少。

 

　　以iPhone6为例：布局视口为，则，这时设计稿上给定一个元素的宽为（设备独立像素），我们只需要将它设置为即可。

 

　　当然，以上的工作方式显然是低效且不可接受的，我们可以借助PostCSS的插件来帮我们完成这个计算过程：

 

　　以上代码是基于Vue Cli3.x的Webpack项目，只需要配置在当前项目根目录的中即可，除了Webpack配置之外，还可以使用其他的配置方式，详细介绍可以点击这里进行了解。

 

　　可以帮我们把我们需要转的px值计算转换为对应的值，如：

 

　　转换后是这个样子：

 

　　即中展示的内容依然使用的是像素，在高倍屏下会出问题，如我们在使用引用一个腾讯视频的视频播放资源时，该视频播放器的播放按钮在不同的设备上展示差异很大：

 

　　从图中我们可以看出播放按钮在的设备上展示的大小要比在的设备上要大很多，如果你去仔细测量的话，会发现刚好是其倍，如果你读过了深入浅出移动端适配，那么很容易就理解为什么了，我们这里不做深究。

 

　　如果你去研究过的源码，那你一定知道对安卓手机的特殊处理，即：一律按处理。

 

　　那么，Flexible为什么不对安卓的高倍屏做适配处理呢？我想Flexible这样做应该是有苦衷的：长久以来，安卓手机的五花八门，从到甚至到，更甚者、、这样的值也层出不穷。所以Flexible在权衡之下直接简单粗暴的把安卓手一律按处理，也算是快刀斩乱麻了。

 

　　当然，我们也可以手动去修改的源码去弥补上这个缺憾，但我们也只可能针对那些为整数的安卓设备做适配，对于那些比较奇葩的直接忽略即可。然而，天知道安卓手机的最大整数值是多少呢？天知道（三星S8的就是）

 

　　响应式布局，其实质性做法就是结合的媒体查询对一些不同尺寸阈值做特定的布局设计，如对以下屏幕的使用紧凑型布局，对到的屏幕做图文混排型布局，对大于的屏幕做富元素、多元素布局等。

 

　　其中，语法中涉及到的尺寸查询语句，查询的尺寸依据是当前设备的物理像素，和Flexible的布局理论（即针对不同设备等比缩放视口的值，从而同时改变布局视口和视觉视口大小）相悖，因此响应式布局在“等比缩放视口大小”的情境下是无法正常工作的。

 

　　根据Flexible的实现理论，我们都知道它是通过设置的元素的大小，从而确保页面内所有元素在使用为单位进行样式设置时都是相对于元素的值。

 

　　然而，在微信环境（或其他可设置字体大小的Web浏览器中，如Safari）下，设置微信的字体大小（调大）后再打开使用Flexible技术适配的Web页面，你会发现页面布局错乱了，所有使用设置大小的元素都变大了，此时的还是原来的大小，但是元素就是变大了，这是为什么呢？

 

　　事实上，虽然Flexible帮我们使用标签设置了和以及对应的缩放值以保证我们的元素大小在高倍屏下（ ）正常展示，但是在调整Web浏览器的字体大小后，我们的"视口"也响应的等比缩小了，即视觉视口（），豁然开朗，并不是我们的元素变大了，而是我们的视觉视口变小了！

 

　　基于我们已经掌握的视口相关知识，其根本原因是我们在调整Web浏览器的字体大小时，也响应的调整了视口的值，因此才导致了视觉视口的变小。

 

　　知道了Bug产生的原因，那我们有办法解决吗？答案是在Flexible方案下毫无办法，而在接下来要讲到的Viewport方案中则可以完美解决。Flexible承载的历史使命已经完成了，让我们放下Flexible，拥抱新的变化。

 

　　Viewport方案中主要使用的是中CSS Values and Units Module Level 3（候选推荐）新增的单位、、和。定义中，它们都是相对单位，其相对的参考系都是"视觉视口":

 

　　unitrelative to（参考单位）和是根据Viewport中长度偏大的那个维度值计算出来的，如果则取值为，取值为。

 

　　可能会有同学担心Viewport方案的浏览器兼容性问题，我们可以使用caniuse来查看下viewport单位在各主流浏览器版本上的兼容情况：

 

　　从图中可以看出，目前大部分的主流浏览器基本上已经支持了viewport单位，其中有一些淡绿色的浏览器版本表示为部分支持，其主要内容为无法兼容和的用法；而“Know issues”一栏中所列的一些已知问题大多也是针对用户缩放大小或者所特有的一些buggy behavior，而对于这些我们是可以控制的。

 

　　事实上，我们的适配方案，与其称为“viewport适配方案”不如叫“vw适配方案”，因为在我们的适配方案中，我们只需要使用到这一个相对单位即可，并且其兼容性是最好的，其他单位基本上使用不到。

 

　　对于那些只存在及老版本才会出现的一些问题，大可不必多虑，毕竟现在已经9102年了，而是“2013年9月18日正式推出，2013年9月19日凌晨1点开放免费下载更新”的，年代久远，加之的不更新系统就给你来个限速变卡的骚操作，这种远古系统再出现的概率几乎为0。

 

　　作为布局单位，从底层根本上解决了不同尺寸屏幕的适配问题，因为每个屏幕的百分比是固定的、可预测、可控制的。

 

　　从我们的实际开发工作出发，我们现在都是统一使用的的视觉设计稿（即宽度为），那么，即。那么如果设计稿上某一元素的宽度为像素，那么其对应的vw值则可以通过来计算得到。