iphone5
640 X 1136 物理像素
320 X 568 逻辑像素
px: Css pixels逻辑像素,浏览器使用的抽象单位
dp,pt: devide independent pixels设备无关像素物理像素固定
dpr: devidePixelRatio 设备像素缩放比
计算公式: 1 px = (dpr)^2 X dp
为什么iphone5是320px X 568px*?
一> 因为dpr = 2
平面上:1px = (2)^2 X dp
纬度上:1px = 2 X dp
—> 640dp X 1136 dp
= 320px X 568px
DPI: 打印机每英寸可以喷的墨汁点(印刷行业)
PPI: 屏幕每英寸的像素数量,即单位英寸内的像素密度
目前,在计算机显示设备参数描述上,二者意思表达的是一样的。
计算公式:以iphone5(4英寸)为例子
ppi = √(1136^2 + 640^2) / 4 = 326 ppi (视网膜Retina屏)
注意:单位为硬件像素,非px
PPI越高,像素数越高,图像越清晰
但可视度越低(小),系统默认设置缩放比越高(大)
ldpi | mdpi | hdpi | xhdpi | |
---|---|---|---|---|
默认缩放比dpr | 0.75 | 1.0 | 1.5 | 2.0 |
Retina屏(高清屏): | dpr都是大于等于2 |
手机浏览器默认为我们做了两件事情
一:页面渲染在一个980px(ios)的viewport
二:缩放
为什么渲染时,要有viewport?
—>为了排版正确
visual viewport (度量/视口)
== 窗口缩放salce
<meta name = '"viewport" content ="width = devide - width">
window,innerWidth //…[visual` viewport](会窗口变化)
screen.width //….[屏幕宽度](固定值)
layout viewport (布局viewport)
body{width:320px}
document.body.clientWidth //…[layout viewport]
注意:指,layout viewport,不是原页面的大小,
如:ios默认viewport是980px
window,innerWidth / document.body.clientWidth //1…(默认缩放比dpr)
为什么不使用默认的980px的布局viewport
-
宽度不可控制,不同系统不同设备的默认值都可能不同
-
页面缩小版显示,交互不友好
-
链接点不可点
- 有缩放,缩放后又有滚动
移动font-size为40px等于PC上12px同等物理大小,不规范
3.Viewport_Meta 标签<meta name = '"viewport" content ="name = value, name = value">
- width - viewport的宽度[pixel_value |device-width]
- height - viewport的高度[pixel_value |device-height]
- initial-scale - 初始的缩放比例[float_value]
- maximum-scale - 允许用户缩放到的最大比例
- minimum- scale (/scalbujue) - 允许用户的最小缩放值
- user-scalable - 用户是否可以手动缩放 [yes | no]
<meta name = '"viewport" content =" width = 320"> <meta name = '"viewport" content =" width = devide - width">
width = devide – width ——> layout viewport = 设备宽度
<meta name = "viewport" content ="initial - scale = 1.0">
initial – scale自带width = devide – width ——> 度量viewport = 布局viewport
移动web最佳viewport设置
<meta name = '"viewport" content =" width = devide - width, initial - scale = 1,user – scale = no">
4.Viewport_coding布局viewport = 度量viewport = 设备宽度
Viewport
方案一:根据设备的移动宽度来设计(常用)
手机宽度320px,我们就拿320px设计。
方案二:1px=1dp
缩放0.5。根据设备的物理像素dp等于抽象像素px来设计。1px边框和高清图片都不需要额外处理。
二.高效的移动Web布局 1.Flexbox弹性盒子布局根据元素个数不同,自动填充容器
.nav {…; display: -webkit-flex; / *display: -webkit-flex 标示使用弹性布局*/}
.item {…; flex:1 /**flex: num 占容器的比例/}
Flex等比划分
.item1 {…; flex:1} /*/占容器1/(1+2) */
.item2 {…; flex:2} /*占容器2/(1+2) */
Flex混合划分
.item1 {…; width: 100px} /*占容器100px 多用于图片*/
.item2 {…; flex:2} /占容器2/(100%-100px) 多用于文字*/
.item3 {…; flex:1} /占容器1/(100%-100px) 多用于文字*/
在移动web的应用场景更加广泛
不定宽高的水平垂直居中
.myoff_wrapper
{
position: absolute;
top: 50px;
left: 50px;
z-index: 3;
-webkit-transform: translate(-50%, -50%);
border-radius: 6px;
background: #fff;
}
【Flexbox版】不定宽高的水平垂直居中
.parent
{
justify-content: center; /*子元素水平居中*/
display: -webkit-flex;
}
扩展知识
引用:Flex 布局教程:语法篇
作者: 阮一峰
日期: 2015年7月10日
Flex 布局是什么?
Flex 是 Flexible Box 的缩写,意为"弹性布局",用来为盒状模型提供最大的灵活性。
任何一个容器都可以指定为 Flex 布局。
.box{
display: flex;
}
行内元素也可以使用 Flex 布局。
.box{
display: inline-flex;
}
Webkit 内核的浏览器,必须加上-webkit前缀。
.box{
display: -webkit-flex; /* Safari */
display: flex;
}
注意,设为 Flex 布局以后,子元素的float、clear和vertical-align属性将失效。
基本概念
采用 Flex 布局的元素,称为 Flex 容器(flex container),简称"容器"。它的所有子元素自动成为容器成员,称为
Flex 项目(flex item),简称"项目"。容器默认存在两根轴:水平的主轴(main axis)和垂直的交叉轴(cross axis)。
主轴的开始位置(与边框的交叉点)叫做main start,结束位置叫做main end;
交叉轴的开始位置叫做cross start,结束位置叫做cross end。
项目默认沿主轴排列。
单个项目,
占据的主轴空间叫做main size,
占据的交叉轴空间叫做cross size。
容器的属性
以下6个属性设置在容器上。
- flex-direction
- flex-wrap
- flex-flow
- justify-content
- align-items
- align-content
项目的属性
以下6个属性设置在项目上。
2.响应式设计
- order
- flex-grow
- flex-shrink
- flex-basis
- flex
- align-self
兼容性
- ios可以使用最新的flex布局
- android4.4以下,只能兼容旧版的flexbox布局
- android4.4及以上,可以使用最新的flex布局
新flex布局 | 旧flexbox布局 |
---|---|
display:-webkit-flex; | display:-webkit-flex-box; |
-webkit-flex:1; | -webkit-flex-box:1; |
justify-content:center; | box-pack:center; |
align-items:center; | box-align:center; |
媒体查询:
- screen(屏幕)
- print(打印机)
- handheld(手持设备)
- all(通用)
常用媒体查询参数
- width —— 视口宽度
- height —— 视口高度
- devide-width —— 设备的宽度
- devide-height —— 设备的高度
- orientation: 检查设备处于横屏(landscape)还是竖屏(portrait)
设计点一:百分比布局
仅仅使用媒体查询来适应不同的宽度设计,
只会从一组css到另一组css的切换。
两种之间的没有任何平滑渐变。
当没有命中媒体查询时,
表现就会变得不可控制(滚动,换行)。
设计点二:弹性图片
<div class="img"><img scr="xxx.jpg"/></div>
.img{max-width:100%;}
无论何时,都全包在图片的元素宽度范围内,
以最大的宽度同比完整的显示图片。
设计点三:重新布局,显示和隐藏
当页面达到手机屏幕宽度的时候,
很多时候就要放弃一些传统的页面设计思想。
力求页面简单,简洁。
- 同比例缩减元素尺寸
- 调整页面结构布局
- 隐藏冗(rong3)余的元素
经常需要切换位置元素使用【绝对定位】,
减少重绘画提高渲染性能。
关于响应式设计的思考
根据响应式设计的理念,
一个页面包含所有设备不同屏幕的样式和图片,
当一个移动设备访问一个响应式的页面,
就会下载PC,笔记本,ipad等不同设备对应的样式。
而这些样式却是冗余的,完全没有用。
权衡利弊
- 弊:性能不是最优。
- 利:减少重复开发 3.移动Web特别样式处理
高清图片
在移动web页面上渲染图片,为了避免图片产生模糊,
图片的宽高应该用物理像素定位渲染,即100 X 100的图片,
应该所有100dp X 100dp。
width:(w_value/dpr)px;
height:(h_value/dpr)px;
一像素边框
同样是retina屏幕下的问题,
根本原因: 1px使用2dp渲染。
border:0.5px /不可用!仅仅ios8可以用/
正确用法: sacleY(.5)
.sidebar .folder li {
/*border-top: 0.5px solid #ddd;*/
padding: 8px 0 8px 15px;
color: #7c7c7c;
position: relative;
}
.folder li+li:before {
position: absolute;
top: -1px;
left: 0;
content: " ";
width;100%;
height:1px;
border-top:1px solid #ddd;
-webkit-transform:scaleY(.5);
}
相对单位rem
为了适应各大屏幕的手机,px略显固定,
不能根据尺寸的大小而改变,
使用相对单位更能体验页面即时性。
- em:是根据父节点的font-size为相对单位
- rem:是根据html的font-size为相对单位
em在多层嵌套下,变得非常难以使用
rem更加能作为全局统一设置的度量
rem的基值设置多少好?
回归我们的目的:为了适应各大手机屏幕
rem = screen.width / 20; (screen.width / 10)
/*默认320px; 320px/10*/
html{font-size: 32px;}
/*iphone 6*/
@media (min-devide-width: 375px) {
html{font-size: 37.5px;}
}
/*iphone 6 plus*/
@media (min-devide-width: 414px) {
html{font-size: 41.4px;}
}
如(iphone5)html:32px;(rem基值)—— div:64px 64px;—— 2rem 2rem
换算公式:width:px/rem基值;height:px/rem基值。
不使用rem的情况:font-size
一般来讲font-size是不应该使用rem等相对单位的。
因为字体的大小是趋向于阅读的实用性,
并不适合于排版布局。
同理趋向于一些固定的元素的特性。
我们不使用rem而改为使用px去确保
在不用屏幕上表现一致(跟rem的目的相反)。
多行文本溢出…
/*单行文本溢出…*/
.inaline {
overflow: hidden;
white-space: nowrap;
text-overflow: ellipsis(省略);
}
/*多行文本溢出…*/
.intwoline {
display: -webkit-box !portant;
overflow: hidden;
text-overflow: ellipsis;
word-break: break-all;
-webkit-box-orient: vertial;
-webkit-line-clamp: 2; /*显示行数*/
}
单行文本溢出,对title类的使用非常多,
而多行文本溢出,在详情介绍则用的比较多。
在移动设备上没有了鼠标输入,
hover等一些鼠标事件不再生效。
取而代之的是更加人性化的触摸事件(touch)。
PC上的惯性思维,是时候要转换一下。
终端交互优化 | |
---|---|
对click事件say no | tap事件基础 |
弹性滚动 | touch触摸事件 |
上拉刷新 | 下拉加载 |
300毫秒的故事
移动web页面上的click事件响应都要慢上300ms。
假定这么一个场景。用户在 iOS Safari 里边点击了一个链接。由于用户可以进行双击缩放或者双击滚动的操作,当用户一次点击屏幕之后,浏览器并不能立刻判断用户是确实要打开这个链接,还是想要进行双击操作。因此,iOS Safari 就等待 300 毫秒,以判断用户是否再次点击了屏幕。
于是,300 毫秒延迟就这么诞生了。
300ms延迟怎么办?
使用Tap事件代替click事件。
自定义Tap事件原理:
在touchstart、touchend是记录时间、手指位置,
在touchend时进行比较,如果手指位置为同一位置
(或允许移动一个非常小的位移值)且时间间隔较短
(一般认为是200ms),且过程未曾触发过touchmove,
即可认为触发了手持设备上的“click”,一般称它为“tap”。
移动框架库Zepto.js****
(按钮)click事件触发过程:
touchstart —— touchend —— 300ms —— click触发
(按钮前加蒙层)点透发生过程:
touchstart —— touchend蒙层消失 —— 300ms —— target为btn,click触发
Tap透传的解决方案
- 使用缓动动画,过渡300ms的延迟
- 中间层dom元素的加入,让中间层接受这个“穿透”事件,稍后隐藏
- “上下”都使用tap事件,原理上解决tap透传事件(但不可避免原生标签的clisk事件)
- 改用Fastclick的库(听说最新的则zepto已经fixed掉这个bug)
- 触摸touch
触摸才是移动设备的交互的核心事件。
touchstart:手指触摸屏幕触发(已经有手指放屏幕上不会触发)。
touchmove:手指在屏幕滑动,连续触发。。
touchend:手指离开屏幕时触发。
touchcancel:系统取消touch时候触发(不常用)。
BUG: Android只会触发一次touchstart,一次touchmove,touchend不触发。
解决方案: 在touchmove中加入:event. preventDefault()可fixedBug。(调用事件可以阻止滚动)
但注意: event.preventDefalut()会导致默认行为不发生,如scroll,导致页面不滚动。
除常见的事件属性外,触摸事件包含专有的触摸属性(用于跟踪触摸)。
touches:跟踪触摸操作的touch对象数组
targetTouches:特定事件目标的touch对象数组
changeTouches:上次触摸改变的touch对象数组
每个touch对象包含属性:
clientX:触摸目标在视口中的x坐标。
clientY:触摸目标在视口中的y坐标。
identifier:标识触摸的唯一ID。
pageX:触摸目标在页面中的x坐标。
pageY:触摸目标在页面中的y坐标。
screenX:触摸目标在屏幕中的x坐标。
screenY:触摸目标在屏幕中的y坐标。
target:触目的DOM节点目标。
bubbles(起泡事件的类型)
cancelable(是否用 preventDefault() 方法可以取消与事件关联的默认动作)
根据touch对象跟踪触摸具体位置,从而判断触摸交互或手势事件。
弹性滚动
当客户端的页面滚动到顶部或底部的时候,
滚动条会收缩并让我们多滑动一些距离。
通过缓冲反弹的效果,带给用户良好的体验。
移动web页面也是拥有这样的能力的,
但滚动有几种情况需要考虑:
body层滚动:(系统特殊化处理)
自带弹性滚动,
overflow:hidden失效,
GIF和定时器暂停。
局部滚动:
没有弹性滚动,没有滚动惯性,不流畅。
局部滚动开启弹性滚动:
body {
overflow: scroll;
-webkit-overflow-csrolling: touch;
}
注意Andriod不支持原生的弹性滚动!
但可以借助第三方库iScroll来实现。
下拉刷新
顶部下拉一小距离,页面弹性滚动向下。
上拉加载
使用scroll事件而不是touch事件(andriod有bug)
略
共同学习,写下你的评论
评论加载中...
作者其他优质文章