关于javascript:移动端适配

屏幕尺寸

屏幕分辨率

数值大的在后面，数值小的在前面

PPI 和 DPI

是指对角线上每英寸的像素数量，而不是每平方英寸上的像素数量，这里指物理像素

设施像素和逻辑像素

设施像素即物理像素：

逻辑像素：


这个 375*667 就是逻辑像素

设施像素和逻辑像素不等价的状况：

dpr- 设施像素比

咱们 css 中写 windth:1px，Iphone6 设施上会占用两个发光点来显示
Iphone6 中设施像素是逻辑像素的两倍，Iphone6 也称为 2 倍屏，也就是 dpr 是 2

设施独立像素 -DIP

视图视口 -visual viewport

布局视口 -layout viewport

测试代码：

后果：
选中 box 标签，发现它的宽度是 980px

meta viewport 标签只对挪动端浏览器无效，对 PC 端浏览器是有效的。

测试代码：

后果：
选中 box 标签，发现它的宽度是 450px

Window10 零碎，如果设置了缩放，比方选中 200% 的缩放，上例中，选中 box 标签，发现它的宽度将是 225px

发现当设置 width=450 是，呈现了横向滚动条：

批改为 width=device-width：

后果：
选中 box 标签，发现它的宽度是 414px，跟 iphone8plus 的逻辑像素统一

测试代码：

后果：
Iphone8 的 375px 的盒子里能放下 640px 长度的标签，是因为缩放了 0.5 倍：

现实视口 -ideal viewport

只设置 initial-scale 也能实现成果，因为浏览器会主动去计算出 width 的值：布局视口宽度 = 设施现实视口宽度 / initial-scale
不设置 width 属性时，浏览器会将布局视口宽度设置为视觉视口宽度，以将页面正好铺满屏幕。能够认为这是一条定律。
如果 initial-scale 和 width 同时设置了，就取计算结果数值大的那个
常见的写法是两个都写，而不是只写一个

对于视口：

• 挪动端的适配离不开 viewport，前面百分比和 rem 的计划，都是在 viewport 的根底上
• 只有在浏览器调试台显示的像素，都是逻辑像素，他们是一样的单位，如下的 375667、64060、638*58 都是一样的单位
  

百分比布局计划

这边包含两种：

• 百分比 + 固定高度
• 弹性盒子(即 flex 布局)+ 固定高度

百分比 + 固定高度的案例：

Rem 布局计划

媒体查问扭转根元素的字体大小：

这里的 min-width 是指逻辑像素，即 css 像素，即上面的这个像素：

如果设计稿习惯给 640*2=1280px 的，那么 min-width:640px 上面定为 100px，是因为不便换算，比方设计稿上一个标签是 120px，则写成 1.2rem

min-width:480px 上面的 75px 是怎么计算的：
640/480 == 100/75 == 1.33

当初更多应用 750*1334px 的设计稿，所以应该在 750 这个范畴里设置 font-size:100px

毛病：

js 实现动静扭转根元素的字体大小

document.clientWidth 是布局视口的宽度，即 viewport 中指定的 width

这个公式和后面媒体查问的数据公式是一样的

毛病：在 2 倍屏的设施上，1px 的线条显示很粗，因为是占用两个物理发光点来显示 1px

缩放自适应布局形式

举荐两个挪动端适配插件：

淘宝的 flexible 计划地址：
https://github.com/amfe/lib-f…

hotcss 地址：
https://github.com/imochen/ho…

Hotcss 的应用步骤：
下载 zip 包，解压后拷贝如下两个文件到我的项目里：

Hotcss.js 里的代码：

px2rem 里的代码：

测试代码：

后果：box 物无论在什么设施上都是屏幕宽度的一半
因为，hotcss 将屏幕均匀分成了 16 份，1 份就是 1rem

hotcss 的具体用法：

cart.html：

.html 文件中不须要写 <meta name=”viewport”，因为援用的 hotcss.js 文件里会动静增加
css 文件最好再 js 文件之前引入

px2rem.scss：

cart.sass：

.box 标签在 750px 的设计稿上量进去是 100px，写成 px2rem(100)
.box2 不应用 px2rem

cart.sass 编译后：

后果：

超过 540 将不再自适应变动，因为 540 是 hotcss.js 代码里写死的

hotcss.js 解析

核心思想：
背景：以后的设计稿，宽泛应用的是二倍图，因为再小点不清晰，再大点图片太重
指标：当量出设计稿上某个标签的长宽后，能够间接写到 css 中，不须要简单换算
计划：想要让二倍图大小的标签挤进一倍大小的布局视口里，能够应用 initial-scale 进行放大

meta 标签 initial-scale 的大小计算：

var dpr = window.devicePixelRatio
initial-scale = 1/dpr

html 标签下的 font-size 值的大小计算：

上一步中 meta 标签 initial-scale 的大小确认后，
document.documentElement.clientWidth 的大小也就确认了
var clientWidth= document.documentElement.clientWidth
var fontSize = (clientWidth*20/320) + ‘px’

px2rem.scss 里

@function px2rem($px){

@return $px*320/$designWidth/20 + rem

}

$designWidth = 750

这段代码的作用:

以 750px 设计稿为例
上一步中失去 html 标签下的 font-size:750*20/320=46.875
设计稿中一个标签量进去是 750px，换算成 rem 单位是：750px/46.875=16rem
hotcss 的目标就是 16 这个数字，所以才会写 $px*320/$designWidth/20 这一堆
为什么要 16 这个数字：模仿 bootstrap 栅格化，栅格化 16 等份
当不援用 px2rem.scss 文件，只援用 hotcss.js 文件，css 中也能够写 rem 单位，不必 px2rem($px)函数
写 16rem 就是满屏的长度
如果设计稿中一个标签量进去是 32px，换算：32/750*16=0.68，css 中就能够写成 width:0.68rem
因为换算太麻烦，所以才呈现 px2rem.scss 里的代码

如果提供的是非 750px 的设计稿:

假如提供的是 iPhone12 pro 的 780px 的设计稿
iPhone12 pro 的 devicePixelRatio=2
initial-scale = 1/dpr = 1/2 = 0.5
var clientWidth= document.documentElement.clientWidth = 780
var fontSize = (clientWidth20/320 ) + ‘px’ = (78020/320) +’px’ = 48.76
$designWidth = 780
设计稿中一个标签量进去是 780px，换算成 rem 单位是：780px/48.76=16rem

hotcss 的特地用法：

• 只援用 hotcss.js 文件，不应用 px2rem.scss，本人写办法转换 px 和 rem：
  $designWidth: 750; // 视觉稿横屏尺寸
  @px2rem: 320/$designWidth/20 * 1rem;
  如果 750px 设计稿中一个标签量进去是 32px，写成：
  div{
  background: red;
  width: 32*@px2rem;
  }
• 如果.html 文件须要写 <meta name=”viewport” 也能够，
  <meta name=”viewport” content=”width=device-width,initial-scale=1.0,
  minimum-scale=1.0, maximum-scale=1.0, user-scalable=no, viewport-fit=cover”>
  hotcss.js 文件里会依据这个 viewport，算出 html 标签下 font-size 的值
  前面的过程也是一样的，用法也是一样的：width: px2rem(100)
• 在内联款式中间接写 rem 单位
  <p style=”height:3rem”>111{{test}}</p>
  记住 16rem 是横向满屏的宽度
• js 代码中应用 px 单位

• 在 hotcss.js 文件中，往 window 上挂了全局属性和函数：
  rem2px 函数(将 rem 转化为 px)、
  px2rem 函数(将 px 转化为 rem)、
  dpr 属性(window.devicePixelRatio)

  如果 750 设计稿上量进去的 100px，则写成 rem2px(100 * 320 / 750 / 20)
  为什么要写 * 320 / 750 / 20，是因为要转换成 rem，参考 hotcss 特地用法的第一条
  100 * 320 / 750 / 20 = 2.1rem，所以也能够间接写 rem2px(2.1)
  2.1/16 = 13%，所以无论在什么设施上，tabWidth 的宽度都会渲染为横屏宽度的 13%

兼容问题：

横竖屏转换 rem 计算提早问题

clientWidth 适配计划的兼容解决：

hotcss 适配计划的兼容解决：

挪动端 1 像素 1px 边框过粗解决办法：

补充

document.documentElement.clientWidth
或者
document.documentElement.getBoundingClientRect().width
取值的状况：
当 initial-scale= 1 时，取值就是该设施的逻辑像素：

当 initial-scale=0.5 时，取值是该设施的逻辑像素的 2 倍：
（只设置 initial-scale 也能实现成果，因为浏览器会主动去计算出 width 的值：布局视口宽度 = 设施现实视口宽度 / initial-scale
不设置 width 属性时，浏览器会将布局视口宽度设置为视觉视口宽度，以将页面正好铺满屏幕。能够认为这是一条定律。
如果 initial-scale 和 width 同时设置了，就取计算结果数值大的那个
）