移动端 移动自适应 移动端meta元标签
【前言】2019.9.19
【内容】 移动端 移动自适应 移动端meta元标签…
（1）浏览器的默认字体大小：16px
（2）chrome字体最小限制：12px
（3）CSS单位分为绝对单位和相对单位
CSS中，单位分为两类
（1）绝对单位：无论其他相关的设置怎么变化，绝对单位指定的值是不会变化的；
（2）相对单位：没有固定的度量值，是由其他元素尺寸来决定的相对值。
CSS绝对单位
CSS相对单位
CSS单位浏览器兼容性
默认计算方式
浏览器的默认字体大小都是16px，所以1em=16px，那么10px=0.625em
继承性
em是一个相对的单位，是当前元素相对于当前对象字体的大小而言的；
例如：父元素设置font-size: 32px ，子元素设置font-size: 1em ，那么子元素的字体大小也是32px。如果父元素没有设置字体大小的话，就是想对于浏览器默认的字体大小而言的
一般宽泛的讲是相对于父元素，但是并不是十分准确，分为以下几种情况。
①对于普通定位元素就是我们理解的父元素
②对于position: absolute;的元素是相对于已定位的父元素
③对于position: fixed;的元素是相对于ViewPort（可视窗口)
ex 和ch 单位，依赖于当前字体font-family 和字体大小 font-size。
ex 指当前字体环境中小写字母x 的高度；
ch 指当前字体环境中数字 0 的宽度。
什么是rem？
rem（font size of the root element）是指相对于根元素的字体大小的单位。简单的说它就是一个相对单位。
看到rem会想起em单位，em（font size of the element）是指相对于当前对象内字体大小的单位。它们之间其实很相似，只不过一个宽高计算是依赖根元素字体大小，另一个是依赖当前对象或祖先的字体大小计算。
rem计算验证：
因为浏览器默认字体大小为16px，则1rem=16px。如果想设置一个元素的宽高为100px，计算起来较为麻烦，所以一般做法为html {font-size: 62.5%;}
即将根元素字体大小缩为默认大小的62.5%，此时1rem=16px*62.5%=10px
rem计算验证：
问题：
验证后发现chrome字体限制BUG，因为chrome限制最小字体为12px，所以此时无法将根元素字体大小的16px的62.5%缩为10px。
即chrome下最小字体为12px，所以假如你设置html{font-size:62.5%} header{height:8rem} 那么在其他浏览器下 header的高度是80px，但是在chrome下是96px。
方案：
设置：html{font-size:625%} 这样子既便于计算，又不会产生这个问题
如果将html{font-size:625%;}后，宽高计算都没有问题，但字体会顶飞，变得特别大…
rem字体过大解决方案：
重新定义body字体大小为font-size:0.16rem即可
面试常问：
设了html{font-size:62.5%}后就有1rem = 10px，为什么不直接设置html{font-size:10px}，如果设置10px，则1px也是=10px？
开发移动端设置viewport配合进行缩放
参数分析：
device-width设备宽度、initial-scale初始缩放比、maximum-scale允许用户缩放到的最大比例、user-scalable用户是否可以手动缩放 (no/yes)
JS动态设置根元素字体大小
（1）获取根元素字体大小
document.documentElement.style.fontSize
（2）获取屏幕可视区域窗口宽度
document.documentElement.clientWidth
计算语法：
document.documentElement.style.fontSize
=
document.documentElement.clientWidth / 750*100 + ‘px’;
简介及原理：
flexible.js是一个开源的用于终端设备的适配解决方案，主要用于解决各种不同尺寸移动设备的大小自适应问题，其原理是通过移动设备的dpr（设备像素比=物理像素/设备独立像素）和屏幕宽度来动态改变html的font-size大小。
假如一个元素的宽是160px,在平时，我们可以采用百分比可以做到自适应，假如使用响应式的话，可能需要设置多个，比如在320px，输出80px，而在640px输出160px等。而采用以上rem的方法，则只需要输出2.5rem就能实现统一，如下表格：
设置编码格式语法：
注意：
以上为HTML5的声明语法，传统声明语法为
可以操作的属性有 4 个：
width – viewport 的宽度 （范围从 200 到 10,000，默认为 980 像素）
height – viewport 的高度 （范围从 223 到 10,000 ）
initial-scale – 初始的缩放比例 （范围从 > 0 到 10）
minimum-scale – 允许用户缩放到的最小比例
maximum-scale – 允许用户缩放到的最大比例
user-scalable – 用户是否可以手动缩放 (no，yes)
移动端开发时常用语法
解析：
强制让文档与设备的宽度保持 1:1 ；
文档最大的宽度比列是1.0（ initial-scale 初始刻度值和 maximum-scale 最大刻度值）；
user-scalable 定义用户是否可以手动缩放（ no 为不缩放），使页面固定设备上面的大小；
meta元标签
简介：meta 标签位于 head 标签之间，是 HTML 语言的一个辅助性标签，在移动端中起着非常重要的作用。
常见苹果适配问题：
【问题1】：iPhone页面会自动把数字当成电话号码，点击后自动跳到电话拨号界面
方案：
meta元标签常见苹果适配问题
【问题2】微信浏览器自动调整页面字体大小
方案：禁止微信浏览器调整页面字体大小
【问题3】用户随意选中页面文字及图片
方案：如无文本选中需求，此为必选项
【问题4】iPhone长按图片保存图片弹窗
方案：关闭长按图片保存图片弹窗
【问题5】 iPhone输入框的光标发生位移，上移或者下移
方案：不要设置line-height即可
【问题6】苹果手机上的input按钮自带渐变效果
方案：加上outline:0px; -webkit-appearance:none; 清除原有样式，同时苹果手机上的input按钮自带圆角需要按需要去掉
【问题7】表单input元素获取焦点时页面被放大
表现：在iPhone上点击input框会有一个动画效果，这是苹果公司默认设置的，每次input获取焦点都会使页面放大，效果非常不好看
方案：
【问题8】iPhone移动端input 无法获取焦点
原因：在移动端开发中，我们有时有针对性的写一些特殊的重置，在整个项目之中有一个需求，禁止用户进行复制.选择.，于是写了这样的代码 -webkit-user-select: none;影响到了input获取焦点。
方案：把-webkit-user-select:none改成-webkit-user-select:auto;覆盖掉或者直接注释掉就行，如果项目需要，就不用注释了。
【问题9】360浏览器兼容模式打开项目无法正常浏览
场景表现：自己写完项目在各个浏览器检查时，并没有问题，当项目给到后台同事的时候，在他们的电脑上用360浏览器兼容模式打开项目，出现不兼容的问题。
同事的电脑安装的同样都是同一版本的360浏览器。最后，经过查阅资料发现，360兼容模式出现的兼容问题，实质还是IE的兼容问题，同时，每个电脑内置的IE版本是不一样的，开发时电脑内置IE的版本高，而同事的版本低导致出现渲染页面时出现问题。
【问题9】360浏览器兼容模式打开项目无法正常浏览
方案：在头部加上以下代码
原理：http-equiv=“X-UA-Compatible” 这是一个文档兼容模式的定义， Edge模式告诉IE以最高级 模式渲染文档，也就是任何IE版本都以当前版本所支持的最高级标准模式渲染，避免版本升级造成的影响。这句代码可以改变360兼容模式下以何种版本的IE去渲染页面。
【问题10】移动端click事件延迟300ms
场景：一般情况下，如果没有经过特殊处理，移动端浏览器在派发点击事件的时候，通常会出现300ms左右的延迟。也就是说，当我们点击页面的时候移动端浏览器并不是立即作出反应，而是会等上一小会儿才会出现点击的效果。
在移动WEB兴起的初期，用户对300ms的延迟感觉不明显。但是，随着用户对交互体验的要求越来越高，现今，移动端300ms的点击延迟逐渐变得明显而无法忍受。
【由来】：那么，移动端300ms的点击延迟是怎么来的呢？
问题由来：
1、这要追溯至 2007 年初。苹果公司在发布首款 iPhone 前夕，遇到一个问题：当时的网站都是为大屏幕设备所设计的。于是苹果的工程师们做了一些约定，应对 iPhone 这种小屏幕浏览桌面端站点的问题。
这当中最出名的，当属双击缩放(double tap to zoom)，这也是会有上述 300 毫秒延迟的主要原因。双击缩放，顾名思义，即用手指在屏幕上快速点击两次，iOS 自带的 Safari 浏览器会将网页缩放至原始比例。
那么这和 300 毫秒延迟有什么联系呢？
问题由来：
2、假定这么一个场景。用户在 iOS Safari 里边点击了一个链接。由于用户可以进行双击缩放或者双击滚动的操作，当用户一次点击屏幕之后，浏览器并不能立刻判断用户是确实要打开这个链接，还是想要进行双击操作。因此，iOS Safari 就等待 300 毫秒，以判断用户是否再次点击屏幕。
鉴于iPhone的成功，其他移动浏览器都复制了 iPhone Safari 浏览器的多数约定，包括双击缩放，几乎现在所有的移动端浏览器都有这个功能。之前人们刚刚接触移动端的页面，在欣喜的时候往往不会care这个300ms的延时问题，可是如今touch端界面如雨后春笋，用户对体验的要求也更高，这300ms带来的卡顿慢慢变得让人难以接受。
问题由来：
3、那么我们该如何解决这个问题，大家可以参考如下的几种方法。
①禁用缩放
②FastClick插件
③JS库jQuery电脑端和zepto.js移动端等js库的tap触屏事件
移动端
触屏事件
触屏开始touchstart—触屏滑动touchmove—触屏结束touchend
触屏取消touchcancel（电话、闹铃）
解决方案：
（1）禁用缩放
解决方案：
（2）FastClick插件
FastClick是FT Labs专门为解决移动端浏览器 300 毫秒点击延迟问题所开发的一个轻量级的库。简而言之，FastClick 在检测到 touchend 事件的时候，会通过 DOM 自定义事件立即触发一个模拟 click 事件，并把浏览器在 300 毫秒之后真正触发的click事件阻止掉。
当 FastClick 检测到当前页面使用meta设置了user-scalable=no或者 touch-action 属性的解决方案时，会静默退出。可以说，这是真正的跨平台方案出来之前一种很好的变通方案。就目前而言，FastClick 非常实际地解决 300 毫秒点击延迟的问题。
解决方案：
（2）FastClick插件
用法：FastClick 的使用方法非常简单，在 window load 事件之后，在body上调用FastClick.attach()即可。
①引入脚本：引入插件的js文件到HTML网页中，脚本必须加载到实例化fastclick在页面的任何元素之前
问题：上下拉动滚动条时卡顿、慢
涉及属性1：
text-size-adjust:100%;用百分比来指定文本大小在设备尺寸不同的情况下如何调整
涉及属性2：
-webkit-overflow-scrolling:touch；快速滚动和回弹的效果，允许独立的滚动区域和触摸回弹，WebKit私有的属性
涉及属性3：
tap-highlight-color:transparent;当用户轻按一个链接或者JavaScript可点击元素时给元素覆盖一个高亮色。
如果想取消这个高亮，将值设置为全透明即可，比如transparent
涉及属性4：
appearance:none;解决iPhone圆角问题
appearance允许使元素看上去像标准的用户界面元素
appearance: normal常规元素|icon图标（小图片）|window视口|button按钮|menu呈现为一套供用户选择的选项|field呈现为输入字段;
涉及属性5：
border-collapse:collapse;表格设置合并边框
涉及属性6：
text-size-adjust: 100%; 解决的是chrome等以webkit为内核的浏览器下不支持小于12px的问题，在chrome下，缩小网页，其他元素缩小，但是字体大小不变的问题。 -ms-text-size-adjust: 100%;；解决IE的字体调整问题。
移动端开发模板