> 原文出處：http://www.w3cplus.com/responsive/responsive-images-101-part-9-image-breakpoints.html
我其實很害怕寫[響應式圖片101系列](http://www.w3cplus.com/blog/tags/509.html)里圖片斷點這個部分。選擇圖片斷點每個人都會遇到，坦白說，我也沒有一個好的解決方案。
但我們遲早會遇到圖片斷點的問題。所以不妨現在就開始研究。
## 響應式圖片斷點是什么？
在響應式布局中，斷點代表在某個視口尺寸上改變頁面的布局或功能。通常與媒體查詢相對應。
響應式圖片斷點與此類似但有細微差別。當我在思考圖片斷點時，我會嘗試回答兩個問題：
* 需要提供多少個圖片源來包含此圖片需要使用的場景？
* 在哪里以及什么時候應該使用這些圖片？
這些問題的答案產生的斷點會與響應式布局中標準的斷點不同。在布局中，我遵循Stephen Hay的好方法：改變瀏覽器大小直到頁面看起來很糟糕那么這個時候啊哈，我們需要一個斷點。
然而在[藝術指導](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)中，需要多個圖片源的原因和圖片在什么瀏覽器尺寸下看起來很糟糕并無關系。我們想提供多個圖片源是基于表現考慮，不同尺寸屏幕的分辨率等其他原因。
因此我們不能在圖片上機械重復使用響應式布局斷點。或者我猜也許是可以，但是如果這樣做的話，那就和我們使用響應式圖片的初衷背道而馳了。
## 藝術指導的圖片斷點相對簡單
在[藝術指導使用情況中](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)，藝術指導本身會告訴我們需要多少個圖片源并且什么時候應該使用。
回顧Nokia瀏覽器網頁的例子，我們可以知道圖片應該在什么時候從風景模式轉為肖像模式。發生轉換時，需要一個新圖片源。
然而，這也許只是圖片的一部分。如果藝術指導的某一張圖片包含了大范圍的尺寸呢。我們會發現仍然需要與藝術指導切換不對應的多個圖片源。
可以在[第8部分](http://www.w3cplus.com/responsive/responsive-images-101-part-8-css-images.html)提到的Shopify首頁看到看到這個例子。
雖然圖片只有一個主要的藝術指導切換變化－從全尺寸的圖片變成裁剪的版本－Shopify仍然提供了6個圖片源說明圖片尺寸和顯示器分辨率。
~~~
<picture>
<source srcset="homepage-person@desktop.png, homepage-person@desktop-2x.png 2x"
media="(min-width: 990px)">
<source srcset="homepage-person@tablet.png, homepage-person@tablet-2x.png 2x"
media="(min-width: 750px)">
<img srcset="homepage-person@mobile.png, homepage-person@mobile-2x.png 2x"
alt="Shopify Merchant, Corrine Anestopoulos">
</picture>
~~~
了解圖片在藝術指導使用情況下的表現讓我們得到一些結論，但仍然沒法回答關于必要圖片斷點的所有問題。
## 分辨率切換斷點
這就是事情變得有技巧的地方。至少藝術指導給了我們一些關于需要多少圖片源的提示。
當拉伸自適應圖片時，它們總是表現良好。不能指望它們表現變差來告訴我們什么時候需要改變圖片源。
來看一下分辨率切換的例子：
在這里例子中，當前頁面視口尺寸中一張Michelle Obama的照片的尺寸為`400px?x 602px`。這張圖片的最大尺寸要在`2000px?x 3010px`的分辨率下才會顯示。最大文件的大小為`250K`。
可以直接縮放這張`2000px`的圖片，并且它會表現良好。但是尺寸過大。如果提供一個小版本的圖片例如分辨率`800px?x 1024px`會顯得更好。圖片尺寸僅為`73K`。
我們都同意當頁面中圖片尺寸僅為`400px?x 602px`時，提供一張分辨率為`800px?x 1024px`大小為`73K`的圖片會比下載最大尺寸的圖片更好。
但為什么要止步于800×1204呢？
如果我們提供另一張尺寸為`600px × 903px`的圖片源，大小只有`42K`。這比`800px × 1024px`大小的圖片節約了`31K`（`42％`）。
很棒。`42%`的空間節約是很大的進步。也許我們應該更進一步。如果是`500px`寬呢？`450px`寬呢？
每個更小尺寸的圖片都可能比之前的尺寸更節約空間。如果繼續這種方式，最終會達到頁面上這張圖片的精確尺寸。
那么這里有一個令人困擾的關于圖片斷點的問題。如何確定當前頁面使用的圖片尺寸的文件大小太大了呢？
答案是除非圖片源完全匹配圖片顯示在頁面上的尺寸，否則它總是過大的。總是有機會提供更小尺寸的圖片來優化。
## 為什么不提供精確的圖片尺寸呢？
在這一點上，你也許會疑惑為什么不直接提供在頁面中使用圖片的精確尺寸呢。
首先，響應式設計中設定自適應圖片斷點的目的是讓圖片隨著視口改變而伸縮。如果提供頁面中使用圖片的精確尺寸，不論是視口尺寸改變還是設備旋轉都需要下載新圖片。
其次，提供任何能想到尺寸的圖片是不可能的。是的，我們可以動態改變圖片尺寸，但與此同時，服務器需要處理這些工作就會拖慢分發圖片到瀏覽器的速度。
因此，大多數網站把圖片緩存在內容分發網絡（CDN）上。要把每個尺寸的圖片緩存在CDN上是非常昂貴的。
最后，[瀏覽器在開始下載時并不知道頁面中圖片的確切尺寸](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)。這就是最初讓我們制定響應式圖片新標準的原因。
## 選擇圖片斷點的可行方法
像開始提到的那樣，我沒有絕對可靠的關于如何選擇需要圖片源數量的方案。相反，我想闡述一些看待這個問題的不同方式來幫助你做決定。
## 讓它飛起來（又叫做，匹配布局的斷點）
你團隊中的某些人會說，“嗨，你覺得這些產品圖片需要多少圖片源？”
你猶豫了一會兒說，“3個怎么樣？小，中，大。”
如果你已經這么做了也不要羞澀。我很確定現在大部分使用響應式圖片的人已經這么做了。
也許你的考量中需要兼容手機，平板和桌面也就是小，中，大屏幕。
或者你考慮到圖片會顯示的范圍并估計一下。也許你只是簡單看一下主流的斷點數量然后決定同樣處理圖片斷點。
我完全理解。顯然這比給所有視口提供一張大圖片要好。
當然如果我們的決定更有邏輯會更好。
## 測試響應式圖片
可能猜測聽起來也不是很奇怪，讓我們在選擇圖片斷點中加入一些科學成分。我們來看一些響應式圖片并計算出它們需要多少斷點。
這件事情最難的部分是限制響應式圖片，或計算出總共有多少個圖片。
對于一些網站，所有照片可能按照品牌有特定樣式。如果是這種情況，很容易找到具體的有代表性的圖片。選擇一些圖片改變尺寸并保存最大和最小圖片間的尺寸直到你認為已經得到了合適的范圍。
當然，如果你的網站有多種多樣的圖片樣式，找到具有代表性的圖片幾乎是不可能的。
## 內存消耗對圖片斷點分布的影響
今年夏天早些時候，[Tim Kadlec](http://timkadlec/)發表了一個關于[手機圖片過程](https://www.youtube.com/watch?v=jP68rCjSSjM)的演講。在這個演講中，他主要研究了響應式設計中自適應圖片的內存開銷。
Tim展示了隨著圖片增大，改變圖片尺寸的影響也變大了。
在上述例子中，在每個方向上將一張`600px × 600px`的圖片減少`50px`會導致`230000b`的浪費相比于用同樣方式將`200px × 200px`減少`50px`只有`70000b`的浪費。
這一點給我們提供了一些選擇斷點的參考。并不是要使斷點均勻分布，在圖片變大時應該增加更多斷點。
不幸的是，雖然這一點告訴我們大尺寸圖片需要更多斷點，我們依然不知道具體在哪里需要這些斷點。
## 基于績效預算設置圖片斷點
如果我們把績效預算的靈感應用到響應式圖片？這樣會看起來如何呢？
我們給浪費的比特數定義一定數量的預算，瀏覽器下載適應當前頁面的圖片時可以在這范圍內造成一定的比特浪費。
因此我們決定每個響應式圖片的績效預算為`20K`。這意味著必須確保定義的各種圖片源都小于`20K`。
這樣做后，我們發現圖片斷點基于視覺多樣性發生了巨大的改變并且使用了壓縮。
讓我們來看三張樣例圖片。
### 時代廣場－8個圖片斷點
這張圖片的視覺多樣性豐富。顏色和紋理變化意味著無法在保證圖片質量的情況下進行很大程度的JPEG無損壓縮。
因此，這張圖有8個圖片斷點－以20k為間隔設置－最小圖片尺寸為（`320×213`），最大圖片尺寸為（`990×660`）。
| Breakpoint # | Width | Height | File Size |
| --- | --- | --- | --- |
| [1](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-320x213.jpg) | 320 | 213 | 25K |
| [2](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-453x302.jpg) | 453 | 302 | 44K |
| [3](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-579x386.jpg) | 579 | 386 | 65K |
| [4](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-687x458.jpg) | 687 | 458 | 85K |
| [5](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-786x524.jpg) | 786 | 524 | 104K |
| [6](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-885x590.jpg) | 885 | 590 | 124K |
| [7](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-975x650.jpg) | 975 | 650 | 142K |
| [8](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square.jpg) | 990 | 660 | 151K |
### 凱特林的早晨－3個圖片斷點
不像時代廣場的圖片，這張圖片很多地方顏色非常相似并且紋理很少。因此，JPEG能更好得壓縮這張圖片。
在一張能被良好壓縮的圖片上，20K的預算可以更進一步。對于這張圖片，我們只需要三個圖片斷點來覆蓋這張圖片會使用的所有尺寸區間。
| Breakpoint # | Width | Height | File Size |
| --- | --- | --- | --- |
| [1](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/kettering-sky-320x213.jpg) | 320 | 213 | 9.0K |
| [2](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/kettering-sky-731x487.jpg) | 731 | 487 | 29K |
| [3](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/kettering-sky.jpg) | 990 | 660 | 40K |
### 微軟logo－1個圖片斷點**
這是一張簡單的PNG8文件。最大尺寸（`990×660`）的大小僅為`13K`。因此，它不用做任何改變就適合我們的`20K`預算。
| Breakpoint # | Width | Height | File Size |
| --- | --- | --- | --- |
| [1](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/Microsoft_Logo.png) | 990 | 660 | 13K |
來看一下我們創建的[樣例頁面](http://cloudfour.com/examples/image-breakpoints/)上的其他圖片。了解斷點數量如何變化即便所有圖片開始時分辨率相同且最終斷點相同。
現在，我并沒有建議大家手動決定每個圖片的斷點。但是未來你可以在服務器上聲明20K的響應式圖片預算然后讓服務器計算每張圖片的圖片源數量。
我過去已經寫過了更多關于[響應式圖片的績效預算](http://blog.cloudfour.com/sensible-jumps-in-responsive-image-file-sizes/)內容的細節。如果你最終施行了這個方法，請告訴我。
## 基于請求的頻繁程度設置圖片斷點
最近的[響應式圖片討論組（RICG）](http://responsiveimages.org/)中，[Yoav Weiss](http://blog.yoav.ws/)?和?[Ilya Grigori](https://www.igvita.com/)討論了一個基于圖片尺寸請求的頻繁程度來選擇圖片斷點的方式。
對于在Akamai工作的Yoav和在Google工作的lily來說，他們對于多圖片的一個共同問題在于把這些源都存在[邊緣服務器](http://www.nczonline.net/blog/2011/11/29/how-content-delivery-networks-cdns-work/)上然而存儲空間通常有限制并且代價更加昂貴。
不光是像Akamai和Google這樣的公司想要減少邊緣服務器上存儲的圖片數量，它們內容分發網絡的整個目的都是減少人們耗費在web頁面渲染上的時間。
因此，如果能夠把請求最頻繁的圖片尺寸緩存在邊緣服務器，它們會給大多數用戶帶來最快的分發體驗。
對于這些組織，他們可以把圖片處理和斷點邏輯與分析系統聯系起來并且一旦發現新的圖片尺寸被更頻繁得請求后便改變圖片的尺寸。
當把它與Ilya已經實現新[HTTP客戶端提示](https://tools.ietf.org/html/draft-grigorik-http-client-hints-03)特性結合起來時，服務器對于如何在CDN上保存圖片會變的非常聰明，這樣做的話很少需要設計師和開發來做決策。
## 人們不應該手動去做
我相信在短短幾年內，沒有人會再談論選擇響應式圖片斷點因為沒有人會再手動去做。
當然，我們仍然會對藝術指導使用情況的圖片作出決定，但即便是這個情況，我們當然不會給每個圖片源做決定。我們只處理需要介入的部分然后讓圖片處理服務解決剩余部分。
根據績效預算或不同尺寸的請求頻繁程度來選擇圖片源都有一大堆好處。但這些解決方案作為手動工作流的一部分都站不住腳。
未來，我們的工作流也許是將最高品質的圖片上傳到內容管理系統或圖片處理系統并且再也不要關心。
[這個系列](http://www.w3cplus.com/blog/tags/509.html)一開始有9個部分，但是討論響應式圖片時總有許多要說。最后補允一篇，用來總結響應式圖片的使用。
