1、像素和物理像素
iphone5：320*568px（像素）=》640*1136px（物理像素）
2、viewport
手机浏览器默认为我们做了两件事情
1）页面渲染在一个980px（ios）的viewport：为了排版正确
2）缩放
3、Meta标签
不使用默认的viewport
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">
width=device-width：布局viewport宽度=设备宽度
4、在手淘的设计师和前端开发协作过程中：手淘设计师常选择iPhone6作为基准设计尺寸，交付给前端的设计尺寸是按750px * 1334px为准(高度会随着内容多少而改变)。前端开发人员通过一套适配规则自动适配到其他的尺寸。
5、flex布局（带上-webkit-前缀适配不兼容的手机）
1）父容器：display:flex;display:-webkit-flex;
子容器：flex:1;-webkit-flex:1;（按比例划分）
2）不定宽高元素水平垂直居中
父容器：display:flex;align-items:center;（子元素垂直居中）justify-content:center;（子元素水平居中）
6、响应式布局
1）@media媒体查询
使用 @media 查询，你可以针对不同的媒体类型定义不同的样式。@media 可以针对不同的屏幕尺寸设置不同的样式，当你重置浏览器大小的过程中，页面也会根据浏览器的宽度和高度重新渲染页面。
2）百分比
3）重新布局，显示与隐藏
当页面达到手机屏幕宽度时，力求页面简洁
3.1）同比例缩减元素尺寸
3.2）调整页面结构布局
3.3）隐藏冗余的元素
4）当一个移动设备访问一个响应式的页面，就会下载pc、笔记本、ipad等不同设备对应的样式。而这些样式却是冗余的，没有考虑移动端的网络优化。
7、移动web特别样式处理
1）高清图片问题
在移动web页面渲染图片，为了避免图片产生模糊，图片的宽高应该用物理像素单位渲染，即是 100 * 100 的图片，应该使用100dp * 100dp。在Retina屏幕，一个px等于两个dp，那你拿 100px*100px 实际上是拿了 200dp * 200dp 物理像素去渲染，图片就会被拉大被模糊。
2）一像素边框
一像素的边框的问题其实最根本的问题还是Retina屏幕的问题，那我们设置了border:1px，那1px就等于2个dp，那它实际上这个1像素边框拿了2个dp来渲染，所以那条线就不是很细。
设置border:0.5px？答案是不可以的，因为它仅仅是ios8可以用。实际上更通用的方案是使用scaleY(0.5)来进行缩放处理
3）相对单位
为了适应各大屏幕的手机，px略显固定，不能根据尺寸的大小而改变，使用相对单位更能体验页面的兼容性。相对单位有两个：
em：是根据父节点的font-size为相对单位
rem：是根据html的font-size为相对单位
em在多层嵌套下，变得非常难以使用和维护了，rem更加能作为全局统一设置的度量，我们推荐使用rem。
rem的基值设置多少好？回归我们的目的：为了适应各大手机屏幕，我们可以这样： rem = screen.width / 20 ，或者除以10等。
/* 默认320px */ html{ font-size: 32px; } /* iphone6 */ @media (min-device-wdith : 375px) { html{font-size: 37.5px;} } /* ihpone6 plus */ @media (min-device-width : 414px) { html{font-size: 41.4px;} }
不使用rem的情况：font-size
一般来讲font-size是并不应该使用rem等相对单位的。因为字体的大小是趋于阅读的实用性，并不适合于排版布局。同理，趋向于一些固定的元素的特性，我们不使用rem而改为使用px去确保在不同的屏幕上表现一致（跟rem的目的相反）。
4）单行文本溢出，对title类的使用非常多，而多行文本类，在详情介绍则用的比较多。
.box{ /*多行文本溢出(目前仅支持webkit内核浏览器)*/ width: 200px; display: -webkit-box; -webkit-box-orient:vertical; -webkit-line-clamp: 4; /*这几个属性都得带上-webkit前缀-*/ overflow: hidden; /*-webkit-line-clamp:限制在一个块元素显示的文本的行数。 它是一个不规范的属性，还没有出现在 CSS 规范草案中*/ /*单行文本溢出*/ /*overflow: hidden; white-space: nowrap; text-overflow: ellipsis;*/ }
8、终端交互优化
1）移动web页面上的click事件响应要慢上300ms。
2007年苹果发布首款iphone上IOS系统搭载的safari为了将适用于PC端上大屏幕的网页能比较好的展示在手机端上，使用了双击缩放(double tap to zoom)的方案，比如你在手机上用浏览器打开一个PC上的网页，你可能在看到页面内容虽然可以撑满整个屏幕，但是字体、图片都很小看不清，此时可以快速双击屏幕上的某一部分，你就能看清该部分放大后的内容，再次双击后能回到原始状态。
原因就出在浏览器需要如何判断快速点击上，当用户在屏幕上单击某一个元素时候，例如跳转链接，此处浏览器会先捕获该次单击，但浏览器不能决定用户是单纯要点击链接还是要双击该部分区域进行缩放操作，所以，捕获第一次单击后，浏览器会先Hold一段时间t，如果在t时间区间里用户未进行下一次点击，则浏览器会做单击跳转链接的处理，如果t时间里用户进行了第二次单击操作，则浏览器会禁止跳转，转而进行对该部分区域页面的缩放操作。那么这个时间区间t有多少呢？在IOS safari下，大概为300毫秒。这就是延迟的由来。造成的后果用户纯粹单击页面，页面需要过一段时间才响应，给用户慢体验感觉，对于web开发者来说是，页面js捕获click事件的回调函数处理，需要300ms后才生效，也就间接导致影响其他业务逻辑的处理。
解决方案：使用tap事件代替click事件。在touchstart、touchend时记录时间、手指位置，在touchend时进行比较，如果手指位置为同一位置（或允许移动非常小的位移值）且时间间隔较短，即为tap。
2）tap事件点透
zepto的tap事件是通过兼听绑定在document上的touch事件来完成tap事件的模拟的，并且tap事件是冒泡到document上触发的。然而用户在touchstart和touchend时会触发click事件，但是此时click事件处于延时300ms，如果在这300ms之内tap事件已经完成，将上层元素删除或隐藏。在300ms到来之际，下层事件被执行，出现穿透现象。如果下层是input元素，即使没有绑定click事件，由于其默认聚焦弹出键盘，穿透现象尤为严重。
解决方案：1）使用缓动动画，过渡300ms的延迟
2）“上下”都使用tap事件（不可避免原生标签的click事件）
3）fastclick库
9，1）弹性滚动
-webkit-overflow-scrolling: touch; /* 当手指从触摸屏上移开，会保持一段时间的滚动 */
2）下拉刷新（touch）
3）上拉加载（scroll）