默认缩放比例:
ldpi | mdpi | hdpi | xhdpi | |
---|---|---|---|---|
ppi | 120 | 160 | 240 | 320 |
默认缩放比例 | 0.75 | 1.0 | 1.5 | 2.0 |
手机浏览器默认做了两件事
那么问题来了,为什么会有一个默认的viewport呢?我们知道,pc端页面,在移动端查看的时候,由于像素不匹配,但是为了能够给用户展现一个比较完整的页面,因此会虚拟出一个viewport出来,在此viewprot上渲染页面。也就是说,最终目的,是为了排版正确。但是由于一般默认情况下,给出的viewport像素宽对页面来说是不友好、不规范的,因此我们还需要解决一个规范问题。解决方案:在head中加一个meta标签格式如下:<metaname="viewport"content="name=value, name=value">
<meta name="viewport" content="name=value, name=value">
// name = value 对应关系
width: device-width;
initial: xx; // 设置初始缩放
minimum-scale: xx; // 最小缩放
maxim-scale: xx; // 最大缩放
user-scalable: no; // 用户不可缩放
/* 混合使用flex占比 */
.nav{
display: -webkit-flex;
}
.son1{
flex: 1;
}
.son2{
flex: 3;
}
.son3{
width: 100px;
}
.parent{
justify-content: center;
align-items: center;
display: -webkit-flex;
}
表现如下:
新felx布局 | 旧flexbox布局 |
---|---|
display: -webkit-flex; | display: -webkit-flex-box; |
-weblit-flex: 1; | -weblit-flex-box: 1; |
justify-content: center; | box-pack: center; |
align-items: center; | box-align: cneter |
顾名思义,一套页面,在所有端(pc、超大屏、ipad、手机等)完美运行。随页面宽高变化而改变页面样式,从而适配不同设备。
@media screen and (max-width: 1024px) {
body{
background: #eee;
}
}
@media screen and (max-width: 980px) {
body{
background: green;
}
}
@media screen and (max-width: 720px) {
body{
background: yellow;
}
}
@media screen and (max-width: 640px) {
body{
background: skyblue;
}
}
@media screen and (max-width: 320px) {
body{
background: pink;
}
}
@media screen and (min-width: 1025px) {
body{
background: darkseagreen;
}
}
width: (wvalue / dpr)px height: (hvalue / dpr)px
问题: Retina屏幕下,1像素问题原因: 1px使用2dp渲染解决:
/* 错误案例 */
div{
border-top: 0.5px;
}
/* 正确案例 */
div:before{
border-top: 1px;
-webkit-transform: scaleY(0.5);
position: absolute;
top: -1px;
left: 0;
content: '';
height: 1px;
}
那么,rem的基值设置为多少比较合适呢?回归到开发中来,我们有一个公式:rem=screen.width/x
例:320的屏幕,可以设置为font-size=32px,而375的屏幕,设置为37.5px。我们的目的是为了方便计算。
/* 单行文本溢出*/
.line{
overflow: hidden;
white-space: nowrap;
text-overflow: ellipsis;
}
/* 多行文本溢出 */
.lines{
display: -webkit-box !important;
overflow: hidden;
text-overflow: ellipsis;
word-break: break-all;
-webkit-box-orient: vertical;
-webkit-line-clamp: 2; // 行数
}
在移动端,由于有多重手势操作替代了鼠标操作,因此,为了判断出是点击、双击、触摸移动或者别的手势,iOS系统判断中加了一个300毫秒的延迟:在第一次出发事件300毫秒内再次出发,例如点击,就会被判断为双击。那么为了统一规范,后来在Android系统中也加入了此判定。这就是著名的移动端300ms延迟问题。那么如何解决这个问题呢?tap事件处理。什么是tap事件?简而言之,就是通过touch,监听touchstart和tarchend,如果两者间隔较短,例如100ms甚至更短,且起始位置的偏移量极小,控制在几个像素之内,那么就判定为点击事件。如此操作,可以绕过系统300ms的规范,从而在用户体验上做的更优。但我们只有,一般有利就有弊。我们解决掉300ms延迟问题,从而又产生了一个新的问题,就是穿透问题。例如在按钮上有一个蒙层,我们点击蒙层,关闭其蒙层。但是如果在蒙层下面同样有点击事件,那么我们在点击蒙层关闭后,也会触发到下面的事件。那么这种问题的一般解决方案便是关闭蒙层的时候,添加一个300ms的延时,经过300ms延时关闭后,点击不再具有穿透性,巧妙的解决的该穿透问题。但是问题又来了,300ms延时其实对用户体验来讲并不那么友好。因此还是推荐第一种解决方案,不会出现拆东墙补西墙或者说捉襟见肘的问题。当然,如果使用框架库的话,大部分强大的库默认都解决了这个问题,不用开发者再为此操心。
触摸是移动设备交互的核心事件
事件 | 触发情况 | 备注 |
---|---|---|
touchstart | 手指触摸屏幕触发 | 已有手指放在屏幕上则不触发 |
touchmove | 手指在屏幕上滑动 | 连续触发 |
touchend | 手指离开屏幕时触发 | / |
touchcancel | 系统取消touch时触发 | 不常用 |
在Android中,某些版本只会触发一次touchstart和一次touchmove,不会触发touchend。解决方案则是在事件中(touchmove)添加阻止默认事件:event.preventDefault()
。但与此同时,要注意随之产生的一个问题,就是组织默认事件后,页面也会随之禁止滚动,因此看情况使用。