摘要：目录移动端开发的基本观点像素基础知识原理解析弹性布局响应式设计的运用移动端的事件库的使用移动端开发的基本观点移动端开发的意义移动端用户使用量市场需求市场供给公司需要移动端开发人才工资高，就业易涌现大波程序猿到了猴年马月，工资才会
目录
移动端开发的基本观点
像素基础知识
viewport原理解析
弹性布局
响应式设计
1rem的运用
移动端的事件
zepto库的使用
移动端开发的意义
移动端用户使用量 -> 市场需求 -> 市场供给 -> 公司需要移动端开发人才 -> 工资高，就业易 -> 涌现大波程序猿 -> 到了猴年马月，工资才会降下来 -> 新的技术涌现，VR/AI -> 市场需求攀升 -> 重走一波老路......
扯远了，以上大致就是学习移动端开发的动机；
移动端开发的认识
移动端开发就是手机端开发吗？
No、No、No...
移动端是一个大的范畴，小羊认为应该包括智能手机、平板在内的移动设备，主要是这两者；
移动端开发入门的学习路径
目录就是
先抛3个概念，
px(CSS pixels)：虚拟像素，可以理解为“直觉”像素，我要这个元素宽高10px；
dp(device pixels)：设备像素（物理像素），可以理解为实际的像素，这个宽高为10px的元素在设备中实际用了多少个物理像素点表示；
dpr(device pixels ratio)：设备像素比，公式为1px = (dpr)^2 * 1dp，可以理解为1px由多少个设备像素组成；
3个概念整合理解就是：
我为一个元素设置的宽高为10px，那么实际在显示设备中用多少个设备像素真实表示呢？
dpr=2的话，那么1px由4个设备像素显示，如果是10px，那么显示设备实际用40个dp去显示10px；
dpr=1，则1px由1个设备像素显示；
px和dp的区别就是直觉认为只有10px和真实使用40dp；
为什么会出现dpr>=2的情形？dpr=1不是更加符合我的认知和理解吗？
还不是人们为了追求更高的分辨率所致，分辨率越高图像越清晰！！！；
但是Mac的Retina屏和一般PC的在相同尺寸下，图像却清晰许多，为肾？
dpr>=2所致啊！！！
别的品牌机子老老实实1px = 1dp，Mac却是1px = 4 dp，所以你直觉认为大家都使用同样多的像素点表示图像（这是没错滴），实际背后Mac用了多1倍（指的是dpr）的设备像素显示图像；
实际应用中，显示设备不会直接给你个px和dpr
你实际看到的是以下的参数，下面是肾6Plus的显示屏参数信息：
再抛几个概念，可别晕咯...
英寸：这里指的是屏幕主对角线的尺寸，1英寸=2.54cm，5.5英寸约等于14cm（13.97cm）
分辨率：1920*1080像素，这里指的是物理像素（设备像素）
ppi（pixels per inch）：每英寸的像素点，这里肾6Plus为每英寸有401个像素点
那么ppi是如何计算出来的呢？
顾名思义，每英寸的像素点（设备像素），已知屏幕分辨率和主对角线的尺寸，则ppi等于
var 斜边尺寸 = V(1920^2+1080^2) V代表开根号 var ppi = 斜边尺寸/5.5 ppi = 401ppi
现在我们知道，ppi越高，每英寸像素点越多，图像越清晰；
和先前的知识点有什么关系？
毕竟这些参数是外国人先发明的，他们会优先选择自己熟悉的计量单位作为显示设备的工厂标准参数，因此ppi就用作显示设备的工业标准；
告诉业界人士，ppi达到多少是高清屏，此时对应的dpr是多少，而不直接告诉你我现在的显示设备dpr是多少
毕竟人们直接听到像素分辨率会更加有反应
下面是不同ppi对应的dpi：
| ldpi | mdpi | hdpi | xhdpi | |
|---|---|---|---|---|
| ppi | 120 | 160 | 240 | 320 |
| 默认缩放比 | 0.75 | 1.0 | 1.5 | 2.0 |
【注】Retina屏都是dpr>=2的高清屏
肾6Plus的dpr为3，是超高清屏；
到目前为止，我们了解到：
给你一个显示设备，设备分辨率为1920*1080，尺寸为5.5英寸，可以计算出其ppi = 401，根据ppi得知其dpr = 3，
由此可以该设备1px = （3^2）dp，其虚拟像素为1920/3 = 660px，1080/3 = 360px，即虚拟分辨率为360*660；
此时，如果你在代码设置元素的宽高为360*660到的话，会发现它的实际尺寸就等于肾6Plus的屏幕尺寸；
【ppi】
一个很有意思的现象是，当你把上面的代码在chrome下使用设备模拟方式，模拟肾6Plus的时候，神奇的事情发生了，该元素设置的宽高明明就是手机的宽高，按常理应该占据整个屏幕，实际却是：
究竟是怎么一回事？，如何解决这一问题呢？
好吧，作为实用主义者的你们（不是我哟），先讲解决方案：
在meta标签有一个viewport的属性，可以为这个属性设置width；
肾6Plus默认的width是980px，所以元素宽是360px，实际显示的尺寸是360px*360/980=132.24px（不信可以自己测试一下哟）；
现在只要将viewport的width设置为360px，那么元素就可以占满全屏了；
现在就要引入另一个概念：viewport
viewport的原理在于：
先将页面渲染在一个width为显示设备默认尺寸的viewport上，如肾6Plus为980px；
然后将viewport等比例缩放至整个手机屏幕上；
例如上例中，元素宽高为360*600px，先将元素渲染在宽度为980px的viewport上，然后等比例缩放在整个手机屏幕上；
viewport就是连接手机屏幕和页面的中间层
为什么要多此一举呢？
想象一下，如果没有中间层，直接将一个页面宽度为980px的直接缩放至320px，那么里面的DOM节点将会进行重绘，很有可能导致排版错乱；
viewport的作用是将所有的DOM节点先绘在宽度为980px的viewport上，然后整个viewport统一缩放，这样就能保证排版的正确性；
关于viewport，涉及两个概念：
layout viewport：布局viewport，可以理解为放置页面的幕布
visual vewport：视窗viewport，可以理解为屏幕的视窗
比如：
肾6Plus的visual viewport的宽度为360px，layout viewport为980px；
360px是屏幕视窗的虚拟像素，980px是放置页面的像素；
回顾一下，前面元素出现的缩放现象：
根据肾6Plus的物理分辨率1920*1080以及5.5英寸的屏幕，计算出ppi = 401-> dpr = 3 -> 虚拟分辨率为640*360px；
画一个宽度为360px的元素，理应充满整个手机屏幕 ，但是由于viewport的作用 -> 360px的元素画在980px的layout viewport上，然后等比例缩放在360px的visual viewport上-> 最终你看到的就是，360px的元素无法填充整个屏幕；
先前的一个解决办法是，改变layout viewport，即，让整个layout viewport就是360px，那么元素将填充整个屏幕；
以上都是世界观，给人一些概念性的理解，无法实操，下面就是方法论
实际移动端开发，我们只需关注layout viewport，知道每个移动设备提供给我们多大尺寸的幕布，但是移动设备型号那么多，不可能一个个手动设置width呀！！！
动态设置layout viewport
上面的设置表示让layout viewport总是等于设备宽度，即visual viewport；
【注】细心的童鞋可能会注意到，肾6Plus的虚拟分辨率为什么不是640*360px，具体解答可以参考知乎问答
获取visual viewport和layout viewport的api
window.innerWidth：表示窗口的宽度（包含滚动条），即visual vewport的宽度 document.body.clientWidth：表示body元素的宽度（不包括border），即layout viewport的宽度
移动端其他初始化设置
intial-scale:页面首次显示时，可视区域的缩放级别，取值1.0则页面按实际尺寸显示，无任何缩放； no-scalable：是否允许缩放
一个完整的viewport属性的设置为：
上述完整的意思是，layout viewport等于设备的宽度，首次显示页面时不进行缩放也不允许用户缩放；
demo
一开始讲px/dp/dpr/ppi的意义在于铺垫背景知识
理解上述知识后，给你一个移动设备的物理分辨率，如iPhone6 Plus19201080以及尺寸5.5inches，可以计算出其ppi为401->dpr = 3，从而测算出手机的虚拟分辨率为640360px；
原则上，你开发一个640*360px的元素就可以填充整个手机屏幕，但是由于viewport机制作用，效果未达预期
由此引出viewport概念，viewport可以分为visual viewport（视窗尺寸）和layout viewport（放置页面的“幕布“），iPhone6 Plus默认值为980px；
通过meta标签的viewport属性，可以动态设置layout viewport，实战中只需要设置：
你还可以通过window.innerWidth和document.body.clientWidth（前提是不设置body的宽度）分别获取visual viewport和layout viewport；
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/50464.html
摘要：目录移动端开发的基本观点像素基础知识原理解析弹性布局响应式设计的运用移动端的事件库的使用移动端开发的基本观点移动端开发的意义移动端用户使用量市场需求市场供给公司需要移动端开发人才工资高，就业易涌现大波程序猿到了猴年马月，工资才会 目录 移动端开发的基本观点 像素基础知识 viewport原理解析 弹性布局 响应式设计 1rem的运用 移动端的事件 zepto库的使用 移动端开发的...
摘要：不要再问我的问题系列一不要再问我的指向问题了二不要再问我跨域的问题了移动端适配的问题，一般来说我们都不会去深究，因为这种东西都是配置一次就再也不用管的了，接到设计图就按照祖传套路撸就完事了。 不要再问我XX的问题系列：一、不要再问我this的指向问题了二、不要再问我跨域的问题了 移动端适配的问题，一般来说我们都不会去深究，因为这种东西都是配置一次就再也不用管的了，接到设计图就按照祖传...
摘要：不要再问我的问题系列一不要再问我的指向问题了二不要再问我跨域的问题了移动端适配的问题，一般来说我们都不会去深究，因为这种东西都是配置一次就再也不用管的了，接到设计图就按照祖传套路撸就完事了。 不要再问我XX的问题系列：一、不要再问我this的指向问题了二、不要再问我跨域的问题了 移动端适配的问题，一般来说我们都不会去深究，因为这种东西都是配置一次就再也不用管的了，接到设计图就按照祖传...
摘要：不要再问我的问题系列一不要再问我的指向问题了二不要再问我跨域的问题了移动端适配的问题，一般来说我们都不会去深究，因为这种东西都是配置一次就再也不用管的了，接到设计图就按照祖传套路撸就完事了。 不要再问我XX的问题系列：一、不要再问我this的指向问题了二、不要再问我跨域的问题了 移动端适配的问题，一般来说我们都不会去深究，因为这种东西都是配置一次就再也不用管的了，接到设计图就按照祖传...
摘要：这种使用简单，但是兼容性不太好。这种颜色有阴影，估计过不了设计大佬的那关。最后会把对应的编译出来，这种兼容性好，就是依赖于插件。这种兼容好，但是会和伪类冲突，也是我司采用的方式。 前言 工作以后，大部分的业务工作都是基于移动端H5的，开发过程中学习了很多东西，遇到过许多问题，诸如rememcss pxdevice px等，本文纯属个人的归纳总结，如有问题，请指出亲喷~ PC端 本文主要...
阅读 1518·2023-04-25 17:41
阅读 3040·2021-11-22 15:08
阅读 842·2021-09-29 09:35
阅读 1604·2021-09-27 13:35
阅读 3322·2021-08-31 09:44
阅读 2715·2019-08-30 13:20
阅读 1937·2019-08-30 13:00
阅读 2556·2019-08-26 12:12
