源宝导读:由于我们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 = 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。
五、思考
PC端的ERP是否也能做到完全自适应呢?
移动端盛行,ERP或者周边生态是否会衍生移动端项目呢?待续…
------ END ------
作者简介
罗同学: 研发工程师,目前负责ERP建模平台的设计与开发工作。
也许您还想看
从案例角度解析建模平台动态规则引擎
WEB页面前端性能诊断方法与实践
前端异步对象的原理与使用方法
链路追踪在ERP系统中的应用实践