源宝导读：由于我们ERP目前大都是在在PC上面运行，大家现在关注移动端比较少，谈到移动端适配时，可能都有些生疏也可能比较好奇。以前做过一些移动端的little项目，那么借助这次分享的机会，和大家一起讨论学习下。

一、背景

现在市场上移动设备的屏幕尺寸、分辨率、屏幕密度等因素各式各样，尽可能做到所有设备都自适应，只用一套样式布局来适配所有设备。

二、适配最终效果

1. 在不同分辨率的手机上，页面整体布局自适应，不会出现页面的情况；

2. 在不同分辨率的手机上，字体、宽高、间距、图片大小能够和高保真近视一致。

三、移动端相关的知识点

3.1 关于设备

1. 屏幕的像素：物理设备的显示屏最小组成单位，又称物理像素，是由物理设备决定的，出厂时就确定了；

2. 屏幕的尺寸：屏幕对角线的长度，单位是英寸，1英寸（inch）=2.54厘米（cm）；

3. 屏幕的分辨率：例如：1366px768px的分辨率，意思就是屏幕上横向设置了768个像素，竖向设置了1366个像素。假设你调节分辨率为800600，那么多余的像素块会被系统分配相邻的近视色块占据，看起来就放大了，也模糊了；

4. 屏幕的密度：PPI为屏幕每英寸的像素数量，可以理解为一个屏幕对角线长度为1英寸的正方形内所拥有的像素数，用于度量计算机显示屏上像素的密度。

• 公式：

3.2 关于编码

• css像素：是一个相对单位，用来度量web页面上面的内容，与设备像素无关，在标准屏幕密度下，1px对应1个设备像素，但是在现在主流手机上1px并不等于设备的1px；

• dpr：设备像素比，定义物理像素和设备虚拟像素（可以理解为css像素）的对应关系。可以通过js获取，dpr = window.devicePixelRatio = 设备像素 / CSS像素。

1. 上图说明了1px在不同dpr时等于几个物理像素。1px对应物理像素除了和屏幕像素密度dpr有关，还和用户缩放有关系。当用户把页面放大一倍，那么CSS中1px所代表的物理像素也会增加一倍；

2. 反之把页面缩小一倍，CSS中1px所代表的物理像素也会减少一倍。所以一般会在头部meta中禁止用户缩放:user-scalable=’no’。

• viewport：针对移动端的视口概念，大致了解下：

• • width=device-width：设置布局视口的大小等于设备独立像素；

  • initial-scale=1.0：设置布局视口和视觉视口的大小等于设备独立像素；

  • minimum-scale=1.0、maximum-scale=1.0、user-scalable=no：不允许用户进行缩放；

  • 布局视口（layout viewport）：不同设备的布局视口宽度不同，一般都大于可视区域，样式布局可用大小，document.documentElement.clientWidth来获取；

  • 视觉视口（visual viewport）：用户看到的网站展示区域，一般视觉视口和设备宽度一致。并且它的CSS像素的数量会随着用户缩放而改变，单位是px（CSS像素）；该值是可变的（缩放情况下），可以通过window.innerWidth获取。

  • 完美视口（ideal viewport）:理想宽度就是屏幕的宽度。

  <meta name="viewport" content="width=device-width,initial-scale=1.0,user-scalable=no,minimum-scale=1.0,maximum-scale=1.0"/>
  

  四、寻找适配方案的心路历程

  4.1 在手淘方案没有出来之前，移动端适配其实是一大难题，起初尝试的方案思路：

  • 先根据高保真1：1实现；

  • 再根据媒体查询对应不同屏幕宽度、不同屏幕密度来实现细节调整，如：字体、图片等。举个图片的栗子：

  .header-bg {background-image: url(a.png);background-size: 200px 300px;height: 300px;width: 200px;
  }
  @media only screen and (min-width: 320px) {// 小屏幕
  }
  @media screen and (min-width: 320px) and (max-width: 1300px) {// 各种
  }
  @media only screen and (min-width: 1300px) {// 大屏幕
  }
  @media only screen and (-webkit-min-device-pixel-ratio: 2) and (min-width: 1300px) {// 不同dpr 倍图、原始宽高
  }
  

  优点：

  • 图片资源会在对应宽度才会下载；

  • 语法兼容性好；

  • 可以根据不同屏幕精准控制。

  缺点：

  • 显而易见，代码非常冗余，维护不便；

  • 不同尺寸设备细节实现效果不好；

  • 扩展性很差，不可能针对所有类型的终端屏幕做到面面聚到。

  4.2 为了解css代码维护难问题，采用flex弹性布局来解决此问题

  大致思路如下：

  • 设置完美视口，设置布局视口等于可视；

  • 结构性布局都是用flex弹性布局；

  • 细节性margin和padding采用高保真px来布局；

  • 怪异屏幕分辨率，使用媒体查询来做细节调整；

  • 不同屏幕密度、图片、字体仍然采用媒体查询来控制。

  // 远古写法，兼容 Chrome 4+, Safari 3.1, iOS Safari 3.2+
  .flex-box-h {display:-webkit-box;display:box;-webkit-box-orient:horizontal;box-orient:horizontal;
  }
  .flex-box-v {display:-webkit-box;display:box;-webkit-box-orient:vertical;box-orient:vertical;
  }
  // 居中
  .flex-box-align {-webkit-box-pack: center;box-pack: center;-webkit-box-align: center;box-align: center;
  }
  .flex-1 {-webkit-box-flex:1;box-flex:1;
  }
  .flex-1 {-webkit-box-flex:2;box-flex:2;
  }
  // ......
  

  优点：

  • 解决了部分响应式布局代码冗长的问题；

  • 易于维护。

  缺点：

  • 不能兼顾到细节布局，细节布局还是需要采用媒体查询来适配；

  • felx语法版本太多，需要针对不同系统设备来兼容；

  • felx部分特性兼容性不好，例如：自动换行。

  4.3 虽然解决了部分css代码冗长问题，但是还是有不少地方需要借用的媒体查询来做适配，并且还是有一些奇葩机型上，显示细节达不到预想效果。无意间发现关于viewport知识点的文章，上面介绍一个思路能够非常简单实现适配

  大致思路如下：

  • 布局还是根据高保真1:1实现，例如：750px；

  • 通过js代码计算出750px对应的dpi和缩放，然后动态设置target-densitydpi=dpi，告诉浏览器这样来渲染网页；

  • 图片和字号用媒体查询适配。

  // 伪代码，dpi可以理解为ppi屏幕密度
  function targetDensityDpi(){var designerWidth = 750var deviceWidth = window.screen.width;// Device_Dpi为系统的DPI//如果获取系统DPI失败，采用固定值，有一个屏幕宽度对应DPI的标准表，如:Width<320，Dpi = 120var densityDpi = designerWidth*(Device_Dpi)/deviceWidth;densitydpi = Math.floor(densitydpi);var scale = designerWidth/deviceWidth;document.querySelector("meta[name=viewport]").setAttribute('content','width=device-width,target-densitydpi='+densitydpi+',initial-scale='+scale+', minimum-scale='+scale+', maximum-scale='+scale+', user-scalable=no');
  }
  

  优点：

  • 减少了不同屏幕密度屏幕媒体查询的适配代码；

  • 不需要考虑某些机型的奇葩宽度，对比上一个方案自适应效果好。

  缺点：

  • 未来兼容性不好，target-densitydpi在安卓4.0之后就废弃了；

  • 图片和字体仍然需要媒体查询来适配；

  • 布局细节仍然需要单独处理。

  4.4 动态设置html的font-size + rem + viewport

  大概思路：

  • 根据clientWidth和dpr动态设置font-size；

  • 然后将其他地方根据高保真px转换成rem；

  • 字体通过媒体查询适配 （小屏幕下面显示跟大屏幕同等量的字体。并且如果使用rem的话，那么由于等比例的存在，在小屏幕下就会存在小屏幕字体更小的情况，不利于我们更好的去阅读，所以，对于字体的适配，更好的做法就是使用px和媒体查询来进行适配）。

  function setHtmlFontSize() {var dpr = window.devicePixelRatio;var pxPercent = doc.documentElement.clientWidth * dpr / 10; // 将页面等分10份doc.documentElement.style.cssText = "font-size:" + pxPercent + "px;";
  }
  var resizeEvt = "orientationchange" in window?"orientationchange":"resize";
  window.addEventListener(resizeEvt, setHtmlFontSize,false);
  window.addEventListener("DOMContentLoaded",setHtmlFontSize,false);
  

  rem与px对应关系，1rem代表在JS中设置的html font-size值（为一块的宽度），px对应占多少块。

  优点：

  • 兼容性比较好；

  • css适配代码少，易于维护。

  缺点：

  • 对于不同dpr处理细节较麻烦；

  • 1px细节问；

  • rem小数点问题，最终css值都是四舍五入的，可能不精准。

  4.5 手淘方案：rem + flexible库

  大致思路：

  • 选择一种尺寸作为设计和开发的基准；

  • 定义一套适配规则，自动适配剩下的尺寸；

  • 特殊适配效果单独处理。

  原理：flexible库其实做了以下3件事：

  • 动态改写标签，动态设置scale缩放比例；

  • 给元素添加data-dpr属性，并动态改写data-dpr的值；

  • 给元素添加font-size属性，并且动态改写font-size的值。

  使用方式和注意事项：

  • 引用flexible_css.js,flexible.js；

  • px转化成rem，由于flexible库将设计图等分成10份，750px设计稿，相当于1rem=7.5px，可以借助less或者scss去转换，获取采用px2rem库统一转换，还可以利用插件，方式很多不一一列举；

  • 字号不用rem用px，通过[data-dpr=”2”]和[data-dpr=”3”]分开设置px单位的字体。同样可以采用less或者sass处理；

  • 利用[data-dpr=”2”] .test，处理不同dpr的场景。

  @function pxToRem($num) {@return ($num/$base) * 1rem;
  }
  div{width:pxToRem(50);height:pxToRem(50);
  }
  

  优点：

  • css适配代码量明显减少；

  • 开发效率高，有成套的解决方案；

  • 1px、2px细节通过缩放方式能够有效解决 。

  缺点：

  • 奇葩Android中dpr为小数情况，导致1px兼容场景兼容不好；

  • 针对不同分辨率、1px、高DPR、倍图等场景，都是通过Hack手段处理，而不是原生css处理，相比纯css处理性能会差点。flexible2.0针对1px场景增加兼容。

  // 进行了精简
  // detect 0.5px supports
  var docEl = document.documentElement;
  if (dpr >= 2) {var fakeBody = document.createElement('body');var testElement = document.createElement('div');testElement.style.border = '.5px solid transparent';fakeBody.appendChild(testElement);docEl.appendChild(fakeBody);if (testElement.offsetHeight === 1) {docEl.classList.add('hairlines')}docEl.removeChild(fakeBody);
  }
  

  4.6 vw + rem

  为了解决纯VW布局不能设置最大最小宽度的问题，我们引入REM。大致思路：

  • 给根元素大小设置随着视口变化而变化的 vw 单位，这样就可以实现动态改变其大小;

  • 限制根元素字体大小的最大最小值，配合 body 加上最大宽度和最小宽度.

  // rem 单位换算：定为 75px方便运算
  $vw_fontsize: 75;
  @function rem($px) {@return ($px / $vw_fontsize ) * 1rem;
  }
  // 根元素大小使用 vw 单位
  $vw_design: 750;
  html {font-size: ($vw_fontsize / ($vw_design / 2)) * 100vw; // 同时，通过Media Queries 限制根元素最大最小值@media screen and (max-width: 320px) {font-size: 64px;}@media screen and (min-width: 540px) {font-size: 108px;}
  }
  // body 也增加最大最小宽度限制，避免默认100%宽度的 block 元素跟随 body 而过大过小
  body {max-width: 540px;min-width: 320px;
  }
  

  优点：

  • 省去js计算font-size、和缩放比例的问题；

  • 原生css处理，性能更好。

  缺点：

  • 兼容性不好，ios8、android4.4以上才完全支持；

  • margin采用px单位，很容易造成整体宽度超过100vw。

  五、思考

  1. PC端的ERP是否也能做到完全自适应呢？

  2. 移动端盛行，ERP或者周边生态是否会衍生移动端项目呢？待续…

  ------ END ------

  作者简介

  罗同学： 研发工程师，目前负责ERP建模平台的设计与开发工作。

  也许您还想看

  从案例角度解析建模平台动态规则引擎

  WEB页面前端性能诊断方法与实践

  前端异步对象的原理与使用方法

  链路追踪在ERP系统中的应用实践