移动web

移动web的基础知识（the basic knowledge of mobile web）

·px:css pixels逻辑像素，浏览器使用的抽象单位，根据不一样的设备，会变大或者变小

　　iphone5的分辨率是640*1136（使用的物理像素）。320px*568px(使用的逻辑像素)

·dp,pt:device independent pixels设备无关像素，不会随设备的变化而变化的大小

·dpr：devicePixelRadio设备像素缩放比

 

平面上：1px = 2*2*dp   纬度上：1px = 2*dp   

dp与px之间的关系是经过dpr进行控制的，计算公式为1px = (dpr)*(dpr)*dp。由于iphone5的dpr=2，因此iphone5的分辨率是320px*568px,也能够说是640dp*1136dp。

因此640px*1136px的图片不能在iphone5上彻底展现。

·DPI：打印机每英寸能够喷的墨汁点（印刷行业）

·PPI：屏幕每英寸的像素数量，即单位英寸内的像素密度

在计算机显示设备参数描述上，两者意思表达的都是单位面积内的像素密度。以iphone5为例子进行计算说明

ppi = √(1136²+640²)/4 = 326ppi(视网膜Retina屏)，计算ppi的时候应该用物理像素计算

ppi越高，像素数越高，图像越清晰。但可视度越低（小），系统默认设置缩放比越大（好比：pc的分辨率越高，则桌面上的icon越小）

表1

ppi 默认缩放比	ldpi	mdpi	hdpi	xhdpi
	120	160	240	320
	0.75	1.0	1.5	2.0

Retina屏（高清屏）：dpr都是大于等于2

以iphone5为例设备分辨率转为像素分辨率：官方指导iphone5的设备分辨率为1136*640dp,根据公式获得其为326ppi，326ppi属于retina高清屏，根据表1获得默认缩放比dpr=2，再根据公式1px = dpr²*dp获得iphone5的屏幕为320*568px

·Viewport

pc端的页面会把整个页面渲染在移动端的一个viewport里面，来保证能够在移动端看到页面的全貌。

ios的viewport广泛为980px，安卓的viewport可能有640px,1000px,1200px等等

手机浏览器默认为咱们作了两件事情：

　　一 页面渲染在一个980px(ios)的viewport中

　　二 页面渲染在viewport中后，进行缩放。

　　这样作的目的能够防止屏幕太小时排版的混乱，因此在pc页面在移动端进行渲染时，虚拟了一个viewport来保证排版的正确。

viewport能够细分为两层，一层是visual viewport(视图viewport,控制窗口缩放的大小),一层是layout viewport(布局viewport,这个viewport就指的移动端浏览器默认的viewport，如ios的980px)

设计移动web通常不使用默认的980px布局的viewport，缘由有如下几点：

　　1，宽度不可控制，不一样系统不一样设备的默认值均可能不一样

　　2，页面缩小版显示，交互不友好

　　3，连接有时不可点

　　4，有缩放，缩放后有滚动

　　5，font-size为40px才等于PC上的12px同等物理大小，不规范

可使用meta标签改变默认的viewport

·meta标签

<meta name="viewport" content="width=device-width,initial-scale=1.0"> 保证默认viewport的宽度始终等于设备宽度

　　width:设置布局viewport的特定值（“device-width”）

　　inital-scale:设置页面的初始缩放

　　minimum-scale:最少缩放

　　maximum-scale:最大缩放

　　user-scalable:用户可否缩放

 　　移动页面的最佳设计比为：布局viewport = 设备宽度 = 度量viewport。所以meta标签最佳设置为

　　<meta name='viewport' content='width=device-width,initial-scale=1,user-scalable=no'

 ·设计移动web

　　方案一：根据设备的实际宽度来设计（经常使用）

　　　　　　手机宽320px，就拿320px设计

　　方案二：1px = 1dp

　　　　　　缩放0.5，根据设备的物理像素dp等于抽象像素px来设计。1px边框和高清图片都不须要额外处理

 

高效的移动web布局（efficient mobile CSS layout）

PC端的页面常使用的两种布局为固定布局和流体布局，其中固定布局占主导。

可是移动端页面没法使用固定布局，由于移动设备的屏幕及分辨率很是多，因此在移动端常用响应式布局及flex弹性布局。

·使用flex弹性盒子布局，实现根据元素个数不一样，自动填充容器，如下是flexbox的几种经常使用布局模式

　　flex等比划分

　　　　父容器 display:-webkit-flex   子容器1  flex:1(等比占1/3)    子容器2  flex:2(等比占2/3)

　　flex混合划分

　　　　父容器 display:-webkit-flex   子容器1  flex:1(等比占1/3)    子容器2  flex:2(等比占2/3)   子容器3  width:100px;

　　　　这种布局方式在移动web的应用场景更加普遍，好比图文混合的状况，通常图片为了保证清晰度不宜放大，因此图片采起固定宽度，而文字则能够根据容器的大小而变化

　　不定宽高的水平垂直居中

　　　　父容器  { display:-webkit-flex;justify-content:center;align-items:center}

 flex兼容性

　　1，ios可使用最新的flex布局；2，android4.4一下，只能兼容旧的flex布局；3，android4.4以上，可使用最新的flex布局

·响应式设计

 　　使用百分比布局

　　　　仅仅使用媒体查询来适应不一样的固定宽度设计，只会从一组css到另外一组css的切换。两种之间的没有任何平滑渐变（好比使用media为iphone和ipad air都设置了样式，可是两者之间的ipad mini没有设置样式，这样会致使ipad mini上的样式错乱）

 　　 弹性图片

　　　　图片也使用百分比，不管什么状况下，都全包在图片的元素宽度范围内，以最大的宽度同比完整的显示图片。如img{max-width:100%}

　　 从新布局，显示与隐藏

　　　　当页面达到手机屏幕宽度的时候，不少时候就要放弃一些传统的页面设计思想。尽可能保证页面的简单、整洁。能够采起下述方法进行处理

　　　　1,同比缩小元素的尺寸；2，调整页面结构布局；3，隐藏冗余的元素；

　　常常须要切换位置的元素使用绝对定位，减小重绘，提升渲染性能

　　响应式的利弊

　　　　1，根据响应式的设计理念，一个页面包含全部设备不一样屏幕的样式和图片，当一个移动设备访问一个响应式的页面，就会下载PC、ipad、iphone等不一样设备对应的样式，而这些样式倒是冗余的，没有必要的。

　　　　2，虽然响应式的设计性能不是最优的，可是却能够减小重复开发，一个样式同时适配多端。

·移动web特别样式处理

　　高清图片

　　　　好比100px*100px的图片在Retina屏幕上渲染，则是在200dp*200dp的屏幕上渲染的，因此会拉大。因此在移动web页面上渲染图片，为了不图片产生模糊，图片的宽高应该用物理像素单位渲染，便是100*100的图片，应该使用100dp*100dp

　　　　width:(w_value/dpr)px;  height:(h_value/dpr)px

　　一像素边框

　　　　Retina屏幕下的问题，根本缘由是border:1px使用2dp进行渲染

　　　　因为border:0.5px的这种解决方式在安卓上不适用，因此通常能够采用scale(0.5)进行一下缩放

·相对单位rem

　　为了适应各大屏幕的手机，px不能根据尺寸的大小而改变，使用相对单位更能体验页面兼容性

　　em:根据父节点的font-size为相对单位；这个单位在多层嵌套下，会变得很困难

　　rem:根据html的font-size为相对单位；这个单位更加能做为全局统一设置的度量

　　为了适应各大手机屏幕，rem的基值设置为rem=screen.width/20

　　html{font-size:32px}  iphone5

　　@media (min-device-width:375px){html{font-size:37.5px}}   iphone6

　　@media (min-device-width:414px){html{font-size:41.4px}}   iphone6 plus

　　通常font-size不使用rem等相对单位做为单位，由于字体的大小是趋于阅读的实用性的，并不适合于排版布局。

·多行文本溢出

　　单行文本溢出 .inaline{overflow:hidden;white-space:nowrap;text-overflow:ellipsis;}

　　多行文本溢出 .inmoreline{display:-webkit-box!important;overflow:hidden;text-overflow:ellipsis;word-break:break-all;-webkit-box-orient:vertical;-webkit-line-clamp:3;} -webkit-line-clamp的值表示在第几行用“...”表示溢出

终端交互优化(interactive optimization in mobile web）

　　移动web页面上的click事件响应都要慢上300ms。是由于移动设备访问的web页面都是pc上的页面，在默认viewport(980px)的页面每每都是须要“双击”或“捏开”放大页面以看清页面。而正是为了确认用户是“双击”仍是“单击”。safari须要个300ms的延迟来判断，然后来的iphone也一直延续这种设计，而借鉴iphone的android也沿用这样的设计。因而“300ms的延迟”成为了一道规范。

　　使用tap事件代替移动web中的click事件。使用touch事件进行模拟。

　　tap事件在移动端的点透的bug，这个bug和300ms的延迟有关

　　　　移动端click事件的触发过程：touchstart,touchend....300ms......click触发

　　　　移动端点透发生的过程：touchstart致使蒙层消失,touchend冒泡到btn上.....300ms.....btn的click触发

　　tap透传的解决方案

　　　　1，使用缓动动画，过渡300ms的延迟

　　　　2，中间层dom元素的加入，让中间层接受这个‘穿透’事件，稍后隐藏

　　　　3，‘上下’都使用tap事件，原理上解决tap透传事件（但不可避免原生标签的click事件，好比<a>）

　　　　4，使用fastclick库或者最新的zepto

Touch基础事件的经常使用属性

　　-touches:跟踪触摸操做的touch对象数组

　　-targetTouches:特定事件目标的touch对象数组

　　-changeTouches:上次触摸改变的touch对象数组

var touchHandler = function(e){ var type = e.type; //touchend的touches和targetTouches为空，
　if(type !== 'touchend'){ 　　var pos = { 　　　　x:e.touches[0].clientX, 　　　　y:e.touches[0].clientY 　　} 　　switch(type){ 　　　　case 'touchstart':break; 　　　　case 'touchmove':event.preventDefault();break;//安卓4.4.4.0的bug，只触发touchstart,和一次touchmove,touchend不触发。加入preventDefault会解决这个bug，可是会致使阻止默认事件，好比scroll,致使页面不滚动。
　　　　case 'touchend':break; 　　} 　} }

touch.js

var touch = { startX: 0, startY: 0, endX: 0, endY: 0, touchStart: function (event) { var touchPoint = event.touches[0]; this.startX = touchPoint.pageX this.startY = touchPoint.pageY this.endX = 0
        this.endY = 0 }, touchMove: function (event) { var touchPoint = event.touches[0]; endX = touchPoint.pageX endY = touchPoint.pageY }, isSwipe: function (strX, endX, strY, endY) { var flag = false; if (endX && endY) { flag = Math.abs(endX - strX) > 80 || Math.abs(endY - strY) > 80 } return flag; }, swipeDirection: function (strX, endX, strY, endY) { var swipeDirection = Math.abs(endX - strX) > Math.abs(endY - strY) ? ((endX - strX) > 0 ? "Right" : "Left") : ((endY - strY) > 0 ? "Down" : "Up"); return swipeDirection.toString(); } }; var touchEvents = { touchstart: "touchstart", touchmove: "touchmove", touchend: "touchend", /** * @desc:判断是否pc设备，如果pc，须要更改touch事件为鼠标事件，不然默认触摸事件 */ initTouchEvents: function () { if (!isAppBrowser()) { this.touchstart = "mousedown"; this.touchmove = "mousemove"; this.touchend = "mouseup"; } } }; function isAppBrowser() { var userAgentInfo = navigator.userAgent; var Agents = ["Android", "iPhone", "SymbianOS", "Windows Phone", "iPad", "iPod"]; var isAppBrowser = false; for (var v = 0; v < Agents.length; v++) { if (userAgentInfo.indexOf(Agents[v]) > 0) { isAppBrowser = true; break; } } return isAppBrowser; }

移动web效果之弹性滚动

当客户端的页面滚动到顶部或者底部的时候，滚动条会收缩并让咱们多滑动必定距离。经过缓冲反弹的效果，带给用户良好的体验。这种效果通常在原生APP中出现，移动web页面也能够作到，但滚动有几种状况须要考虑：

　　-body层滚动：（系统特殊化处理）自带弹性滚动，overflow：hidden失效，GIF和定时器暂停

　　-局部滚动：没有弹性滚动，没有滚动惯性，不流畅

　　　　局部滚动开启弹性滚动方法：body{overflow:scroll;-webkit-overflow-scrolling:touch;}。可是android不支持原生的弹性滚动，即上述样式没有生效，能够借助第三方库iScroll来实现。

移动web效果之下拉刷新

顶端下拉一小点的距离，页面弹性滚动向下

移动web效果之上拉加载

使用scroll事件，而不是touch事件（android有bug）