(九)：圖片斷點

原文出處：http://www.w3cplus.com/responsive/responsive-images-101-part-9-image-breakpoints.html

我其實很害怕寫響應式圖片101系列里圖片斷點這個部分。選擇圖片斷點每個人都會遇到，坦白說，我也沒有一個好的解決方案。

但我們遲早會遇到圖片斷點的問題。所以不妨現(xiàn)在就開始研究。

響應式圖片斷點是什么？

在響應式布局中，斷點代表在某個視口尺寸上改變頁面的布局或功能。通常與媒體查詢相對應。

響應式圖片斷點與此類似但有細微差別。當我在思考圖片斷點時，我會嘗試回答兩個問題：

• 需要提供多少個圖片源來包含此圖片需要使用的場景？
• 在哪里以及什么時候應該使用這些圖片？

這些問題的答案產(chǎn)生的斷點會與響應式布局中標準的斷點不同。在布局中，我遵循Stephen Hay的好方法：改變?yōu)g覽器大小直到頁面看起來很糟糕那么這個時候啊哈，我們需要一個斷點。

然而在藝術指導中，需要多個圖片源的原因和圖片在什么瀏覽器尺寸下看起來很糟糕并無關系。我們想提供多個圖片源是基于表現(xiàn)考慮，不同尺寸屏幕的分辨率等其他原因。

因此我們不能在圖片上機械重復使用響應式布局斷點?；蛘呶也乱苍S是可以，但是如果這樣做的話，那就和我們使用響應式圖片的初衷背道而馳了。

藝術指導的圖片斷點相對簡單

在藝術指導使用情況中，藝術指導本身會告訴我們需要多少個圖片源并且什么時候應該使用。

回顧Nokia瀏覽器網(wǎng)頁的例子，我們可以知道圖片應該在什么時候從風景模式轉(zhuǎn)為肖像模式。發(fā)生轉(zhuǎn)換時，需要一個新圖片源。

然而，這也許只是圖片的一部分。如果藝術指導的某一張圖片包含了大范圍的尺寸呢。我們會發(fā)現(xiàn)仍然需要與藝術指導切換不對應的多個圖片源。

可以在第8部分提到的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>

了解圖片在藝術指導使用情況下的表現(xiàn)讓我們得到一些結(jié)論，但仍然沒法回答關于必要圖片斷點的所有問題。

分辨率切換斷點

這就是事情變得有技巧的地方。至少藝術指導給了我們一些關于需要多少圖片源的提示。

當拉伸自適應圖片時，它們總是表現(xiàn)良好。不能指望它們表現(xiàn)變差來告訴我們什么時候需要改變圖片源。

來看一下分辨率切換的例子：

在這里例子中，當前頁面視口尺寸中一張Michelle Obama的照片的尺寸為400px?x 602px。這張圖片的最大尺寸要在2000px?x 3010px的分辨率下才會顯示。最大文件的大小為250K。

可以直接縮放這張2000px的圖片，并且它會表現(xiàn)良好。但是尺寸過大。如果提供一個小版本的圖片例如分辨率800px?x 1024px會顯得更好。圖片尺寸僅為73K。

我們都同意當頁面中圖片尺寸僅為400px?x 602px時，提供一張分辨率為800px?x 1024px大小為73K的圖片會比下載最大尺寸的圖片更好。

但為什么要止步于800×1204呢？

如果我們提供另一張尺寸為600px × 903px的圖片源，大小只有42K。這比800px × 1024px大小的圖片節(jié)約了31K（42％）。

很棒。42%的空間節(jié)約是很大的進步。也許我們應該更進一步。如果是500px寬呢？450px寬呢？

每個更小尺寸的圖片都可能比之前的尺寸更節(jié)約空間。如果繼續(xù)這種方式，最終會達到頁面上這張圖片的精確尺寸。

那么這里有一個令人困擾的關于圖片斷點的問題。如何確定當前頁面使用的圖片尺寸的文件大小太大了呢？

答案是除非圖片源完全匹配圖片顯示在頁面上的尺寸，否則它總是過大的?？偸怯袡C會提供更小尺寸的圖片來優(yōu)化。

為什么不提供精確的圖片尺寸呢？

在這一點上，你也許會疑惑為什么不直接提供在頁面中使用圖片的精確尺寸呢。

首先，響應式設計中設定自適應圖片斷點的目的是讓圖片隨著視口改變而伸縮。如果提供頁面中使用圖片的精確尺寸，不論是視口尺寸改變還是設備旋轉(zhuǎn)都需要下載新圖片。

其次，提供任何能想到尺寸的圖片是不可能的。是的，我們可以動態(tài)改變圖片尺寸，但與此同時，服務器需要處理這些工作就會拖慢分發(fā)圖片到瀏覽器的速度。

因此，大多數(shù)網(wǎng)站把圖片緩存在內(nèi)容分發(fā)網(wǎng)絡（CDN）上。要把每個尺寸的圖片緩存在CDN上是非常昂貴的。

最后，瀏覽器在開始下載時并不知道頁面中圖片的確切尺寸。這就是最初讓我們制定響應式圖片新標準的原因。

選擇圖片斷點的可行方法

像開始提到的那樣，我沒有絕對可靠的關于如何選擇需要圖片源數(shù)量的方案。相反，我想闡述一些看待這個問題的不同方式來幫助你做決定。

讓它飛起來（又叫做，匹配布局的斷點）

你團隊中的某些人會說，“嗨，你覺得這些產(chǎn)品圖片需要多少圖片源？”

你猶豫了一會兒說，“3個怎么樣？小，中，大?！?/p>

如果你已經(jīng)這么做了也不要羞澀。我很確定現(xiàn)在大部分使用響應式圖片的人已經(jīng)這么做了。

也許你的考量中需要兼容手機，平板和桌面也就是小，中，大屏幕。

或者你考慮到圖片會顯示的范圍并估計一下。也許你只是簡單看一下主流的斷點數(shù)量然后決定同樣處理圖片斷點。

我完全理解。顯然這比給所有視口提供一張大圖片要好。

當然如果我們的決定更有邏輯會更好。

測試響應式圖片

可能猜測聽起來也不是很奇怪，讓我們在選擇圖片斷點中加入一些科學成分。我們來看一些響應式圖片并計算出它們需要多少斷點。

這件事情最難的部分是限制響應式圖片，或計算出總共有多少個圖片。

對于一些網(wǎng)站，所有照片可能按照品牌有特定樣式。如果是這種情況，很容易找到具體的有代表性的圖片。選擇一些圖片改變尺寸并保存最大和最小圖片間的尺寸直到你認為已經(jīng)得到了合適的范圍。

當然，如果你的網(wǎng)站有多種多樣的圖片樣式，找到具有代表性的圖片幾乎是不可能的。

內(nèi)存消耗對圖片斷點分布的影響

今年夏天早些時候，Tim Kadlec發(fā)表了一個關于手機圖片過程的演講。在這個演講中，他主要研究了響應式設計中自適應圖片的內(nèi)存開銷。

Tim展示了隨著圖片增大，改變圖片尺寸的影響也變大了。

在上述例子中，在每個方向上將一張600px × 600px的圖片減少50px會導致230000b的浪費相比于用同樣方式將200px × 200px減少50px只有70000b的浪費。

這一點給我們提供了一些選擇斷點的參考。并不是要使斷點均勻分布，在圖片變大時應該增加更多斷點。

不幸的是，雖然這一點告訴我們大尺寸圖片需要更多斷點，我們依然不知道具體在哪里需要這些斷點。

基于績效預算設置圖片斷點

如果我們把績效預算的靈感應用到響應式圖片？這樣會看起來如何呢？

我們給浪費的比特數(shù)定義一定數(shù)量的預算，瀏覽器下載適應當前頁面的圖片時可以在這范圍內(nèi)造成一定的比特浪費。

因此我們決定每個響應式圖片的績效預算為20K。這意味著必須確保定義的各種圖片源都小于20K。

這樣做后，我們發(fā)現(xiàn)圖片斷點基于視覺多樣性發(fā)生了巨大的改變并且使用了壓縮。

讓我們來看三張樣例圖片。

時代廣場－8個圖片斷點

這張圖片的視覺多樣性豐富。顏色和紋理變化意味著無法在保證圖片質(zhì)量的情況下進行很大程度的JPEG無損壓縮。

因此，這張圖有8個圖片斷點－以20k為間隔設置－最小圖片尺寸為（320×213），最大圖片尺寸為（990×660）。

凱特林的早晨－3個圖片斷點

不像時代廣場的圖片，這張圖片很多地方顏色非常相似并且紋理很少。因此，JPEG能更好得壓縮這張圖片。

在一張能被良好壓縮的圖片上，20K的預算可以更進一步。對于這張圖片，我們只需要三個圖片斷點來覆蓋這張圖片會使用的所有尺寸區(qū)間。

微軟logo－1個圖片斷點**

這是一張簡單的PNG8文件。最大尺寸（990×660）的大小僅為13K。因此，它不用做任何改變就適合我們的20K預算。

來看一下我們創(chuàng)建的樣例頁面上的其他圖片。了解斷點數(shù)量如何變化即便所有圖片開始時分辨率相同且最終斷點相同。

現(xiàn)在，我并沒有建議大家手動決定每個圖片的斷點。但是未來你可以在服務器上聲明20K的響應式圖片預算然后讓服務器計算每張圖片的圖片源數(shù)量。

我過去已經(jīng)寫過了更多關于響應式圖片的績效預算內(nèi)容的細節(jié)。如果你最終施行了這個方法，請告訴我。

基于請求的頻繁程度設置圖片斷點

最近的響應式圖片討論組（RICG）中，Yoav Weiss?和?Ilya Grigori討論了一個基于圖片尺寸請求的頻繁程度來選擇圖片斷點的方式。

對于在Akamai工作的Yoav和在Google工作的lily來說，他們對于多圖片的一個共同問題在于把這些源都存在邊緣服務器上然而存儲空間通常有限制并且代價更加昂貴。

不光是像Akamai和Google這樣的公司想要減少邊緣服務器上存儲的圖片數(shù)量，它們內(nèi)容分發(fā)網(wǎng)絡的整個目的都是減少人們耗費在web頁面渲染上的時間。

因此，如果能夠把請求最頻繁的圖片尺寸緩存在邊緣服務器，它們會給大多數(shù)用戶帶來最快的分發(fā)體驗。

對于這些組織，他們可以把圖片處理和斷點邏輯與分析系統(tǒng)聯(lián)系起來并且一旦發(fā)現(xiàn)新的圖片尺寸被更頻繁得請求后便改變圖片的尺寸。

當把它與Ilya已經(jīng)實現(xiàn)新HTTP客戶端提示特性結(jié)合起來時，服務器對于如何在CDN上保存圖片會變的非常聰明，這樣做的話很少需要設計師和開發(fā)來做決策。

人們不應該手動去做

我相信在短短幾年內(nèi)，沒有人會再談論選擇響應式圖片斷點因為沒有人會再手動去做。

當然，我們?nèi)匀粫λ囆g指導使用情況的圖片作出決定，但即便是這個情況，我們當然不會給每個圖片源做決定。我們只處理需要介入的部分然后讓圖片處理服務解決剩余部分。

根據(jù)績效預算或不同尺寸的請求頻繁程度來選擇圖片源都有一大堆好處。但這些解決方案作為手動工作流的一部分都站不住腳。

未來，我們的工作流也許是將最高品質(zhì)的圖片上傳到內(nèi)容管理系統(tǒng)或圖片處理系統(tǒng)并且再也不要關心。

這個系列一開始有9個部分，但是討論響應式圖片時總有許多要說。最后補允一篇，用來總結(jié)響應式圖片的使用。