移动端适配方案移动端适配方案是一个比较常见的话题，但是针对不同的项目，不同的业务场景，可能需要不同的适配方案进行移动端适配。兼容的基线也需要提前订购。其实移动端整体的宽高和下面的玩具是一样的，对应的形状可以塞进对应的容器里。但是有一个小问题就是这些块的大小可能和容器不一样。对于前端来说，这些积木不是木头做的，应该是橡皮泥做的。商业环境是决定整体项目适配方案的核心因素。一套代码需要兼容多少环境，需要在项目开始架构时确定。程序员交友网站，github主站可以清楚的看到所有内容都被限制在一个980像素的内容区域内。而它的移动端也明显是单独的布局方式，整体宽度不再受限。即使在iPadPro这样宽度为1024像素的设备上，它仍然会占据整个屏幕。淘宝主站和github类似，分为手机端和PC端，PC端也有左右空白，也是为了让用户在宽屏的时候把注意力集中在中间区域。目前大部分站点都是通过UA判断用户的设备，然后直达PC或者H5页面。两者唯一的区别是淘宝会更加严格的将页面直接重定向到另一个链接，而github加载不同的CSS文件进行渲染。当然，这两种方案没有本质区别，单独的H5页面可以更好的在客户端复用。因此，如果有足够多的开发者，开发适合两种设备类型的页面是一种友好的解决方案。如果你的手机客户端是基于webview开发的，那么H5页面也可以直接嵌入到webview中展示。宽度适配对于整体宽度，一般移动设备的纵横比比较协调，但iPad等设备宽度过大，导致正常H5页面在其上显示时出现奇怪的效果。比如淘宝主站在iPad上的展示效果，可以看到上下区块的导航器被拉长了很多，导致效果不好。但是如果考虑成本的话，iPad用户会更多的使用APP来访问，所以H5页面风格的重要性就降低了。github移动版会更好的适配宽屏设备。有兴趣的可以看看淘宝的H5页面。这个页面有一个非常有趣的地方。这个地方后面会提到。这里先提一下：除了width仍然占据屏幕宽度的方案外，设置屏幕的最大宽度。可以保证在宽屏设备上的显示效果，但需要考虑空白部分进行处理。由于最大宽度是固定的，所以只需要对空白超过宽度的设备做特殊处理（可以是背景，功能按钮等），中间最大宽度的部分可以使用用于代码重用。viewport考拉团队写的这篇博客写的很清楚。感谢考拉小伙伴们为我们提供了便宜的海淘和这么好的文档输出lol：在PC桌面浏览器中，正常视口的宽度是整个浏览器的窗口宽度，会随着浏览器窗口的伸缩而缩放.默认情况下，如果未设置HTML的静态宽度，HTML标签将填充整个视口。如果如前所述在PC端页面设置了最大宽度，那么当视口缩放到最大宽度之外时，不会影响可见区域的显示效果，但如果缩小到小于最大宽度width,原来页面的布局方案很重要。弹性布局和百分比布局可以保证页面收缩时页面布局不会塌陷。布局视口在手机端，视口和手机浏览器的宽度不再关联，而是完全独立。我们称之为布局视口。整个页面可能会变得很大，然后只有一部分显示在设备的可见区域，整个页面的大小称为LayoutViewport。这个大小可以通过document.documentElement.clientHeight/clientWidth获取。PPK这篇很早的文章对视口的描述非常清楚。从上图可以看出，LayoutViewport的宽高其实是可变的。当页面被手势缩放时，LayoutViewport会发生变化。当页面缩放到与设备可见区域相同大小时，LayoutViewport刚好等于向上的VisualViewport。可见视口VisualViewport其实很好理解，就是整个屏幕可见区域的大小。由于设备的物理像素，即CSS中的pt单位是固定的，在移动端对页面进行缩放后，CSS像素在页面中的分布在设备上也会发生变化。IdealViewport其实就是以上两者的结合。当我们将LayoutViewport的宽度设置为屏幕的宽度时，我们可以保证页面中的CSS像素不变。这里使用移动端适配常用的标签来保证页面的宽度与移动端屏幕的宽度一致。在手机端放大时，页面中的CSS像素保持不变，但可见视口的像素比例发生变化，但禁用缩放会导致部分用户体验不佳。将缩放比例保持在一定范围内是合适的。整体布局以上述内容为基础，结合当前业务内容-主要适配移动端，使用最大宽度的设置，并在meta标签中设置idealviewport，可以保证整体上的视图移动设备和PC布局效果。内容布局目前移动端适配的内容布局效果如下：百分比，所有需要动态调整的元素的宽高都使用百分比，字体大小固定为像素。rem，通过计算或者JavaScript获取设备像素/CSS像素的比例，确定根元素的字体像素，然后根据rem中根元素的字体像素设置所有单位，确定大小。并且baserem会根据设备发生变化。vw，根据当前设备的VisualViewport宽度为100vw，然后得到单位vw的宽度，所有元素按照vw单位排列。媒体查询：使用断点来适应不同宽度间隔的设备样式。上述每种方法都有其自身的优点。我们可以看看实际应用效果：Percentage使用百分比作为内容大小的标准，在大多数情况下是可行的。百分比可以使元素保持独立。位置，与屏幕的宽度无关。但是文本有一个很大的问题。由于文本的大小是固定的，当屏幕dpr发生变化时，文本的CSS像素保持不变，从而导致文本在页面上占用的空间发生变化。这样做的结果是，当文字过多或屏幕dpr过小时，会发生溢出；但如果以小屏幕为基准，字体就会偏小。当前移动端适配排版时，将使用百分比作为版块级元素的兼容排版。这也与设计稿中的效果有关。如果设计稿要求一个元素有固定的宽度，那么就用px来保证宽度即可。remrem单位有点类似于之前常用的em。唯一的区别是rem和根据根元素的字体大小计算的相对值。Em有很多缺点。比如层层嵌套之后，你可能会忘记上一层的font-size是多大。或者像现在的模块化开发一样，一个路由嵌入另一个路由，甚至需要在其他文件中找到父元素。为了解决em的问题，标准中还有单位rem来帮助排版。所有的元素大小都以rem为单位，然后在页面的根元素中，我们给根元素的font-size赋一个确定的值，这样所有的rem单位都有一个明确的基准。屏幕适配时，只需要调整这个参考值，就可以保证每个元素的大小自动按比例调整。阿里的lib-flexible方案其实就是采用这种方式，将font-size和data-dpr属性绑定到标签上，适配整个页面。该方案将整个页面宽度分为100个部分。之所以分成100份，可以看下面的另一个方案。每10个单位宽度视为1rem，即整个mockup的宽度将被分成100份10rem。如果你拿到的mockup是750px，那么1rem就是75px。这样得到的比例因子为75/750，即每次将设计稿转成CSS，只需将设计稿的像素值除以/10，即可得到对应的rem值。通过一个预加载的JavaScript脚本，计算出根节点的字体大小，document.documentElement.style.fontSize=window.innerWidth/10+'px';，那么我们只需要写入原始像素值/参考值可以得到对应的rem单位。当然，每次都按计算器肯定是不够的。如果想使用方便，可以使用less或sass等预处理器对页面进行处理。@functionpx2rem($px)//这里将设计稿的px转换为rem，@return($px/$unit-px)*1rem//根据设备的dpr适配字体@mixinfont-dpr($font-size)font-size:$font-size[data-dpr="2"]&font-size:$font-size*2除了元素的宽高，可以更好的还原，而且文字大小的适配也比较好重要，因为每个设备的dpr不一样（这里特别是iOS设备），直接导致很多文字在iPhone6+上显示正常，但是在iPhone5太大，导致文字溢出。上面的lessmixin是适配字体样式的。匹配。这种方法结合了sass的功能和rem的适配，加上必要的百分比和媒体查询，以获得更好的移动性能。这是使用该方法在iphone6上的显示效果。具体的整体展示效果，可以点击这里。rem基准样式示例。如果对文本在各个平台的显示效果不满意，可以使用上面提到的sassmixin，让文本按照dpr断点渲染。这样做的问题是只适用于移动端，不能适配横屏，因为横屏之后，页面的宽度发生了变化，但是引用值还是保持原来绑定的引用值根节点。.vw（是最终解决方案吗？）先看看vw的浏览器支持，能否使用vw支持，使用这个单位意味着你放弃IE11以下的PC用户，在一个主要兼容移动端的世界里，有副作用不大（这里吐槽一下，其实PC端的兼容性远比移动端方便。移动端奇怪的分辨率和2x、3x的屏幕，还有硬压的ipad，横屏让我每次做兼容性都想解决烦恼）。vw本身是将整个可见视口水平分成100份，每个单位为1vw。这个单元最大的优点是在移动端，无论是竖屏还是横屏，vw始终是针对水平方向的，相比于rem解决方案的好处是当屏幕尺寸发生变化时（顺便说一句，它兼容未来屏幕尺寸可调的移动设备[手动斜视]），页面不会崩溃。对于移动设备，比如iphone6+的375pxCSS像素宽度，1vw等于3.75px。本单元可以解决上述依赖脚本绑定根元素font-size的问题。竖屏和横屏效果最好。通过vw解耦css和js后，vw能独立解决所有问题吗？//首先我们设计稿的宽度目前是750px，以iPhone6+的实际375px为基准$w-base:375px$w-base-design:750px@functionpx2vw($px)@return($px/$w-base-design)*100vw首先，上面的sass代码可以根据你设计稿上的px单位转换成vw单位值。当然，最简单的方法就是直接根据视觉稿上的像素点输入，然后直接输出对应的vw值。当然vscode和sublime都有现成的插件，但是我个人不是很喜欢这种方式，所以得不到视觉稿的原始像素值。后期维护的时候会增加很多很多很多的麻烦。这个写的爽，改成火葬场吧。..vw的效果可以看下面的codepen。vw也是适配页面，那么有什么优缺点呢？目前vw肯定不适合单独使用。毕竟页面中还有很多元素需要绝对尺寸定位。px永远是必不可少的，视觉不可能让一切都适应你。那么vw能解决什么问题呢？首先是%在CSS中的大部分使用被替换。百分比在CSS中有很多歧义。宽度、上下边距、左右边距、内外边距的处理方法不同。即使是一个复杂的前端有时也不得不考虑当前的百分比是基于什么的。而vw是一个绝对值，仅根据不太可能改变的屏幕宽度确定。百分比主要解决的弹性问题是vw重点解决的问题。vw不能兼顾所有情况，所以这个单元还不是最终的解决方案，我们还需要和其他单元配合，帮助页面展示的更优雅。结语虽然根据实现的效果来看，几种方法的效果可能相差不大，但最大的问题是实现这种效果需要多复杂的代码。CSS兼容性不在于解释器，而在于设备的屏幕。很多时候，不仅需要将页面展示在用户面前，还需要将页面稳定、优雅地展示给用户。无论是百分比、rem还是vw，都是定位于局部容器元素。px作为最底层的叶子元素或者单位元素，会被更多的使用，尽可能的还原视觉稿。从长远考虑这个问题，vw在只有移动接入的情况下是非常有效的，因为不考虑兼容性，只需要考虑适配问题。项目中使用哪种方式取决于大部分业务需要兼容的环境。
