在本系列的第1部分中，我讨论了（相当抽象地）图像的"响应"意味着什么。简而言之，响应图像是一种可变图像，它可以适应不同的上下文，以便为用户提供良好的体验，而不管用户的屏幕、浏览器、网络连接或设备如何是的。那自适应可变性多种形式；其中最常见和最具影响力的是自适应、可变的图像分辨率。网络研讨会Fixed和fluibitmap图像具有固定的分辨率：它们包含固定数量的像素。然而，网络上的图像是流动的，它们在布局和屏幕上占据的像素数量可以变化。这里这就是一个例子。假设我们有一个图像--我们想和全世界分享它。我们把它放在一个网站上，然后在我们的电话：看起来相当锋利！为我们的工作感到自豪，我们把网址发给了一个朋友，正好他有一个全新的5K展示：他是的，嗯，没那么令人印象深刻。问题是什么？我们的原始图像的分辨率为800×600，因此，虽然它在我们的750×1334 iphone7屏幕上看起来非常清晰，但是当缩放到适合我们朋友的5120×2880时，它看起来非常模糊怪兽。脆在这个（极端！）上下文需要（很多！）更大的图像：.erics_表{边界塌陷：崩塌；余量：2em自动；}.erics_table td:第一个孩子，.erics_表th{填料：0.25em 0.5em；}埃里克斯表td{填料：0.5em；}.erics_表thead{边框底部：1px实心#eee；}像素分辨率字节800×6000.48 MP66千字节5000×375018.75 MP2.2兆字节为了填满我们朋友的5K屏幕，我们的图像需要大约40倍的数据。这个超大文件本身就超过了一般的网页，优惠券返利，而且除了最快的互联网连接外，加载任何东西都要花很长时间。最糟糕的是，在更小（也更常见）的屏幕上，我们巨大的图像最终会被缩小以适应，而所有这些额外的像素都会被缩小没用。多个，替代版本so–为了利用高分辨率硬件，我们是否应该使用高分辨率图像？或者我们应该使用在低分辨率环境中快速加载的小图像吗？答案，当然，是一个强调"是"的两个，以及两者之间的一切！我们可以而且应该包括我们的图像的多个替代版本，并确保我们只向需要它们的用户发送高分辨率版本，同时仍然向每个人发送低分辨率版本否则，这个概念很简单，大数据的概念，允许开发人员提供这些多个备选方案的HTML特性也很简单；它被称为srcset。但是魔鬼就在细节里-你到底需要多少不同的版本他们的决议应该是什么以及如何智能地从场景中选择并加载其中一个-出奇的狡猾！我们将在转弯。怎么走许多版本，在什么决议？为了更好地服务于不同环境中的用户，我们需要提供多种不同分辨率的图像。但是我们需要多少版本，它们的决议应该是什么？让我们把这个问题分解成更小的部分。我们可以从考虑限制开始：我们需要的最大和最小分辨率是什么？为了解决这个问题，我们需要考虑：在我们的布局中，我们的图像可以放大/缩小到什么大小？我们真正关心的显示器尺寸和密度是多少？一旦我们确定了射程的极限，我们就要想办法把它填满在。为了网络开发者，更多的资源意味着更多管理。为用户，更多的资源意味着更少的浪费。但同时，更多的HTML下载，大数据是啥意思，更少的缓存命中，结果，矛盾的是，速度变慢了装载。如何我们是否应该处理这些相互冲突的优先事项？最初，大多数开发人员都会举手选择或多或少任意的步长（像素）。jasongrigsby率先提出了这样一个想法：我们可以通过使用基于文件大小的步骤来实现这一点。因此，与其拥有600、800和1000像素宽的版本，不如生成重60kb、80kb和100kb的版本kB。为什么？因为不同的图像可能具有令人惊讶的不同的压缩特性，而且在加载过大的图像时，我们更关心的是浪费的字节，而不是浪费的字节像素。云认为这种基于文件大小的"响应图像断点"策略非常聪明，并在中构建了响应图像断点生成器以帮助开发人员实现它。生成器允许您输入一个高分辨率的原始图像，并选择以千字节为单位的最大分辨率、最小分辨率和步长；然后它会生成一整套备用资源，并提供一个方便的下载链接以及将它们全部包含在HTML中所需的标记。整洁！我们已经标记了一组多个备用资源——浏览器应该如何从这些资源中挑选和加载最合适的资源？为了进行选择，浏览器需要知道其中有多少像素盒子：一旦他们要知道，数据分析平台，他们可以选择最能填满盒子的版本。但是！盒子的大小由很多因素决定：视口大小屏幕密度页面布局浏览器始终知道视口大小和屏幕密度。然而，公众号返利系统，页面布局是事情发生的地方黏糊糊的。什么时候加载一个网页并解析它的HTML，浏览器一旦在标记中看到它们的url，就开始加载外部资源（如CSS和图像）。这有利于提高性能—图像字节占web的68%，我们希望尽快开始在网络上移动这些字节。但这对布局感知的图像加载是不利的，因为这意味着浏览器不会、不会、也不能在启动图像加载之前等待布局。"一看到就立即加载"策略意味着，作为web开发人员，我们必须在以下两者之间做出选择：故意延迟图像加载并等待页面布局完成，以便在加载给定图像之前知道实际需要多少像素的分辨率尽快启动图像加载（不知道实际需要多少像素）换言之：我们希望我们的图像具有分辨率响应性，还是立即加载？因为，如果不在等式中添加其他元素，我们就不能两种溶液一些上下文、延迟的、分辨率自适应的大小调整不是问题。如果一个图像是延迟加载的（甚至只是在折叠之下），我们可以等待布局。Cloudinary Javascript库和Alexander Farkas的lazy sizes等库绕过了浏览器的正常图像加载机制，并在布局后使用Javascript响应地加载图像。但是，如果我们想让我们的分辨率响应图像更快，我们就需要使正常的信息流短路。我们需要直接告诉浏览器图像的布局大小标记。这个大小属性的作用。sizes声明以难以阅读而著称，我从痛苦的经历中知道，它们可能很难编写。因为这个属性被明确地设计为打破关注点的分离，并在标记中复制一点布局信息，所以关于大小的最具挑战性的事情可能是维护；布局频繁调整的站点将尤其如此受苦吧因为我喜欢尺寸，尽管困难重重，它解决了我们在知道布局问题之前如何知道布局，直接为浏览器提供了所需的最小信息量，以便他们尽快开始加载分辨率响应图像可能的。作为这样，在使用带有w描述符的srcset属性时需要使用大小，这是标准的（得到普遍支持！）实现分辨率自适应响应的模式图像。有问题，但最有可能的是，分辨率响应图像的实现可能有点棘手，但回报是巨大的。通过提供每个图像的多个版本，并使用Javascript或srcset和大小在其中进行选择，我们可以确保每个用户（无论是在电话上、5K显示器上，还是在两者之间）都能获得一个分辨率刚好足以在其上显示的图像版本显示。加入我们下次再谈另一种重要的图像变化方式：可变图像编码。演示还有更多Cloudinary的官方响应图像文档关于使用srcset、size和Cloudinary的深入教程。介绍Cloudinary基于Javascript的响应图像解决方案。变宽度图像上的Yoav-Weissjasongrigsby的10个部分的responsiveimages101系列的srcset、size和responsiveimage断点部分（上面已经链接了，但是下面又链接了一下，以便更好地度量！）一个由三部分组成的对杰森的采访，关于反应图像的历史和未来。Cloudinary对响应图像断点生成器的介绍和更新。最后，作为一个高级主题，额外的功劳：您的真正关于如何使用w峈auto和客户端提示来解决srcset的复杂性问题。具有Cloudinary的响应图像自动裁剪图像，实现响应式设计，提高图像质量通过3个简单的步骤使网站上的所有图片都能响应响应式Web设计的最佳实践