2022年移动端适配方案指南全网最新最全

　　在移动端虽然整体来说大部分浏览器内核都是webkit，而且大部分都支持css3的所有语法。但是，由于手机屏幕尺寸不一样，分辨率不一样，或者你需要考虑横竖屏的问题，或者考虑到各式各样的移动端兼容性问题。这时候你也就不得不解决在不同手机上，不同情况下的展示效果，所以就需要一个开箱即用并且行之有效的移动端适配方案。一、基本知识点
　　工欲善其事必先利其器，在具体介绍适配方案前，在本章我们会学习下适配相关的知识点，便于后续适配方案的直接上手接收。1。1、响应式设计像素
　　像素单位有设备像素、逻辑像素、CSS像素3种。1。1。1、设备像素、设备分辨率
　　设备像素（devicepixels）也叫物理像素，指的是显示器上的真实像素，每个像素的大小是屏幕固有的属性，屏幕出厂以后就不会再改变。
　　设备分辨率描述的就是这个显示器的宽和高分别是多少个设备像素，例如常见的显示器的分辨率为19201080。
　　设备像素和设备分辨率是由操作系统来管理的，浏览器不知道、也不必知道设备分辨率的大小，它主要根据逻辑分别率（下一小节介绍）来计算的。1。1。2、设备独立像素、逻辑分辨率
　　设备独立像素（deviceindependentpixels）是操作系统定义的一种像素单位，应用程序将设备独立像素告诉操作系统，操作系统再将设备独立像素转化为设备像素，从而控制屏幕上真正的物理像素点。
　　为什么需要在应用程序与设备像素之间定义这么一种单位呢？为什么应用程序不应该直接使用设备像素？
　　例如原先在1280720设备分辨率的显示屏中，显示高度为12个设备像素的字体，现在放到设备分辨率为25601440的显示屏中，如果要想得到原先的大小，则需要24个设备像素，如果应用程序直接使用设备像素，那么编写应用程序则将变得非常困难，需要编写应用程序逻辑：字体在一些屏幕上高度为12个设备像素，在另一些屏幕上却需要24个设备像素。
　　因此操作系统定义了一个单位：设备独立像素。操作系统保证：用设备独立像素定义的尺寸，不管屏幕的参数如何，都能以合适的大小显示（这也是设备独立像素名字的由来）。操作系统是如何做到的呢？对于那些像素密度高的屏幕，将多个设备像素划分为一个逻辑像素。至于将多少设备像素划分为一个逻辑像素，这由操作系统决定。
　　对于上面的例子：原本高度为12个设备像素的字体，现在高度为24个设备像素才能得到相同的大小，操作系统会将一个逻辑像素定义为22个真实像素，从而设备独立像素尺寸不需要改变，而且不管在新、旧设备上，显示的尺寸大致相同。
　　设备独立像素与设备像素之间的比例是多少，显示器厂商和操作系统厂商会通过调查研究来得出最利于观看的比例。普遍规律是，屏幕的像素密度越高，就需要更多的设备像素来显示一个设备独立像素。
　　逻辑分辨率用屏幕的宽高来表示（单位：设备独立像素），我们通过操作系统的分辨率设置来改变设备独立像素的大小。例如屏幕的设备分辨率是19201200（单位：设备像素），我们可以在当前的分辨率下设置逻辑分辨率是1280800（单位：设备独立像素）。那么横、纵方向的设备像素数量恰好是设备独立像素的1。5倍。这也意味着，设备独立像素的边长是设备像素边长的1。5倍。1。1。3、CSS像素
　　在CSS中使用的px都是指css像素，比如width：128px。css像素的大小是很容易变化的，当我们缩放页面的时候，元素的css像素数量不会改变，改变的只是每个css像素的大小。也就是说width：128px的元素在缩放200以后，宽度依然是128个css像素，只不过每个css像素的宽度和高度变为原来的两倍。如果原本元素宽度为128个设备独立像素，那么缩放200以后元素宽度为256个设备独立像素。
　　（1）css像素与设备独立像素的关系缩放比例就是css像素边长设备独立像素边长；在缩放比例为100的情况下，1个css像素大小等于1个设备独立像素；在缩放比例为200的情况下，1个css像素大小等于（22）个设备独立像素；
　　（2）css像素与设备像素的关系
　　window。devicePixelRatio设备像素比，devicePixelRatio（在相同长度的直线上）设备像素的数量CSS像素的数量。这个比例也等价于CSS像素边长设备像素边长。如devicePixelRatio2，表示在相同长度的直线上，设备像素的数量是CSS像素数量的2倍，因此CSS像素的边长是设备像素的2倍。缩放会导致CSS像素边长的改变，从而导致window。devicePixelRatio的改变！
　　1。2、响应式设计viewport
　　viewport表示浏览器的可视区域，也就是浏览器中用来显示网页的那部分区域。存在三种viewport分别为layoutviewport、visualviewport以及idealviewport，我们接下来分别介绍三种。1。2。1、layoutviewport
　　layoutviewport为布局视口，即网页布局的区域，它是html元素的父容器，只要不在css中修改元素的宽度，元素的宽度就会撑满layoutviewport的宽度。
　　很多时候浏览器窗口没有办法显示出layoutviewport的全貌，但是它确实是已经被加载出来了，这个时候滚动条就出现了，你需要通过滚动条来浏览layoutviewport其他的部分。
　　layoutviewport用css像素来衡量尺寸，在缩放、调整浏览器窗口的时候不会改变。缩放、调整浏览器窗口改变的只是visualviewport。
　　在桌面浏览器中，缩放100的时候，LayoutViewport宽度等于内容窗口的宽度。（你几乎不会在电脑上见过横向滚动条，除非你调整缩放）
　　但是在移动端，缩放为100的时候，LayoutViewport不一定等于内容窗口的大小。当你用手机浏览浏览宽大的网页（这些网页没有采用响应式设计）的时候，你只能一次浏览网页的一个部分，然后通过手指滑动浏览其他部分。这就说明整个网页（LayoutViewport）已经加载出来了，只不过你要一部分一部分地看。
　　1。2。2、visualviewport
　　visualviewport为视觉视口，就是显示在屏幕上的网页区域，它往往只显示layoutviewport的一部分。
　　visualviewport就像一台摄像机，layoutviewport就像一张纸，摄像机对准纸的哪个部分，你就能看见哪个部分。你可以改变摄像机的拍摄区域大小（调整浏览器窗口大小），也可以调整摄像机的距离（调整缩放比例），这些方法都可以改变visualviewport，但是layoutviewport始终不变。
　　1。2。3、idealviewport
　　idealviewport为理想视口，不同的设备有自己不同的idealviewport，idealviewport的宽度等于移动设备的屏幕宽度，所以其是最适合移动设备的viewport。只要在css中把某一元素的宽度设为idealviewport的宽度（单位用px），那么这个元素的宽度就是设备屏幕的宽度了，也就是宽度为100的效果。idealviewport的意义在于，无论在何种分辨率的屏幕下，那些针对idealviewport而设计的网站，不需要用户手动缩放，也不需要出现横向滚动条，都可以完美的呈现给用户。1。2。4、利用meta标签对viewport进行控制
　　移动设备默认的viewport是layoutviewport，也就是那个比屏幕要宽的viewport，但在进行移动设备网站的开发时，我们需要的是idealviewport。那么怎么才能得到idealviewport呢？
　　我们在开发h5页面时，最经常见的标签如下所示metanameviewportcontentwidthdevicewidth，initialscale1。0，maximumscale1。0，userscalable0
　　该meta标签的作用是让当前viewport的宽度等于设备的宽度，同时不允许用户手动缩放。如果你不这样的设定的话，那就会使用那个比屏幕宽的默认viewport（layoutviewport），也就是说会出现横向滚动条。
　　相关的属性意义如下所示
　　width
　　设置layoutviewport的宽度，为一个正整数，或字符串widthdevice
　　height
　　设置页面的初始缩放值，为一个数字，可以带小数
　　initialscale
　　允许用户的最小缩放值，为一个数字，可以带小数
　　minimumscale
　　允许用户的最大缩放值，为一个数字，可以带小数
　　maximumscale
　　设置layoutviewport的高度，这个属性对我们并不重要，很少使用
　　userscalable
　　是否允许用户进行缩放，值为no或yes，no代表不允许，yes代表允许二、方案选择
　　在前端滚滚潮流的历史发展中的不同时期分别出现了一些极具代表性的适配方案，以下分别进行简单介绍。2。1、使用css的媒体查询media
　　基于css的媒体查询属性media分别为不同屏幕尺寸的移动设备编写不同尺寸的css属性，示例如下所示。虽然此方法能在一定程度上解决移动设备适配的问题，但我们也可以看出其存在以下问题，所以其已几乎被历史潮流淘汰。页面上所有的元素都得在不同的media中定义一遍不同的尺寸，这个代价有点高；如果再多一种屏幕尺寸，就得多写一个media查询块；mediaonlyscreenand（minwidth：375px）｛。logo｛width：62。5px；｝｝mediaonlyscreenand（minwidth：360px）｛。logo｛width：60px；｝｝mediaonlyscreenand（minwidth：320px）｛。logo｛width：53。3333px；｝｝2。2、使用rem单位
　　rem（fontsizeoftherootelement）是指相对于根元素的字体大小的单位，如果我们设置html的fontsize为16px，则如果需要设置元素字体大小为16px，则写为1rem。但是其还是必须得借助media属性来为不同大小的设备设置不同的fontsize，相对上一种方案，可以减少重复编写相同属性的代价，简单示例如下所示。
　　我们也能看到该方案存在以下问题：不同的尺寸需要写多个media；所有涉及到使用rem的地方，全部都需要调用方法calc（），这个也挺麻烦的；mediaonlyscreenand（minwidth：375px）｛html｛fontsize：375px；｝｝mediaonlyscreenand（minwidth：360px）｛html｛fontsize：360px；｝｝mediaonlyscreenand（minwidth：320px）｛html｛fontsize：320px；｝｝定义方法：calcfunctioncalc（val）｛returnval1080；｝。logo｛width：calc（180rem）；｝2。3、flexible适配方案
　　在rem方案上进行改进，我们可以使用js动态来设置根字体，这种方案的典型代表就是flexible适配方案。2。3。1、使用rem模拟vw特性适配多种屏幕尺寸
　　它的核心代码如下所示set1remviewWidth10functionsetRemUnit（）｛varremdocEl。clientWidth10docEl。style。fontSizerempx｝setRemUnit（）；
　　上面的代码中，将html节点的fontsize设置为页面clientWidth（布局视口）的110，即1rem就等于页面布局视口的110，这就意味着我们后面使用的rem都是按照页面比例来计算的。2。3。2、控制viewport的width和scale值适配高倍屏显示
　　设置viewport的width为devicewidth，改变浏览器viewport（布局视口和视觉视口）的默认宽度为理想视口宽度，从而使得用户可以在理想视口内看到完整的布局视口的内容。
　　等比设置viewport的initialscale、maximumscale、minimumscale的值，从而实现1物理像素1css像素，以适配高倍屏的显示效果（就是在这个地方规避了大家熟知的1px问题）varmetaELdoc。querySelector（meta〔nameviewport〕）；vardprwindow。devicePixelRatio；varscale1dprmetaEl。setAttribute（content，widthdevicewidth，initialscalescale，maximumscalescale，minimumscalescale，userscalableno）；2。3。3、flexible的缺陷
　　不可否认flexible在兼容性不友好的某个时期还是极大帮助来成千上万的开发者，但是该方案自身是存在一些问题的。由于其缩放的缘故，video标签的视频频播放器的样式在不同dpr的设备上展示差异很大；如果你去研究过libflexible的源码，那你一定知道libflexible对安卓手机的特殊处理，即：一律按dpr1处理；if（isIPhone）｛iOS下，对于2和3的屏，用2倍的方案，其余的用1倍方案if（devicePixelRatio3（！dprdpr3））｛dpr3；｝elseif（devicePixelRatio2（！dprdpr2））｛dpr2；｝else｛dpr1；｝｝else｛其他设备下，仍旧使用1倍的方案dpr1；｝不再兼容media的响应式布局，因为media语法中涉及到的尺寸查询语句，查询的尺寸依据是当前设备的物理像素，和flexible的布局理论（即针对不同dpr设备等比缩放视口的scale值，从而同时改变布局视口和视觉视口大小）相悖，因此响应式布局在等比缩放视口大小的情境下是无法正常工作的；
　　其实flexible方案是在模拟viewport功能，只是随着浏览器的发展及兼容性增强，viewport已经能兼容绝大部分主流浏览器，并且flexible方案自身存在的问题，所有其也已几乎退出历史潮流。引用libflexible的github主页的原话：
　　由于viewport单位得到众多浏览器的兼容，libflexible这个过渡方案已经可以放弃使用，不管是现在的版本还是以前的版本，都存有一定的问题。建议大家开始使用viewport来替代此方案。2。4、viewport适配方案
　　由于viewport单位得到众多浏览器的兼容，所以目前基于viewport的移动端适配方案被各大厂团队所采用。
　　vw作为布局单位，从底层根本上解决了不同尺寸屏幕的适配问题，因为每个屏幕的百分比是固定的、可预测、可控制的。viewport相关概念如下：vw：是viewportswidth的简写，1vw等于window。innerWidth的1；vh：和vw类似，是viewportsheight的简写，1vh等于window。innerHeihgt的1；vmin：vmin的值是当前vw和vh中较小的值；vmax：vmax的值是当前vw和vh中较大的值；
　　假设我们拿到的视觉稿宽度为750px，视觉稿中某个字体大小为75px，则我们的css属性只要如下这么写，不需要额外的去用js进行设置，也不需要去缩放屏幕等；。logo｛fontsize：10vw；1vw750px17。5px｝
　　2。4。1、设置meta标签
　　在html头部设置mata标签如下所示，让当前viewport的宽度等于设备的宽度，同时不允许用户手动缩放。metanameviewportcontentwidthdevicewidth，initialscale1。0，maximumscale1。0，userscalable0
　　2。4。2、px自动转换为vw
　　设计师一般给宽度大小为375px或750px的视觉稿，我们采用vw方案的话，需要将对应的元素大小单位px转换为vw单位，这是一项影响开发效率（需要手动计算将px转换为vw）且不利于后续代码维护（css代码中一堆vw单位，不如px看的直观）的事情；好在社区提供了postcsspxtoviewport插件，来将px自动转换为vw，相关配置步骤如下：
　　（1）安装插件npminstallpostcsspxtoviewportsavedev
　　（2）webpack配置
　　官网是使用glup进行配置，但是我们项目模版中是使用webpack进行postcss插件以及相关样式插件的配置，所以我们就使用webpack进行配置使用，不需要额外引入gulp编译；webpack相关配置如下，且每个属性表示的意义进行了备注：module。exports｛plugins：｛。。。postcsspxtoviewport：｛optionsunitToConvert：px，需要转换的单位，默认为pxviewportWidth：750，设计稿的视窗宽度unitPrecision：5，单位转换后保留的精度propList：〔，！fontsize〕，能转化为vw的属性列表viewportUnit：vw，希望使用的视窗单位fontViewportUnit：vw，字体使用的视窗单位selectorBlackList：〔〕，需要忽略的CSS选择器，不会转为视窗单位，使用原有的px等单位minPixelValue：1，设置最小的转换数值，如果为1的话，只有大于1的值会被转换mediaQuery：false，媒体查询里的单位是否需要转换单位replace：true，是否直接更换属性值，而不添加备用属性exclude：undefined，忽略某些文件夹下的文件或特定文件，例如nodemodules下的文件include：src，如果设置了include，那将只有匹配到的文件才会被转换landscape：false，是否添加根据landscapeWidth生成的媒体查询条件landscapeUnit：vw，横屏时使用的单位landscapeWidth：1125，横屏时使用的视窗宽度｝，｝，｝；
　　相关配置属性，通过注释一目了然其作用，其中需要强调的点为propList属性，我们配置了fontsize不进行转换vw，也就是说在不同手机屏幕尺寸下的字体大小是一样的。其中fontsize是否需要根据屏幕大小做适配，或者怎么做，一直是个争论不休的话题；考虑到我们移动端没有平板的需求，且咨询过团队业务设计师的意见，所以对模版进行以上默认配置；当然如果你的视觉要求你的项目要做字体大小适配，修改propList属性的配置即可。
　　（3）效果展示我们在项目代码中，进行如下css编码：。hello｛color：333；fontsize：28px；｝
　　启动项目，我们可以看到浏览器渲染的页面中，postcsspxtoviewport已经帮我们做进行了pxvw的转换；如下所示：
　　2。4。3、标注不需要转换的属性
　　在项目中，如果设计师要求某一场景不做自适配，需为固定的宽高或大小，这时我们就需要利用postcsspxtoviewport插件的Ignoring特性，对不需要转换的css属性进行标注，示例如下所示：pxtoviewportignorenext下一行不进行转换。pxtoviewportignore当前行不进行转换exampleinput：。class｛pxtoviewportignorenextwidth：10px；padding：10px；height：10px；pxtoviewportignore｝exampleoutput：。class｛width：10px；padding：3。125vw；height：10px；｝
　　2。4。4、Retina屏预留坑位
　　考虑Retina屏场景，可能对图片的高清程度、1px等场景有需求，所以我们预留判断Retina屏坑位。相关方案如下：在入口的html页面进行dpr判断，以及datadpr的设置；然后在项目的css文件中就可以根据datadpr的值根据不同的dpr写不同的样式类；
　　（1）index。html文件index。html文件constdprdevicePixelRatio3？3：devicePixelRatio2？2：1；document。documentElement。setAttribute（datadpr，dpr）；
　　（2）样式文件〔datadpr1〕。hello｛backgroundimage：url（image1x。jpg）；〔datadpr2〕。hello｛backgroundimage：url（image2x。jpg）；｝〔datadpr3〕。hello｛backgroundimage：url（image3x。jpg）；｝
　　三、若干特定场景最佳实践3。1、行内样式的场景
　　场景：当你需要写行内样式的代码（style）时，postcsspxtoviewport插件无法进行px单位无法转换，需要自己手动计算好vw；
　　最佳实践：通过添加、修改、删除className的方式进行处理此类场景，不直接操作行内样式，这更符合将js和css隔离开的更佳实践。3。2、1px的问题
　　retina屏下1px问题是个常谈的问题，相比较普通屏，retina屏的1px线会显得比较粗，设计美感欠缺；在视觉设计师眼里的1px是指设备像素1px，而如果我们直接写css的大小1px，那在dpr2时，则等于2px设备像素，dpr3时，等于3px设备像素。所以对于要求处理1px的场景，我们要进行特殊处理。
　　以下介绍常用的几种方法3。2。1、transform：scale（0。5）
　　可以使用transform：scale（0。5）进行X、Y轴的缩放，如下示例所示。class1｛height：1px；transform：scaleY（0。5）；｝
　　优点是编写简单，但是如果实现上下左右四条边框会比较难搞，并且如果有嵌套存在的话，会对包含的元素产生影响，所以结合：before和：after来使用。3。2。2、transform：scale（0。5）：before：after（推荐）
　　此种方式能解决例如标签上下左右边框1px的场景，以及有嵌套元素存在的场景，比较通用，示例如下所示。calss1｛position：relative；：：after｛content：；position：absolute；bottom：0px；left：0px；right：0px；bordertop：1pxsolid666；transform：scaleY（0。5）；｝｝3。2。3、boxshadow
　　利用css对阴影处理来模拟边框，示例如下所示，底部一条线，缺点是存在阴影不好看。。class1｛boxshadow：01px1px1pxrgba（0，0，0，0。5）；｝3。2。4、其它
　　还有如下等方式处理1px问题，但不推荐，了解即可viewport：将页面进行缩小处理；borderimage：切个1px图片来模拟；backgroundimage：切个1px图片来模拟；lineargradient：通过线性渐变，来实现移动端1px的线；svg：基于矢量图形（svg）在不同设备屏幕特性下具有伸缩性。3。3、图片高清的问题
　　图片高清的问题：适用普通屏的图片在retina屏中，图片展示就会显得模糊；适用retina屏的图片在普通屏中，图片展示就会缺少色差、没有锐利度，并且浪费带宽；
　　所以如果对性能、美观要求很高的场景，需要根据dpr区分使用对应的图片，我们在文章viewport适配方案中针对retina屏预留了dpr方案，相关css写法如下：〔datadpr1〕。hello｛backgroundimage：url（image1x。jpg）；〔datadpr2〕。hello｛backgroundimage：url（image2x。jpg）；｝〔datadpr3〕。hello｛backgroundimage：url（image3x。jpg）；｝
　　四、iPhoneX适配方案
　　iPhoneX取消了物理按键，改成底部小黑条，这一改动导致网页出现了比较尴尬的屏幕适配问题。对于网页而言，顶部（刘海部位）的适配问题浏览器已经做了处理，所以我们只需要关注底部与小黑条的适配问题即可（即常见的吸底导航、返回顶部等各种相对底部fixed定位的元素）。比如一些需要贴在底部的按钮，和呼起的tabBar和底部弹出框，在iphoneX上就会出现被小黑条遮挡内容，或者页面上出现白色空隙的问题。处理前后截图如下所示
　　4。1、适配之前需要了解的几个新知识4。1。1、安全区域
　　安全区域指的是一个可视窗口范围，处于安全区域的内容不受圆角（corners）、齐刘海（sensorhousing）、小黑条（HomeIndicator）影响，如下图蓝色区域：
　　也就是说，我们要做好适配，必须保证页面可视、可操作区域是在安全区域内。更详细说明，参考文档：HumanInterfaceGuidelinesiPhoneX4。1。2、viewportfit
　　iOS11新增特性，苹果公司为了适配iPhoneX对现有viewportmeta标签的一个扩展，用于设置网页在可视窗口的布局方式，可设置三个值。contain：可视窗口完全包含网页内容（左图）cover：网页内容完全覆盖可视窗口（右图）auto：默认值，跟contain表现一致
　　需要注意：网页默认不添加扩展的表现是viewportfitcontain，需要适配iPhoneX必须设置viewportfitcover，这是适配的关键步骤。更详细说明，参考文档：viewportfitdescriptor
　　4。1。3、env（）和constant（）
　　iOS11新增特性，Webkit的一个CSS函数，用于设定安全区域与边界的距离，有四个预定义的变量：safeareainsetleft：安全区域距离左边边界距离safeareainsetright：安全区域距离右边边界距离safeareainsettop：安全区域距离顶部边界距离safeareainsetbottom：安全区域距离底部边界距离
　　这里我们只需要关注safeareainsetbottom这个变量，因为它对应的就是小黑条的高度（横竖屏时值不一样）。
　　注意：当viewportfitcontain时env（）是不起作用的，必须要配合viewportfitcover使用。对于不支持env（）的浏览器，浏览器将会忽略它。
　　需要注意的是之前使用的constant（）在iOS11。2之后就不能使用的，但我们还是需要做向后兼容，像这样：paddingbottom：constant（safeareainsetbottom）；兼容iOS11。2paddingbottom：env（safeareainsetbottom）；兼容iOS11。2
　　注意：env（）跟constant（）需要同时存在，而且顺序不能换。更详细说明，参考文档：DesigningWebsitesforiPhoneX
　　4。2、适配步骤4。2。1、设置网页在可视窗口的布局方式
　　新增viweportfit属性，使得页面内容完全覆盖整个窗口，前面也有提到过，只有设置了viewportfitcover，才能使用env（）metanameviewportcontentwidthdevicewidth，viewportfitcover4。2。2、fixed完全吸底元素场景的适配
　　可以通过加内边距padding扩展高度：｛paddingbottom：constant（safeareainsetbottom）；paddingbottom：env（safeareainsetbottom）；｝
　　或者通过计算函数calc覆盖原来高度：｛height：calc（60px（假设值）constant（safeareainsetbottom））；height：calc（60px（假设值）env（safeareainsetbottom））；｝
　　注意，这个方案需要吸底条必须是有背景色的，因为扩展的部分背景是跟随外容器的，否则出现镂空情况。
　　还有一种方案就是，可以通过新增一个新的元素（空的颜色块，主要用于小黑条高度的占位），然后吸底元素可以不改变高度只需要调整位置，像这样：｛marginbottom：constant（safeareainsetbottom）；marginbottom：env（safeareainsetbottom）；｝
　　空的颜色块：｛position：fixed；bottom：0；width：100；height：constant（safeareainsetbottom）；height：env（safeareainsetbottom）；backgroundcolor：fff；｝4。2。3、fixed非完全吸底元素场景的适配
　　像这种只是位置需要对应向上调整，可以仅通过下外边距marginbottom来处理｛marginbottom：constant（safeareainsetbottom）；marginbottom：env（safeareainsetbottom）；｝
　　或者，你也可以通过计算函数calc覆盖原来bottom值：｛bottom：calc（50px（假设值）constant（safeareainsetbottom））；bottom：calc（50px（假设值）env（safeareainsetbottom））；｝五、VW兼容方案
　　Android4。4之下和iOS8以下的版本有一定的兼容性问题（ps：几乎绝迹，大家可以统计下你们的用户使用的系统版本占比），但是社区提供了兼容性解决方案，其为viewport的buggyfill：ViewportUnitsBuggyfill，可以访问其github官网查看。
　　我们也做了对应的实践，但是考虑到性能，我们项目模版中不会进行引入，有兴趣的同学可以查看以下实践总结；5。1、ViewportUnitsBuggyfill引入
　　viewportunitsbuggyfill主要有两个JavaScript文件：viewportunitsbuggyfill。js和viewportunitsbuggyfill。hacks。js。你只需要在你的HTML文件中引入这两个文件，比如在react项目中的index。html引入它们；
　　第二步，在HTML文件中调用viewportunitsbuggyfill，比如：
　　但是为保证ViewportUnitsBuggyfill起作用，我们必须在我们样式文件中用到了viewport的单位（vw、vh、vmin或vmax）地方添加content，如下所示：。myviewportunitsusingthingie｛width：50vmin；height：50vmax；top：calc（50vh100px）；left：calc（50vw100px）；hacktoengageviewportunitsbuggyfillcontent：viewportunitsbuggyfill；width：50vmin；height：50vmax；top：calc（50vh100px）；left：calc（50vw100px）；；｝5。2、postcssviewportunits引入
　　在1步骤中，我们人肉引入content属性，效率是非常低下的，好在社区提供了postcssviewportunits插件，帮我们自动处理content：5。2。1、postcssviewportunits安装配置
　　我们执行以下命令，进行postcssviewportunits插件的安装：tnpmipostcssviewportunitssavedev
　　在我们的项目配置文件webpack。config。js中进行对应的插件引入配置：｛loader：postcssloader，options：｛ident：postcss，plugins：（）〔我们加的配置require（postcssviewportunits），〕，sourceMap：isProductionEnv，｝，｝，5。2。2、效果展示
　　我们在项目代码中，进行如下编码：。hello｛color：333；fontsize：28px；｝
　　展示的页面中，postcssviewportunits已经帮我们添加了content属性；如下所示：