前端二倍图的思考(涉及Retina)

EXCELL格式

1 csv格式导出来之后不能用EXCELL打开,会乱码。用记事本打开,然后将“(英文的引号出掉),就可以了。

关于二倍图的操作

概念:

设备像素:也叫物理像素,显示设备上最微小的物理部件。 比如 iphone 5:640 x 1136px. 不同的机型有不同的设备像素,固定死的

这里需要讲一下显示分辨率一定的情况下,显示屏越小图像越清晰,反之,显示屏大小固定时,显示分辨率越高图像越清晰。

  • 高分辨率屏幕:在 Windows 系统下,提高屏幕分辨率一般都是通过提高屏幕尺寸。而随着屏幕分辨率的提升,图像和文字显示目标会相应缩小,造成观看极其不便。
    Retina为什么那么小的屏幕会有那么大的分辨率。为什么那么大的分辨率,非但没有使得文字和图像变小,反而更加清晰了呢?
  • 高像素密度屏幕:高ppi, 以评估的 Retina 视网膜屏幕为例,它并不是像普通显示器那样通过增大尺寸来增加分辨率,而是靠提升单位面积屏幕的像素数量,即像素密度来提升分辨率,这样就有了高像素密度屏幕。并且mac采用了矢量字体。

CSS像素: css pixel。抽象概念,设备无关像素。DIPS,device-independent像素。在标准情况下一个CSS像素对应一个设备像素。

body{
width:2px;
height:2px;
}

我们来对比一下这两者的不同

使用css画了一个2 x 2px的盒子,在普通设备屏幕下是2 x 2px的设备像素。但是在Retina的屏幕下去使用了4 x 4px的设备像素。

device-pixel-ratio:在JS中叫做window.devicePixelRatio
公式: window.devicePixelRatio = 设备像素/css像素。这样,非视网膜屏幕的iphone上,屏幕物理像素320像素,独立像素也是320像素,因此window.devicePixelRatio等于1.
但是在视网膜屏幕的iphone上,屏幕物理像素640像素,独立像素还是320像素,因此,window.devicePixelRatio等于2.

屏幕密度: ppi :每英寸有多少的像素。视网膜屏幕:将960*640的分辨率压缩在,一个3.5英寸的显示屏内。也就是说,该屏幕的像素密度达到326像素/英寸(ppi)。当ppi>300的时候肉眼就无法分辨分辨率了。

为什么需要两倍图/多倍图

1 对于位图而言:

  • 当一个光栅图像在标准设备下全屏显示时,一位图像素对应的就是一设备像素,导致一个完全保真的显示。因为一个位置像素不能进一步分裂,
  • 当在Retina屏幕下时,他要放大四倍来保持相同的物理像素的大小,这样就会丢失很多细节,造成失真的情形。换句话说,每一位图像素被乘以四填补相同的物理表面在视网膜屏幕下显示。

工作原理:

方法一:

利用css样式以及放两倍图。

有一张200x200像素的图片(CSS像素,也就是普通像素点或者说是标准像素点),我们给图片设置一个CSS样式:

img{
width:200px;
height:200px;
}

图片模糊的情况:固定好css像素。将width和height固定好。此时在这个width和height 对于不同的显示器包含的像素已经确定了。然后在两种不同屏幕上放图片:那么Ritina屏幕图片会模糊。因为没有css像素的width height所对应Retina显示器的像素数那么多。你硬生生的把这张图片拉成那么大。必然模糊。
在iPad2或Mini iPad中就是很正常显示的图片;但是,在New iPad中,1个CSS像素点实际上有4个位图像素点,1个分成4个,显然不够分啊,只能颜色近似选取,于是,图片感觉就是模糊的。

因此,要想让视网膜屏幕下的图片高清晰显示,我们需要的图片的原始大小不能是200×200像素,而需要2倍高宽,即400×400像素,CSS像素限制依然是:

img {
width:200px;
height:200px;
}

此时,视网膜屏幕下图片就显示OK了(非视网膜屏幕图片被压缩-减少像素取样——资源浪费!)。

方法二:

查询像素密度:准备两种大小但是一样的图片。利用css的媒体查询或者JS的 Retina.js来调取图片。(浏览器支持是一个问题)
1 css:
可以通过“device-pixel-ratio”属性或者其扩展属性“min-device-pixel-ratio”和“max-device-pixel-ratio”。这几个Media Queries可以使用background-image为Retina准备高精密度像素的图片。

.icon {
background-image: url(example.png);
background-size: 200px 300px;
height: 300px;
width: 200px;
}

@media only screen and (-Webkit-min-device-pixel-ratio: 1.5),

only screen and (-moz-min-device-pixel-ratio: 1.5),

only screen and (-o-min-device-pixel-ratio: 3/2),

only screen and (min-device-pixel-ratio: 1.5) {

.icon {

background-image: url([email protected]);

}

}

2 js:
Retina.js 来处理。

方法三:

放缩放的矢量图形(浏览器支持是一个问题)

获得设备像素比后,便可得知设备像素与CSS像素之间的比例。也就是window.devicePixelRatio。
一倍图:当这个比率为1:1时,使用1个设备像素显示1个CSS像素。
二倍图:当这个比率为2:1时,使用4个设备像素显示1个CSS像素,
三倍图:当这个比率为3:1时,使用9(3*3)个设备像素显示1个CSS像素。

原文地址:https://www.cnblogs.com/666666CFH88888888/p/9813340.html

时间: 2024-10-30 14:56:28

前端二倍图的思考(涉及Retina)的相关文章

如何在普清的屏上调试CSS样式二倍图背景

吐槽: 随着现在越来越多人装B,特别是一些产品经理. 现在也在换新的笔记本电脑,苹果的笔记本又是装B利器(特别是retina的pro). 最近就遇到一个同事的项目,还是像平常一样小心切图,认真对像素. 一切测试都没有问题,顺利上线. 但是,上线之后,产品经理跑过来说,有BUG. BUG描述:(不认为是BUG) 前端页面上的图标是虚的. 环境:mackbook pro retina屏 现象: 给了一个截图 图标是虚的 BUG修复要求: 对图标进行修正,使在retina屏上图标依旧是清晰的. 分析:

关于互联网应用前端架构的一些思考

一.互联网应用的分类. 讨论前端架构之前,首先要弄清楚互联网应用的类型,明确了自己的产品所属的类型才能打造属于自己的架构.对互联网产品进行分类,网上有很多不同的观点.我觉得分类是多维度的,但是按照交互以及功能的复杂程度来分类是比较客观的.因此,我比较认同淘宝玉伯在关于前后端开发模式中对应用的分类,以下引用玉伯的观点: 前端涉及的产品形态在业界可分为两大类:Web Pages 和 Web Apps . Web Pages 是浏览类的,用户主要是来看的:以内容展现为主,辅有少量交互.前端提供基础类库

0074 二倍图:物理像素&物理像素比、背景缩放background-size

3.1物理像素&物理像素比 物理像素点指的是屏幕显示的最小颗粒,是物理真实存在的.这是厂商在出厂时就设置好了,比如苹果6 是 750* 1334. 我们开发时候的1px 不是一定等于1个物理像素的. 一个px的能显示的物理像素点的个数,称为物理像素比或屏幕像素比. 如果把1张100*100的图片放到手机里面会按照物理像素比给我们缩放. lRetina(视网膜屏幕)是一种显示技术,可以将把更多的物理像素点压缩至一块屏幕里,从而达到更高的分辨率,并提高屏幕显示的细腻程度. 对于一张 50px * 5

小米前端二面面经

title: 小米前端二面面经 toc: true date: 2018-10-20 13:04:04 categories: Web tags: JavaScript HTTP TCP UDP Cookie 正好都是不会的...所以完整地记录一下. 简单来说就是JS和网络掌握地并不是很全面. JavaScript严格模式 ES5中新增use strict 不允许使用未声明的变量: "use strict"; x = 3.14; // 报错 (x 未定义) "use stri

用一篇文章了解ppi,dpr,物理像素,逻辑像素,以及二倍图

这篇文章能让你了解到什么是分辨率.dpr.dip.ppi (dpi相当于ppi,dpi用点表示物理像素) 首先从最简单的ppi开始: 一部手机,有大有小,怎么知道手机的大小用尺子量一量即可,有两条边量哪一条呢?勾股定理告诉我们斜边越大,面积就越大,量斜边没跑了.量的单位可不是cm,而是英寸.1英寸= 2.54cm,这个相信看过<新华字典>或<现代汉语词典>的人都知道,上面附有计量单位表. 嘿嘿,又引出了一个物理像素的概念:物理像素就是分辨率的那两个数字,两个数字代表了长宽两条边物理

对前端质量保障的思考

我们时时在踩坑,有时也忍不住埋怨前人给我们留下了无数的坑,可回头想想,自己是不是也在挖坑等别人踩... 上次听 赵海平 的讲座,他提到 Facebook 没有测试人员,以前和现在都没有,以后也不打算有.还提到上线之后就开发者坐在系统前等着,只要有bug,系统能够在五分钟之内检测到,并提供快捷方式修复.我惊叹的是他们能够在五分钟之内监控到所有的问题,实时回馈并及时修复. 当然在探讨质量保障这个话题前,我们需要明确几个关键点:编码前.提交代码.测试.上线.回滚.上线后.针对这几个点,下面我谈一谈我的

前端优化带来的思考,浅谈前端工程化

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

前端优化带来的思考,浅谈前端工程化【转】

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

关于测试工具以及前端性能测试的一些思考

对于下一代测试工具的思考. 在以往的性能测试工作中,一直以来使用的测试工具框架都是基于请求-响应模型来进行开发的, 该模型是指脚本通过模拟HTTP请求并接收服务器的响应来针对被测对象的响应时间等考评指标来进行考评. 目前主流的性能测试工具都产生于瘦客户端的时代,而且由于基于的HTTP请求-响应模型本身是很标准的模型, 因此工具更容易做到普适性. 但是很多时候我们测试的结果看着很漂亮,但是实际用户在使用的时候却感觉系统性能糟透了, 抛开场景本身在抽象后与实际场景的差异,这种测试时间和体验时间之间的