移动端开发系列——像素与viewport

目录

  • 移动端开发的基本观点
  • 像素基础知识
  • viewport原理解析
  • 弹性布局
  • 响应式设计
  • 1rem的运用
  • 移动端的事件
  • zepto库的使用

移动端开发的基本观点
  1. 移动端开发的认识
    移动端开发就是手机端开发吗?
    No、No、No...
    移动端是一个大的范畴,小羊认为应该包括智能手机、平板在内的移动设备,主要是这两者;

  2. 移动端开发入门的学习路径
    目录就是


像素基础知识

先抛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,是超高清屏;

到目前为止,我们了解到:
给你一个显示设备,设备分辨率为19201080,尺寸为5.5英寸,可以计算出其ppi = 401,根据ppi得知其dpr = 3,
由此可以该设备1px = (3^2)dp,其虚拟像素为1920/3 = 660px,1080/3 = 360px,即虚拟分辨率为360
660;
此时,如果你在代码设置元素的宽高为360*660到的话,会发现它的实际尺寸就等于肾6Plus的屏幕尺寸;
【ppi】


viewport原理解析

一个很有意思的现象是,当你把上面的代码在chrome下使用设备模拟方式,模拟肾6Plus的时候,神奇的事情发生了,该元素设置的宽高明明就是手机的宽高,按常理应该占据整个屏幕,实际却是:

究竟是怎么一回事?,如何解决这一问题呢?

好吧,作为实用主义者的你们(不是我哟),先讲解决方案:

在meta标签有一个viewport的属性,可以为这个属性设置width;
肾6Plus默认的width是980px,所以元素宽是360px,实际显示的尺寸是360px*360/980=132.24px(不信可以自己测试一下哟);

现在只要将viewport的width设置为360px,那么元素就可以占满全屏了;

现在就要引入另一个概念:viewport

viewport的原理在于:

  1. 先将页面渲染在一个width为显示设备默认尺寸的viewport上,如肾6Plus为980px;
  2. 然后将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,即<meta name="viewport" content="width=360">,让整个layout viewport就是360px,那么元素将填充整个屏幕;

以上都是世界观,给人一些概念性的理解,无法实操,下面就是方法论

实际移动端开发,我们只需关注layout viewport,知道每个移动设备提供给我们多大尺寸的幕布,但是移动设备型号那么多,不可能一个个手动设置width呀!!!

  • 动态设置layout viewport
<meta  name="viewport" content="width=device-width">

上面的设置表示让layout viewport总是等于设备宽度,即visual viewport;

iPhone 6 Plus
Galaxy S5

【注】细心的童鞋可能会注意到,肾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属性的设置为:

<meta  name="viewport" content="width=device-width,initial-scale=1,no-scalable=no">

上述完整的意思是,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,实战中只需要设置:
<meta  name="viewport" content="width=device-width,initial-scale=1,no-scalable=no">
```,那么你在开发中写元素宽度为360px,实际在手机就显示为360px;
- 你还可以通过`window.innerWidth和document.body.clientWidth(前提是不设置body的宽度)`分别获取visual viewport和layout viewport;

---

下次讲解弹性布局和响应式设计...
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,530评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,403评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,120评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,770评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,758评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,649评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,021评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,675评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,931评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,751评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,410评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,004评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,969评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,042评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,493评论 2 343

推荐阅读更多精彩内容