一、背景
现在市场上移动设备的屏幕尺寸、分辨率、屏幕密度等因素各式各样,尽可能做到所有设备都自适应,只用一套样式布局来适配所有设备。
二、适配最终效果
- 在不同分辨率的手机上,页面整体布局自适应,不会出现页面的情况;
- 在不同分辨率的手机上,字体、宽高、间距、图片大小能够和高保真近视一致。
三、移动端相关的知识点
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。
五、思考
- PC端的ERP是否也能做到完全自适应呢?
- 移动端盛行,ERP或者周边生态是否会衍生移动端项目呢?待续…