web移动端适配

① WEB前端浏览器兼容性问题(pc端及移动端)2021-02-03

1.当使用transform:translate3d(-50%,-50%,0)居中弹框（div）时，在pc端，内部的文字会模糊。
解决办法：给body定义样式

2.用position:absolute/fixed;把一个按钮固定在页面的底部，在android系统中，当调用输入法时，该按钮会被顶起

3.IOS系统调用第三方输入法时，系统无法监测到input的input、focus、change、blur事件

4.不同浏览器默认margin，padding不同。

5.不同浏览器的最小字体不同，有的是10px，有的是12px

6.透明度opacity

7.文字两端居中text-align：justify；text-align-last：just；在移动端不起作用

② 移动端Web页面适配方案（整理版）

@(概述)[基本概念|百分比|rem|vw/vh|响应式设计]

移动端web页面的开发，由于手机 屏幕尺寸 、 分辨率 不同，或者需要考虑 横竖屏 问题，为了使得web页面在不同移动设备上具有相适应的展示效果，需要在开发过程中使用合理的适配方案来解决这个问题。

早期网页设计采用 静态布局 ，通过 <meta> 标签中的 applicable-device 应用设备标识识别移动设备，即 <meta name = 'applicable-device' content = 'mobile'> ，在 <meta> 标签中的 viewport 标签中设置 width ，通过 js 动态修改标签的 initial-scale 使得页面等比缩放，刚好占满整个屏幕。一些文章中有提到静态布局中页面各个元素采用 px 为单位，这种方案实现简单，不存在兼容性问题，但用户体验很不友好。

后面出现 流式布局 ，使用百分比 % 定义宽度，高度使用 px 固定，根据可视区域大小实时进行尺寸调整，通常使用 max-width/min-width 控制尺寸范围过大或者过小。这种方案实现比较简单，但在大屏手机或横竖屏切换场景下可能会导致页面元素被拉伸变形，字体大小无法随屏幕大小发生变化。

顺应不同页面字体大小展现问题，出现了 弹性布局 。这种布局方案下，包裹文字的元素的尺寸采用 em/rem 为单位，页面主要划分区域的尺寸依据情况使用 px 、百分数或者 em/rem 。如一些高校的网站 jlu ，页面的主要划分区域使用 px 和百分比，包裹文字的元素和文字采用 em 。

上面的这几种方案下，页面元素的大小按照屏幕分辨率进行适配调整，但是整体布局不变，对于 响应式web设计 ，网页布局会随着访问它的视口及设备的不同呈现不同的样式，在实现上可能会以上多种方案的结合，同时搭配 媒体查询 技术使用，使得一个页面在多个终端 (PC, mobile, pad) 呈现满意效果，如 mashable 。

[TOC]

像素，是屏幕上显示数据的最基本的点，表示相对大小。不同分辨率下相同长度的 px 元素显示会不一样，是因为像素点的个数相同情况下，不同分辨率下每个像素点对应的像素宽度不同。比如同样是 14px 大小的字，在 1366×768 显示屏下会显示的小，在 1024×768 显示屏下会相对大。也称为 物理像素（设备像素 ），是分辨率的尺寸单位。

印刷行业常用单位，能够使用测量设备测得的长度，等于 1/72 英寸。

在不同屏幕上， css 像素呈现的物理尺寸一致，但 css 像素对应的物理像素具数不同。标准的显示密度下， 1 个 css 像素对应一个物理像素，缩放时， 1 个 css 像素对应的物理像素会减增。是一种 设备独立像素(device independent pixels: DIPs)

像素密度，每英寸所拥有的像素数。值越高，显示画面细节越丰富。计算公式为： ，其中 和 是分辨率的宽高， 是屏幕尺寸。

打印设备每英寸印刷出来的点有多少个，值越高，图片越细腻。

设备物理像素和设备独立像素比 ，即 是指在理想布局宽度，使用多少个物理像素来渲染一个css像素。js中通过 window.devicePixelRatio 获取，css中通过 -webkit-device-pixel-ratio , -webkit-min-device-pixel-ratio , -webkit-max-device-pixel-ratio 进行媒体查询。

<meta> 标签中定义了一些元数据信息，通过设置 <meta name = "viewport"> ，提供有关 视口初始大小 的信息，供 移动设备 使用。属性值为

移动端涉及 布局视口 （Layout Viewport）、 视觉视口 （Visual ViewPort）和 理想视口 （Ideal ViewPort）。

与移动端web页面适配有关的手机屏幕特性包括

硬件所支持的，屏幕每行的像素 * 每列的像素点数，单位是 px 。

设备独立的，软件可以达到的，个人理解是使得软件/页面在不同屏幕上显示出来的效果一致。

像素分辨率 ÷ 逻辑分辨率等于 倍率 ，如 @3x 表示分辨率的 3 倍。一个已知物理像素大小的元素，如果在普通屏中其设备像素等于 css 像素，但在一些高清屏中，如 Retina 显示屏，一个css像素对应 2 或 3 个设备像素，这时显示出来的元素会变小。为了让元素如期待显示，需要传入 原始设计稿尺寸 × 倍率 的设计稿，根据 DPR 的定义，这样加载后能够达到同样的效果。

手机屏幕对角线长度换算成英寸的大小

贴上 源码 分析

视口 是浏览器中用于呈现网页的区域，移动端的视口通常指的是 布局视口

使用 css 预处理器把设计稿尺寸转换为 vw 单位，包括 文本 ， 布局高宽 ， 间距 等，使得这些元素能够随视口大小自适应调整。以 1080px 设计稿为基准，转化的计算表示为

响应式设计 使得一个网站同时适配 多种设备 和 多个屏幕 ，让网站的布局和功能随用户的使用环境（屏幕大小、输出方式、设备/浏览器能力而变化），使其视觉合理，交互方式符合习惯。如使得内容区块可伸缩与自由排布，边距适应页面尺寸，图片适应比例变化，能够自动隐藏/部分显示内容，能自动折叠导航和菜单。

③ 移动前端开发和web前端开发有什么区别

移动前端开发和web前端开发有什么区别呢？既然都是前端开发，两者肯定有紧密的联系，移动前端开发和web前端开发其实都属于前端开发的范围，目前前端发展的趋势就是大前端，可以说是包罗万象，当然也就包含PC端和移动端领域，而现在的前端开发人员也已早就不是当年的切图仔了，需要学习和掌握大前端体系方方面面的知识才能在日常的开发中游刃有余，但是不论趋势如何发展，目前来看HTML、CSS和Java依然是整个前端开发的三大基石。不论是想做移动前端开发还是web前端开发，这三样基础技术都必须熟练掌握。移动前端开发和web前端开发有什么区别呢？
1、业务的应用场景
web前端开发主要指传统的PC端网页开发，页面主要是运行在PC端浏览器中，移动前端开发出来的页面主要是运行在手机上；直观上会感觉，PC端页面大一些，移动端页面小一些，但是根据开发经验，页面大可并不代表书写的代码复杂，页面小也并不意味着开发简单，难与易主要还是取决于具体的业务需求。
2、新技术的使用
由于在移动端主要以webkit内核为主，对于HTML5等新技术支持的更好，所以可以更大范围的使用新技术;而PC端开发由于很多场景下要求兼容IE等老版本浏览器，出于浏览器兼容性的考虑，有些情况下限制了新技术的使用。
3、页面的适配性
传统PC端的页面开发一般都会选择给页面设定一个固定宽度，两侧有留白，但是移动端的页面由于其载体手机屏幕比PC要小很多，一般都会选择尽可能多的在手机屏幕上显示内容，这就要求移动端页面要能够充分适应各种屏幕尺寸的手机并进行最大程度的利用。从这一点上来说移动端页面的适配难度更高一些。
4、页面的性能
PC端的网络情况一般比较稳定，都是通过网线或者Wi-Fi连接网络;但是移动端就比较复杂，除了Wi-Fi，还有2G、3G、4G甚至是在几种不同的网络连接中交替切换也经常发生，不稳定的网络连接对页面性能带来的挑战是移动端的页面资源不能太大，否则在恶劣网络情况下时，页面将会无法访问 ，严重影响用户体验。移动前端开发和web前端开发有什么区别
5、框架选型
由于移动端网络情况的不稳定，导致我们在移动端页面框架选型时，一般只考虑小而美的框架，例如像zepto.js这样的压缩之后只有9.6K，就能满足一般业务的需要，如果是想要构建更复杂的单页面应用，可以选择像vue.js这样的框架，功能强大，但体积压缩后却只有20多K。而web端相对选择的范围就比较大，一些比较重型的框架也可以根据项目需求加以考虑，例如古老但庞大的ext.js，依然凭借着众多UI组件活跃在一些企

④ 移动端H5页面适配问题研究

刚开始做移动端web开发的同学应该都碰到过页面适配问题，为什么我在开发手机上调试好的页面在其他手机会有这样或那样的样式问题？ viewport 我也设置了，为什么还是显示不正常？难道我要为每种手机屏幕写媒体查询，有没有简单的方式，可以不用关注手机屏幕的差异性呢？

网络中搜索 移动端H5页面适配 关键字，大概可以得到180多万的搜索结果，由此可见这个问题也得到很多人的关注。本文的目的主要是分析解决移动端H5页面适配问题过程中牵扯到的知识点，然后梳理分析目前常见的适配解决方案。

由于本文内容较长，下面先给出文章的提纲：

1.1理解移动端单位
1.2理解viewport

2.1图片高清适配
2.2字体大小适配
2.3布局宽度适配

---这里是分隔符，正文开始---

不知道正在看文章的你对上面列出来的这些单位是不是很熟悉，如果是的话，就可以跳过了。

理解这些单位的用法以及区别，对理解移动端页面适配有很大的帮助。为了让你对上面的单位有个大体的认知，这里把上面的单位分成了三类：

下面分别对每个单位展开分析：

*** dpi / ppi ***

** dpi ** , dot per inch ，每英寸的点数；打印或印刷领域使用的单位，代表打印机每英寸可以打印出的点数 。

ppi , pixel per inch ，每英寸的像素数，像素密度；表示图像或者显示器单位面积上像素数量。

dpi 和 ppi 都是描述分辨率的单位，但是两者是有区别的，但是在描述手机分辨率时，可以认为两者意义相同，以前android设备偏向于使用 dpi ，ios设备偏向于使用 ppi ，目前android和ios统一使用 ppi 描述手机屏幕的像素显示密度。

ppi的计算方法：

*** ldpi、mdpi、hdpi、xhdpi、xxhdpi ***

android对移动设备不同屏幕分辨率的分类。

*** pt，pc，sp ***

** pt ** ，磅（point的音译），印刷中使用的表示字型的大小单位，1inch = 72pt （印刷中这个关系成立，ios中不成立），ios开发中使用的逻辑单位，是和设备无关的单位。

** pc ** 印刷中使用的单位，1pc = 12pt，不需要关注。

** sp **， scale independent pixel ，android设备中用来显示字体大小的，和设备无关的尺寸，当设置字体大小单位为sp时，android系统字体大小会影响设置的字体渲染时的大小。

*** dip / dp ***

** dp/dip**， device independent pixel，表示设备独立像素，和设备无关的尺寸，相同的dp/dip值，不同设备展示的效果是一样的。

android使用的单位，之前偏向使用dip，目前建议使用dp。

android设备中，规定160ppi的屏幕，1dp = 1px；320ppi的屏幕，1dp = 2px，所以android设备中dp的计算方法：dp = px * (ppi / 160)，这里的px是指设备的物理像素点。

和ios开发中用的pt单位类似。

*** px ***

** px ** ，像素，有两种像素概念，一种是网页设计中使用的css像素，一种是原生移动系统使用的物理像素。

作为css像素时，表示的也是一种设备无关单位，与android中使用的dp类似，默认情况下与系统分辨率下的像素大小相同，标清设备中，一个css像素和一个设备物理像素大小相同；在高清设备中，一个css像素可以大于或者等于多个设备物理像素，具体一个css像素，需要多少个物理像素来展示，浏览器会根据dpr计算。

原生移动系统中使用px单位时，表示的就是屏幕的物理像素点，每种屏幕的物理像素点大小可能不一样。

*** dpr ***

** dpr ** ，device pixel ratio， 横向或者纵向设备物理像素数量与设备独立像素数量的比值，浏览器中可以通过window.devicePixelRatio获取(存在兼容性问题)。

对于原生app，ios和android系统会自动根据dpr计算出渲染时需要的px值，最终不同屏幕上展示出来的大小很接近；而移动端页面渲染时想要做到这一点，就必须首先得到设备的dpr，然后再根据dpr计算渲染需要的px值。

ios设备中iphone3的dpr为1；iphone4,5,6,7的dpr为2；iphone6+,7+的dpr为3。iphone6+和iphone7+实际计算出来的dpr应该时2.6左右，但是官方还是建议dpr为3，这是因为ios系统利用了一种“缩减像素采样”算法，自动缩减到2.6。

android设备中dpr值有多种，可知的有0.75，1，1.5，1.75，2，2.5，2.75，3，4等。

*** em，rem ***

** em ** 相对单位，CSS2引入的单位，作为字体大小使用时和百分比单位类似，都是相对于最近的父元素设置的字体大小，在body上设置字体大小为100%和设置字体大小为1em是一样的效果，默认情况下浏览器的字体大小为16px，这样只要浏览器默认得字体大小不变，1em = 16px。

** rem ** 相对单位，root em，CSS3新增的单位，作用和em类似，唯一的区别就是em是相对父元素的，rem是相对html根节点的，即所有使用rem单位的子元素的字体大小都是相对根节点的，所以使用rem可以避免使用em带来的子元素字体大小逐层复合的连锁反应。

更多关于em，rem的知识参见这篇文章 理解web开发中的em单位和rem单位 。

*** 分辨率 ***

平时说的手机屏幕分辨率，也称为物理分辨率或者原生分辨率，通常包括纵向分辨率和横向分辨率，例如iphone6的物理分辨率是1334 x 750，其中纵向分辨率是1334px，横向分辨率是750px，表示纵向方向可以显示1334个物理像素点，横向上可以显示750个物理像素点，这里描述分辨率使用的px单位，和css中使用的px单位意义不一样，这里代指物理设备的像素点。

还有一种分辨率叫做系统分辨率，例如iphone6的系统分辨率是667 x 375，其中高度是667pt，宽度是375pt，这里描述分辨率使用了pt单位，是一种设备无关单位。

屏幕尺寸相同的设备，物理分辨率越高，ppi也就越大，绝对单位面积上展示的物理像素数量越多，展示图片也就越细腻。

苹果把ppi > 300的屏幕称为视网膜屏,Retina屏。

传统桌面web页面布局通常是定宽布局，但是定宽布局的方式对移动端却不适用，原因手机屏幕尺寸大小各异，定宽布局可能在某些手机上出现横向滚动条，导致阅读效果比较差。

为了让手机有更好的网页浏览体验，苹果引入了viewport，为页面提供了一个虚拟的布局窗口，在这个虚拟的布局窗口中渲染页面，然后系统会把渲染好的页面自动缩放到手机屏幕大小。

虽然viewport还没有成为正式的规范，但是现在绝大部分浏览器都支持viewport。

在桌面浏览器中，viewport严格等于浏览器窗口大小，页面渲染时，页面宽度不会超过浏览器的宽度。

移动端屏幕太窄，为了提供更好的页面体验，移动端提供了两种viewport： 可视viewport ， 布局viewport 。

可视viewport 就是当前屏幕正在展示的区域，也就是移动设备屏幕的宽度，宽高通过window.innerWidth和window.innerHeight获取（存在兼容性问题）。

布局viewport ，页面布局实际用到的viewport，通常比可视viewport要宽，宽高通过document.documentElement.clientWidth和document.documentElement.clientHeight获取。

移动端还有一种viewport概念，可以理解为 理想viewport ，作用就是在理想viewport下，不同移动设备，展示的字体大小接近，并且不需要用户缩放就可以展示全部的页面内容。

理想viewport的宽度默认等于可视viewport的宽度，但是对同一台设备来说，这个理想viewport的宽度是可以改变的，而可视viewport的宽度是不可变的。

如何使用理想viewport来布局页面呢？只需要设置viewport的width等于device-width。

viewport的属性，推荐使用以及支持度较广泛的属性只有6个： width ， height ， initial-scale ， maximum-scale ， minimum-scale ， user-scalable 。

width 设置viewport布局宽度，内核是webkit的浏览器默认值是980px，取值范围在200-10000px，也可以取值为设备宽度device-width（等于横向设备无关像素数量）。

height 设置viewport布局高度，默认值依赖设备长宽比以及宽度值，取值范围在223-10000px，也可以取值为设备高度device-height。

initial-scale 设置初始缩放比例，页面第一次加载时的缩放比例。默认比例依赖于显示密度。在密度低于200 dpi的显示设备上，比例为1.0。在密度介于200及300 dpi之间的显示设备上，比例为1.5。对于具有300 dpi以上密度的显示设备，比例为密度/150 dpi向下取整的结果。取值范围由 maximum-scale 属性以及 minimum-scale 属性决定。如果设置 initial-scale 值为1， width 默认是device-width， height 默认是device-height

initial-scale 设置的缩放大小会改变理想viewport的大小，不会改变可视viewport的大小，也不会改变布局viewport的大小，这是某些适配方案依赖的基本原理，也是解决 1px问题 的关键。后面分析适配方案时，动态viewport适配方案就依赖这个知识点。

maximum-scale 允许用户缩放到的最大比例，默认值是0.5，范围从0到10.0。

minimum-scale 允许用户缩放到的最小比例，默认值是5.0，范围从0到10.0。

user-scalable 用户是否可以手动缩放，值可以是：yes/true允许用户缩放；no/false不允许用户缩放。

图片适配的目的是为了在页面中可以高清还原设计图中用到的图片。

页面中用到的图片是否清晰和展示页面的硬件设备的dpr以及图片分辨率这两个因素有关，下面会通过三个例子来说明这个问题。

***示例一 ***

例如dpr=2的设备，1个设备无关像素(android中的1dp，ios中的1pt)需要4个设备物理像素点填充。对于尺寸为100 x 120 (px)的图片，如果用 <img> 来展示，图片显示时会产生模糊现象。

原因：渲染图片时，宽度是100px，所以横向会占用100个设备无关像素，高度是120px,所以纵向会占用120个设备无关像素，每个设备无关像素又需要2x2个物理像素点来填充，而图片在每个设备无关像素(px)单位上提供的像素点只有1x1个，这时，系统通过一定的算法在这1个像素点上就近取色，取到4个颜色(这4种颜色接近但是有一定区别)之后，当成4个像素点，然后填充到1个设备无关像素点上，这样就导致图片显示时模糊，dpr越大，这种方式显示的图片越模糊。

示例二

还是dpr=2的设备，但是准备了一个尺寸为200 x 240 (px)的图片，还是用 <img> 来展示，这时显示的图片就比较清晰了。

原因：这时图片本身可以在一个设备无关像素单位上提供2x2个物理像素点，设备展示图片时直接拿图片提供的像素点来填充就可以了，不用对像素点进行处理，所以可以比较清晰的显示图片。

示例三

还是dpr=2的设备，这次准备一个尺寸400 x 480 (px)的图片，还是用 <img> 来展示时，这种情况展示的图片缺少锐利度，也影响了图片的清晰度，但是很难看出来。

原因：图片本身在一个设备无关像素点单位上提供了4x4个物理像素点，而设备本身只需要2x2个物理像素点，所以会通过缩减采样算法，在图片提供的4x4个物理像素点中，选取颜色接近的2x2个物理像素点填充到设备无关像素点上，所以也会产生一定的色差，这种情况下图片尺寸越大，这种色差也就越明显，但是人眼很难区分这种色差。

下面是我在oppo的一款手机上的测试结果，结合这张效果图就可以很好的理解上面的三个示例了：

图片适配最佳实践

要想高清显示图片，如果条件允许(有单独的图片服务器)最直接的解决办法，肯定是根据设备的dpr，为不同dpr的设备加载不同倍率大小图片显示；没这种条件的或者对用户体验没有很高要求的，只能选一种折中的方案了，一般情况下只需要提供布局尺寸2倍大小的切图就可以了，也就是只高清适配dpr=2的设备，但是dpr为3或者4的设备展示效果也能接受，不容易看出来模糊现象。目前主流机型的dpr也就在2和3之间。

字体适配目标主要还是看设计要求，主要有两种：

1.不同屏幕下，字体显示大小都一样，即需要等宽显示字体；

2.不同屏幕下，一行能显示的字数固定，即需要按比例缩放字体大小；

开始分析之前，先看下这两种字体适配的示例：

第1种字体适配方案的示例

第2种字体适配方案的示例

下面就来具体分析下两种字体适配方案的原理以及优劣。

** 第1种字体适配方案原理 **

在开始分析这种方式的原理之前，先通过一张图理解下px和dp以及绝对长度之间关系。

由上图可知字体大小只与css单位px有关，而每个设备上px的绝对宽度又和设备的绝对宽度以及绝对宽度上划分出的设备无关像素点dp有关；只要设备的横向dp数量与绝对宽度的比值(dp/cm)相同，就可以保证px在不同设备上展示的绝对宽度是一样的；如果dp/cm的比值过大，那么px的绝对长度就会变小，看起来就会显小；如果dp/cm的比值过小，那么px的绝对长度就会变大，看起来就会显大；一般来说手机屏幕分辨率越高，相同px值的字体看起来就会越小。

iphone5和6的dp/cm比值十分接近，所以12px大小的字体在这两种手机上显示的大小基本一样，看不出来区别，但是iphone6+的dp/cm比值要比iphone5,6的略大，这就导致12px大小的字体在6+上显示的比5，6上显示的略小，上面的淘宝对比图仔细分辨可以看出来。

android的手机屏幕dp/cm比值在各个设备之间也有差异性，并且比较有多样性。所以同样12px大小的字体，各个设备显示时也是有差别的。

这种显示差别在iphone系列手机中可以忽略不计，但是android碎片化比较严重，完美兼容各种机型没有必要，主流机型中这种显示差别也可以忽略不计，所以采用这种方式进行字体适配只需要px值设置成一样的就可以了。

** 第1种字体适配方案优缺点**

优点：1.不同设备中字体大小显示一致，比较统一；2.大屏手机可以显示更多的文字；

缺点：1.由于单个字体宽度是定死的，所以在有些机型下可能会影响页面布局；

** 第2种字体适配方案原理 **

在设计稿中，计算出字体大小相对于基准字体大小（基准字体大小可以选择设计稿宽度，一般为了计算方便，会把设计稿宽度/10得到的值作为基准字体大小）的比值，然后在不同布局宽度下，先得到基准字体大小，再根据上面计算出来的比值，就可以计算出来不同布局宽度下的字体大小，也就是不同布局宽度下等比例缩放字体。

利用rem的特性，在页面的html标签上设置一个基准字体大小，就可以实现这种方式。

例如，宽是750px的设计图中，字体大小是32px，计算出基准字体大小为75px，比值为 32 * 10 / 75 = 0.426667。

如果布局宽度是414px，此时基准字体大小变成 414 / 10 = 41.4px，然后设置<html style="font-size:41.4px">，字体大小是0.426667rem，计算出来的字体大小为41.4x0.42667=17.66px。

如果布局宽度变成360px，此时基准字体大小变成36px，然后设置<html style="font-size:36px">，字体大小仍然用0.426667rem表示，计算出来的字体大小为36x0.42667=15.36px。

750/32 约等于 414/17.66 约等于 360/15.36，这样就做到了等比缩放字体了。

** 第2种字体适配方案优缺点**

缺点：1.小尺寸设备屏幕上字体显示小，大尺寸设备屏幕字体显示大，导致字体显示不一致；2.不能发挥大屏手机的优势（显示更多的字）；3.字体大小会出现奇数或者小数点大小的值，某些字体不支持这些值，渲染时增加计算量；

优点：1.适配简单，不同设备不会影响页面布局，可以和设计稿布局保持一致；

布局中对宽度的适配，也是采用rem来实现，和上面第2种字体大小适配方式中的原理类似，也是计算出一个比例值，然后不同布局宽度中等比缩放，这里偷下懒，不在赘述。

目前的解决方案有两类

第一类就是js动态生成viewport标签，标签中的initial-scale值根据设备的dpr计算，不同dpr设备的viewport值不同。

第二类就是js不操作viewport，每个设备都使用理想viewport来布局。

** 动态viewport解决方案分析 **

这里分析两个动态viewport解决方案：

1.手机淘宝的flexible方案；
2.hotcss方案；

手机淘宝的flexible方案 ，特点：

1.仅针对iphone生成动态viewport，因为目前iphone的dpr只有1，2，3三种，android的dpr很有多种，不具有一致性；

2.字体大小不用rem做缩放处理，仍然使用px单位，设置不同dpr下对应的字体大小；

3.宽度利用rem等比缩放；

4.允许强制定义dpr;

使用时页面头部需要引入 flexible.js .

hotcss方案 ，特点：

1.不区分iphone和android，dpr只取三种1,2,3，android的dpr做近似处理；

2.宽度以及字体利用rem等比缩放；

3.允许强制定义dpr;

使用时页面头部需要引入 hotcss.js

动态viewport方案之所以会称为动态viewport是因为，这个适配过程会根据系统dpr值设置initial-scale属性的大小，大小等于1/dpr。

** 静态viewport解决方案分析 **

利用rem特性，先根据标注图算出各元素相对于设计稿宽度的比值，这个比值就作为rem值，然后页面布局时就用算出的rem值表示，并且在html根元素设置当前布局页面宽度作为基准。更rem值计算具体的解释可以参考这篇文章 使用Flexible实现手淘H5页面的终端适配 。通过这种方式设置标签元素的宽高，位置以及字体大小，这样利用rem特性就可以在不同手机屏幕上实现等比缩放。

参考资料
https://github.com/amfe/article/issues/17
http://www.cnblogs.com/pigtail/archive/2013/03/15/2961631.html

⑤ 什么是移动适配

移动适配是指使不同尺寸的手机设备页面“相对性的达到合理的展示（自适应）”或者“保持统一效果的等比缩放。手机设备屏幕尺寸不一，做移动端的Web页面，需要考虑安卓/IOS的各种尺寸设备上的兼容，针对移动端设备的页面，设计与前端实现更好地适配不同屏幕宽度的移动设备。

(5)web移动端适配扩展阅读：

完美的移动适配不需要用户缩放和横向滚动条就能正常的查看网站的所有内容；显示的文字、图片等其他元素大小合适，无论是在何种密度屏幕，何种分辨率下，显示出来的大小都是差不多的。

适配不同屏幕宽度以及不同dpr，通过动态设置viewport(scale=1/dpr) + 根元素fontSize + rem, 辅助使用vw/vh等来达到适合的显示。

若无需适配可显示1px线条，也可以不动态设置scale，只使用动态设置根元素fontSize + rem + 理想视口。