Web页面适配移动端方案研究

最新推荐文章于 2024-05-01 00:35:14 发布

dotNET跨平台

最新推荐文章于 2024-05-01 00:35:14 发布

阅读量460

点赞数

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

一、背景

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

二、适配最终效果

在不同分辨率的手机上，页面整体布局自适应，不会出现页面的情况；
在不同分辨率的手机上，字体、宽高、间距、图片大小能够和高保真近视一致。

三、移动端相关的知识点

3.1 关于设备

屏幕的像素：物理设备的显示屏最小组成单位，又称物理像素，是由物理设备决定的，出厂时就确定了；
屏幕的尺寸：屏幕对角线的长度，单位是英寸，1英寸（inch）=2.54厘米（cm）；
屏幕的分辨率：例如：1366px768px的分辨率，意思就是屏幕上横向设置了768个像素，竖向设置了1366个像素。假设你调节分辨率为800600，那么多余的像素块会被系统分配相邻的近视色块占据，看起来就放大了，也模糊了；
屏幕的密度：PPI为屏幕每英寸的像素数量，可以理解为一个屏幕对角线长度为1英寸的正方形内所拥有的像素数，用于度量计算机显示屏上像素的密度。

公式：

3.2 关于编码

css像素：是一个相对单位，用来度量web页面上面的内容，与设备像素无关，在标准屏幕密度下，1px对应1个设备像素，但是在现在主流手机上1px并不等于设备的1px；
dpr：设备像素比，定义物理像素和设备虚拟像素（可以理解为css像素）的对应关系。可以通过js获取，dpr = window.devicePixelRatio = 设备像素 / CSS像素。

上图说明了1px在不同dpr时等于几个物理像素。1px对应物理像素除了和屏幕像素密度dpr有关，还和用户缩放有关系。当用户把页面放大一倍，那么CSS中1px所代表的物理像素也会增加一倍；
反之把页面缩小一倍，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 = 750
  var deviceWidth = window.screen.width;
  // Device_Dpi为系统的DPI
  //如果获取系统DPI失败，采用固定值，有一个屏幕宽度对应DPI的标准表，如:Width<320，Dpi = 120
  var 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系统中的应用实践