移动端基础和常见问题

常见的移动端基础和问题

1. 移动端适配
2. 移动端布局
3. touch事件
4. 300ms延迟
5. 点击穿透

---

1.移动端适配

移动端 vs PC端区别:

1.css像素和物理像素：

物理像素 : 他是显示设备上一个最微小的物理显示单元。不同的物理设备的物理像素的大小是不一样的。这是厂商在出厂时就设置好了的，即一个设备的分辨率是固定的

css像素 ： CSS中的像素只是一个抽象的单位。主要使用在浏览器上。在不同的设备中，CSS中的1px所代表的设备物理像素是不同的。

PC端布局，css的1px = 1个物理像素。比例 1 ：1。

pc端，因为屏幕足够大，一个css像素用一个物理像素来显示，完全可以，pc端默认情况下一个css像素就对应着一个物理像素

---

移动端布局：css的1px = n个物理像素。比例 1：n。 也就是说，不同的移动设备，css定义1px，展示出来的效果可能会千差万别。

2.移动设备视窗概念

visual viewport 是当前可视区域的大小

layout viewport : 浏览器的初始视窗大小和浏览器厂商有关

等比例缩放：是浏览器的特性。移动设备打开PC网页，浏览器会将页面内容缩放到移动设备visual viewport的可视区内

ideal viewport ：是希望网页在任何分辨率下，都可以完美的呈现给用户，ideal viewport并没有一个固定的尺寸，不同的设备拥有有不同的ideal viewport。可以通过meta标签控制

3. 利用meta标签对viewport进行控制

4.Flex布局

使用flex布局的容器（flex container），它内部的元素自动成为flex项目（flex item）。

容器默认存在两根轴：水平的主轴（main axis）和垂直的交叉轴（cross axis）。主轴的开始位置（与边框的交叉点）叫做main start，结束位置叫做main end；交叉轴的开始位置叫做cross start，结束位置叫做cross end。

item按主轴或交叉轴排列，单个item在主轴方向上占据的宽度称为main size，在交叉轴方向上占据的宽度称为cross size。

flex-direction属性 : 属性决定主轴的方向（即项目的排列方向）

关于 Flex布局 。可以查阅这篇博文，写得很棒：30分钟彻底弄懂flex布局

媒体查询

媒体查询就是根据，监控不同设备的分辨率来使用不同的CSS样式。需要使用meta标签配合
1、布局特点：每个屏幕分辨率下面会有一个布局样式，即元素位置和大小都会变。
缺点：
（1）媒体查询是有限的，也就是可以枚举出来的，只能适应主流的宽高。
（2）要匹配足够多的屏幕大小，工作量不小，设计也需要多个版本。

rem适配方案

rem是根据 html 的font-size大小来变化，正是基于这个出发，我们可以在每一个设备下根据设备的宽度设置对应的html字号，从而实现了自适应布局。
默认情况下页面 的font-size是16px。 所以 默认情况下 1rem = 16px。
一般都是通过JS动态的设置页面的font-size大小。配合CSS预处理器

---

touch事件

touch事件的几个API

上面的这些事件都会冒泡，也都可以取消

触摸事件还包含下面三个用于跟踪触摸的属性：

touches：存储当前位于屏幕上的所有手指触摸点的一个数组。
targetTouches：存储正在触摸当前 DOM 元素上的手指的一个数组。
changeTouches：表示自上次触摸以来发生了什么改变的，Touch对象的数组。

一般使用targetTouches。因为只关心特定DOM元素的触发。

每个Touch对象包含下列属性：

clientX:触摸目标在视口中的x坐标。
clientY：触摸目标在视口中的y坐标。
identifier:标识触摸的唯一ID。
pageX：触摸目标在页面中的x坐标。
pageY：触摸目标在页面中的y坐标。
screenX：触摸目标在屏幕中的x坐标。
screenY：触摸目标在屏幕中的y坐标。
target：触摸的DOM节点目标。

---

300ms延迟

问题由来
这要追溯至 2007 年初。苹果公司在发布首款 iPhone 前夕，遇到一个问题：当时的网站都是为大屏幕设备所设计的。于是苹果的工程师们做了一些约定，应对 iPhone 这种小屏幕浏览桌面端站点的问题。

这当中最出名的，当属双击缩放(double tap to zoom)，这也是会有上述 300 毫秒延迟的主要原因。

双击缩放，顾名思义，即用手指在屏幕上快速点击两次，iOS 自带的 Safari 浏览器会将网页缩放至原始比例。 那么这和 300 毫秒延迟有什么联系呢？ 假定这么一个场景。用户在 iOS Safari 里边点击了一个链接。
由于用户可以进行双击缩放或者双击滚动的操作，当用户一次点击屏幕之后，浏览器并不能立刻判断用户是确实要打开这个链接，还是想要进行双击操作。因此，iOS Safari 就等待 300 毫秒，以判断用户是否再次点击了屏幕。 
鉴于iPhone的成功，其他移动浏览器都复制了 iPhone Safari 浏览器的多数约定，包括双击缩放，几乎现在所有的移动端浏览器都有这个功能。
之前人们刚刚接触移动端的页面，在欣喜的时候往往不会care这个300ms的延时问题，可是如今touch端界面如雨后春笋，用户对体验的要求也更高，这300ms带来的卡顿慢慢变得让人难以接受。

当我们点击屏幕之后，浏览器会有300ms的延迟来判断我们是否还有下一次点击。如果没有浏览器会认为是单机操作。反之300ms之内又一次点击，浏览器会认为是双击操作，会把页面放大。

解决方案

点击穿透

点击穿透跟300ms延迟有一定关系。详细可看别的博文：点击查看