響應式web設計之深挖圖像處理技術
注：這篇文章發表于September 30th, 2011 ，作者是Jason Grigsby
在響應式圖像Part 1中，我站在一個比較概況的層面，解釋了什么是響應式圖像，這其中需要解決的問題以及一些共同面臨的議題。在這篇文章中，我會對于響應式圖像中設計的具體技術做一個更詳細的論述，并且來看看這些技術的可用性。如果你還沒有讀過part 1，也許你會想要先讀一下以便了解我在文中用到的一些術語。
當我兩個月以前開始做這個工作的時候，我覺得工作的最后我可以說，“這是最有效的三種方法。去下載它們并整合進你的系統吧。”現在看來，這實在是太天真了。
現在我發現的是并沒有一個綜合的解決方案。相反，我們做了好幾個月實驗，每個實驗都有它的優點與缺點。
因為這個原因，我們應該了解一些通用的元素和挑戰，這樣，對于我們的解決方案中的每個部分，我們就能選擇相應最好的技術了。
被放棄的一些方法
動態庫標簽(Dynamic Base Tag)
很多早期技術都使用Javascript來動態改變庫標簽。新的庫標簽將會在路徑中加入用于指示需要解析的圖像大小的信息。文件加載以后，庫標簽就會移除。
但是，這種方法會遇到我在part 1中所說的race conditions的問題。
(譯者注：關于race conditons，參見http://linux.chinaitlab.com/man/linux/HOWTO/Secure-Programs-HOWTO/avoid-race.html，race condition是由于事件發生的相對時間之間的依賴而引起的異常行為問題。)
我發現Google Chrome會同時下載移動端和桌面端的圖片。Scott Jehl發現這個問題是由于內部和外部Javascript不同處理方式間的區別引起的。他對webkit提交了一個bug，并將其標記為“不可修復”的，原因如下：
插入庫標簽會改變頁面上隨后的所有的URLs。任何腳本都有可能插入一個庫標簽來避免雙重加載，除非有一個掛起的腳本(a pending script)加載，否則不會加載任何事物。這意味著預加載被禁止了，這就脫離了討論范圍了。
在理論上說，你仍然可以使用內聯動態庫標簽，但是Filament Group主要使用的還是基于cookies的辦法，因為這種方法似乎更安全。
暫時的圖像(Temporary images)
另外一個早期的技術是讓圖像的src指向一個暫時的圖像，然后讓Javascript用一個正確的文件路徑來替換這個圖像的源。在大多數情況下，這個圖像是一個一像素的透明的gif圖像，它使用了緩存技術，這樣，無論它在頁面中被引用多少次，瀏覽器都只需要請求一次。
這種技術的問題在于一旦Javascript失效，瀏覽器將永遠不會加載圖像。
基于Javascript的解決方案
你在哪里存儲不同版本圖像的路徑?
如果圖像指向的是‘small.jpg’，那么，對于需要加載大圖像的大屏幕，你將‘large.jpg’的信息放在哪里?
URL參數
一種解決方法是將不同版本圖像的路徑作為url參數放在圖像屬性中。它最簡單的形式如下：
- <img src=”small.jpg?full=large.jpg”>
如果你有好幾個不同大小的圖像，只需要在url中增加一部分值就可以了。這種方法的關鍵在于將其和一個.htaccess文件綁定。
潛在的CDN，代理，以及緩存問題
使用URL參數的最大缺點在于在內容分發網絡以及使用代理(代理在對內容進行緩存的時候不會注意到url參數)的情況下會引起問題。一些緩存算法會忽略任何有url參數的內容，這意味著由于圖像不會被緩存，頁面會變慢。
另外一些緩存算法只會緩存它們看到的第一種版本的圖像。如果使用代理緩存看到圖像的第一個人恰好是在移動終端上看到圖像的，那么隨后使用同樣的代理緩存的人訪問網站的人看到的都將是適用于移動端大小的圖像，不論他們使用什么平臺，除非這樣的緩存過期了。
這在多大程度上會成為一個問題呢?就此我詢問了Steve Souders。他說這足以構成一個問題因此你不能忽略它。這引發了Bryan 和Stephanie Rieger對于緩存和CDNs的一些評論。
因此，我認為我們應該找到一些不需要使用url參數的技術。
這種方法的一些例子：
響應式圖像JS主分支(https://github.com/filamentgroup/Responsive-Images)
響應式圖像切換(https://github.com/allmarkedup/responsive-images-alt )
響應式圖像及能感知上下文的大小改變(http://www.craig-russell.co.uk/responsive-images-and-context-aware-image-sizing/)
使用Doubletake.js的響應式圖像(http://www.grahambird.co.uk/lab/doubletake/ )
使用PHP及jQuery的響應式圖像(http://www.jamesfairhurst.co.uk/posts/view/responsive_images_with_php_and_jquery/)
使用cookies的響應式圖像(http://blog.keithclark.co.uk/responsive-images-using-cookies/ )
感知上下文的響應式圖像(https://github.com/ahume/Responsive-Images )
數據屬性
文件路徑不是放在url參數中，而是放在一個或者更多的數據屬性中。例如：
- <img src=”small.r.jpg” data-fullsrc=”large.jpg”>
哪一個元素要加入數據屬性以及要加入多少都是依賴于具體技術。
循環檢查每一個圖像
我所知道的這種技術的唯一的缺點是需要循環檢查每一個圖像的數據屬性，然后根據屏幕大小修改源屬性。這對于臺式機瀏覽器來說可能不是個大問題，因為在臺式機中是循環被大量使用的地方。
這種方法的一些例子：
響應式圖像基于數據屬性的JS分支(https://github.com/filamentgroup/Responsive-Images/tree/data-attribute-based )
測試響應式圖像(http://www.monoliitti.com/images/ )
使用noscript標記創建響應式圖像(http://www.headlondon.com/our-thoughts/technology/posts/creating-responsive-images-using-the-noscript-tag)
約定的文件存儲結構
在這種方法中，文件路徑不是包含在HTML文件中，而是假定圖像在服務器上是一種約定俗成的方式放置的。例如，所有的小圖像可能都是在/images/sml/文件夾中，而大圖像都是在/images/lrg/圖像中。
如果是這樣的話，html頁面就不用為兩種圖像都提供路徑。它只需要提供圖像的文件名(例如，boat.jpg)，然后讓Javascript來修改圖像源以便與屏幕大小適應(例如，如果是臺式機，圖片源就是/images/lrg/boat.jpg for desktop)。
這種方法的一些例子：
響應式圖像切換(https://github.com/allmarkedup/responsive-images-alt )
自適應的圖像(http://adaptive-images.com/ )
動態文件名
我在part 1中提到我們或許需要任意圖像尺寸。這個問題的一些解決方案是基于一種假設，即你可以通過url傳遞你所想要的大小，然后得到這樣大小的圖像。
因為圖像大小調整是即時完成的，因此沒有必要在Html文件中存儲不同文件路徑。Javascript會修改文件名，將類似于‘boat.jpg’的名字改成‘boat-480×200.jpg’。同時，也不存在緩存或者CDNs的問題，因為任何一個圖像都是獨特的。
有些圖像確實不能被調整大小
這種方法對于人工選擇不同大小的圖像并沒有提供很好的解決方案。它假設大小調整后的圖像能在任何情況下工作，這顯然是不能的。
這種方法的一些例子：
響應式圖像JS中有意義的一些分支(https://github.com/filamentgroup/Responsive-Images/tree/meaningful-base)
響應式圖像及tinySrc(http://blog.trasatti.it/2011/05/responsive-images-and-tinysrc.html )
.htaccess的角色(或類似的重寫規則)
這種解決方案是基于服務器重寫規則的。例子通常是使用Apache 的.htaccess文件寫的，單它們可能是任何類型的重寫規則。
我們來看看一個.htaccess文件的片段(來源于Responsive Images JS cookie-based branch)，來看重寫規則是如何使用的：
RewriteEngine On
#large cookie, large image
RewriteCond %{HTTP_COOKIE} rwd-screensize=large
RewriteCond %{QUERY_STRING} large=([^&]+)
RewriteRule .* %1 [L]
for the url contains a value for large. This .htaccess file is looking for something like:第一條開啟了重寫規則。接下來是一對條件(RewriteCond)。第一個條件檢查是否有一個名為rwd-screensize值為large的cookie。第二個條件檢查url的查詢語句是否包含一個針對大圖像的值。這個.htaccess文件試圖找到一些：
- <img src=”small.jpg?largelarge=large.jpg”>
如果兩個條件都滿足——cookie被設置為針對大圖像且查詢語句中有針對大圖像的值——則重寫規則會發送在查詢語句中指定的文件(在上面的例子中，是large.jpg)。
rwd-screensize的cookie值是通過Javascript測試屏幕大小以后進行設置的。
你如何避免瀏覽器下載好幾個圖像?
排除了一些基本的方式，我們現在開始談論最棘手的部分。正如第1部分所提到的，在瀏覽器開始下載圖像之前攔截瀏覽器，以便可以評估并改變這些圖像的來源是棘手的問題，并可能導致race conditions。
現在，動態庫標簽已被排除，還剩下兩種主要技術。
設置cookie
這是Filament Group為Boston Globe提出的解決方法。在文件頭部加入了Javascript，這樣就能很快做出評估了。
在它決定了屏幕大小以后，它就會設置一個cookie。每個隨后的圖像請求都會包含這個cookie，服務器端可以使用cookie來決定發送給用戶的最好圖像。
可能存在的問題
如果瀏覽器不支持cookie或者用戶禁用了它們，插入到文件頭部的Javascript就不起作用了。
另外，Yoav Weiss做過一些測試，證明IE9在這種情況下仍然會重復下載文件，Firefox在腳本處于外部的時候也會重復下載文件。這意味著cookies可能帶來race condition的問題，而正是這個問題讓我們放棄了動態庫標簽方法。
這種方法的一些例子：
響應式圖像的cookie分支(https://github.com/filamentgroup/Responsive-Images/tree/cookie-driven)
使用cookies的響應式圖像(http://blog.keithclark.co.uk/responsive-images-using-cookies/)
響應式圖像切換(https://github.com/allmarkedup/responsive-images-alt )
#p#
Noscript標記
在過去的幾個月里，使用noscript標記作為一種阻止多余下載的新的技術已經出現了。我看到的第一個使用這種技術的是Mairead Buchan，她描述這種技術有著“涉水河馬的優雅( the elegance of a wading hippo)”。我認為這種技術還是有一定前景的。
Antti Peisa獨立實現了一個更為清晰的noscript方法。下面是html：
- <noscript data-large=’Koala.jpg’ data-small=’Koala-small.jpg’ data-alt=’Koala’>
- <img src=’Koala.jpg’ alt=’Koala’ />
- </noscript>
- The values for the various sizes of image tags are stored in the data attributes on the noscript tag itself. Antti then provides sample jQuery code used to process the image:
- $(‘noscript[data-large][data-small]‘).each(function(){
- var src = screen.width >= 500 ? $(this).data(‘large’) : $(this).data(‘small’);
- $(‘<img src=”‘ + src + ‘” alt=”‘ + $(this).data(‘alt’) + ‘” />’).insertAfter($(this));
- });
這些代碼檢索了整個文件來找到有合適數據屬性的noscript標記。它對屏幕大小進行了測試，然后插入一個有著合適文件路徑的新的圖像標記。
No race conditions!
當使用noscript標記時，沒有給定的race conditions。在noscript標記中的圖像從來不會開始下載。Mairead解釋說“這是有效的，因為noscript標記的孩子不會被添加到DOM中”
這是有道理的。瀏覽器知道在它開始加載頁面之前Javascript是否有效。如果Javascript有效，就不用擔心noscript標記中的項目了。如果它們沒有被添加到DOM中，則它們肯定不會被下載了。
這種技術同樣是有缺點的，當Javascript沒有啟用或者是不依賴于cookies或htaccess文件時，這種方法就不太有效。
可能的陷阱
最大的陷阱是聲稱支持Javascript但是卻實現得很糟糕的設備。例如，黑莓4.5有Javascript，但是Javascript不能操作DOM。在Ergo中，noscript不會被用到因為盡管腳本是可用的，但是腳本不能成功加載一個新的圖像標記，所以沒有圖像會顯示出來。
需要注意的是，這是我的估計。我知道黑莓4.5是如何工作的，但是我并沒有做過實際測試。
盡管這種方法不會引起race condition，但要確保Javascript執行的速度夠快。插進所有這些圖像可能需要瀏覽器將頁面回流(reflow the page)。這也可能導致瀏覽器加載變慢因為它不能預加載。
由于對執行速度有一定需求，因此將jQuery對Antti’s javascript的依賴移除并將代碼放在文件頭部是一種較好的做法。
這種方法的一些例子
使用noscript標記創建響應式圖像（ http://www.headlondon.com/our-thoughts/technology/posts/creating-responsive-images-using-the-noscript-tag)
測試響應式圖像(http://www.monoliitti.com/images/ )
沒有cookies或者服務器端邏輯的響應式的感知上下文的圖像(https://gist.github.com/1200270)
屏幕大小是正確的依據嗎?
這些技術大多數都是依據屏幕大小來決定應該使用什么尺寸的圖像。Andy Hume指出屏幕大小可能是具有誤導性的。他寫到：
解決這個問題的內容驅動的方法是根據圖像是否會被拉伸來決定應該加載什么圖像。如果一個圖像被拉伸了，它看起來就會像素化或者模糊。在這種情形下，我們會想要加載一個粳稻分辨率的圖像。
Andy為響應式圖像提出的解決方案可以解決這個問題(并提供了對nginx的支持)。
波士頓環球時報的響應式圖像失敗了
我期待環球時報的發布有一陣子了，因為它是工程以及設計的壯舉。它的大瀏覽量使得它可以用來測試響應式圖像的不同方法并來看看什么方法才是有效的。
他們選用的技術結合了數據屬性和cookies。不幸的是，環球時報網站上的響應式圖像以及失效了。這個問題大家有目共睹，他們正在想辦法解決。
這一結果的后果是我們還沒有任何一項響應式圖像相關的技術的大規模部署，因此也就不能依靠實踐來證明什么技術是經過實踐檢驗有效的。
Most promising javascript only techniques
在我看來，cookies加上數據源(data-src)以及noscript是最有希望的兩種技術。兩種技術都存在問題，但是與其他方法相比它們的缺陷更少。
Server端的解決方案
大多數Javascript技術都幾乎不需要來自于服務器端的支持。有一些替代方案可以用來平衡服務器端的負載。
用戶代理字符串解析
一些人已經提出了一些解決方案，這些方案包含輕量級的用戶代理字符串解析來區別不同手機。如果用戶代理可以確認是iPhone或者Android，那么也就意味著移動設備是iPhone或者Android，可以根據這個信息來設置合適大小的圖像。
不像其他的很多開發者，在利用用戶代理字符串進行設備檢測時，我沒有遇到什么問題。如果你想要在手機上進行試驗，你需要通過WURFL, Device Atlas等來進行真實的設備檢測。簡單化的正則表達式匹配和有關屏幕尺寸的假設是行不通的。
設備檢測
有幾個不同的方法依靠設備檢測以確定屏幕尺寸并提供適當的圖像。設備檢測數據庫包含了一些基本信息如屏幕尺寸。
Sencha.io Src (舊稱 TinySRC)
James Pearce創建了一個非常棒的服務TinySRC。他后來為Sencha工作，TinySRC成為了Sencha.io Src。Sencha.io Src能自動為你修改圖像大小。你需要在你的圖像標簽中以如下方式引用Sencha.io Src：
http://src.sencha.io/http://www.myapp.com/myimg.jpg
當一個瀏覽器請求了上述地址時，Sencha.io Src會查找發出請求的設備的用戶代理，以決定什么樣的圖像尺寸是合適的。然后它會從你的服務器抓取圖像并修改圖像大小。然后它會將大小修改過以后的圖像進行緩存以便后來的請求可以更快響應。
除了上述的自動模式，Sencha.io Src還可以讓你自己指定圖像修改以后的大小。
將Responsive Images JS與 Sencha.io Src結合
Andrea Trasatti引用了Scott Jehl的Responsive Images JS方法來將Responsive Images JS與Tinysrc結合起來。腳本利用Javascript找到屏幕大小然后使用htaccess來從Sencha.io Src請求正確大小的圖像。
Andrea的這個方法很早就寫成了。它仍然使用動態庫標簽、url參數，并且會引起“對每一個圖像都有一個HTTP請求，這個請求本可能避免的”。但是所有這些缺陷都可以通過結合一些新的方法來修復。
可能的缺陷
首先，如果你對設備檢測有反感的話，那么你就會不太想用Sencha.io Src或者你需要在使用它時來自己指定你想要的圖像大小。
順便說一句，我發現一件很有趣的事情，人們講設備的檢測和用戶代理字符串的壞話，但接下來卻建議使用TinySRC。我曾經看到一個幻燈片，前面駁回了設備檢測，后面的好幾張卻在講TinySRC是多么出色。在一個更為實際的層面，你需要評估一下這個服務是否會長期存在并考慮一下如果所有指向sencha的url突然間消失了會發生什么。我非常了解James，他當然是想要盡可能地讓這個服務永遠運行下去。但盡管如此，一個服務的長期可用性仍然是需要考慮的。
基于WURFL的解決方案
WURFL是最大的開源設備數據庫。在這個月早期參加了突破性的開發(Breaking Development)會議以后，Carson McDonald收到啟發，開發出一個針對圖像的基于WURFL的解決方案。
(順便說一句，突破性的開發(Breaking Development)會議是北美移動網絡相關的最好會議。你可以注冊參加一下。)
Carson指出他的方法在CDN以及及緩存方面會有一些問題，因為不同大小的圖像都是來自于同一個url。
圖像大小修改服務
Google的mod_pagespeed
Google的mod_pagespeed Apache module將很多任務自動化了，并且包含一個選項讓你可以即時剪裁圖像。有很多方式剪裁圖像(GD, ImageMagick等)。我之所以要提出mod_pagespeed是因為我不曾考慮過它，直到在一個論壇看到有人推薦它。我不知道是否有人試過用它來解決響應式圖像的問題。
將客戶端和服務器端的方法結合起來
自適應的圖像
你現在應該已經意識到了，很少有方法是你應用以后就可以高枕無憂的，你還需要做一些小的修改。兩種最接近即插即用的方式是Sencha.io Src和Adaptive-Images.com.
A自適應圖像是由Matt Wilcox開發的。它在頭部修改了響應式圖像的前提，假設頁面的標記包含的是大的圖像而不會從移動設備版本開始啟用。
這種方法包含三部分：
1.一個頭部的小的Javascript片段用來設置有屏幕高度和寬度的cookie。
- <script>document.cookie=’resolution=’+Math.max(screen.width,screen.height)+’; path=/’;</script>
2.一個.htaccess文件將所有的對圖像的請求寫到了一個php文件中。你可以指定不進行此重寫的目錄。
3.一個php文件用來在你自己配置的斷點之上來來圖像大小。
Matt的方法的最好的地方在于你可以將你的圖像文件分開，這樣你就可以排除那些不需要重設大小的圖像，你可以在不對現有方法做任何改變的情況下實現這個技術。現有的頁面會立刻擁有不同的圖像大小。
現在來談談問題
你一定在想一切不會就這么簡單，對嗎?
Matt在下面做出了評論并指出默認的設置會導致如果Javascript缺失的話就會傳送一個小的圖像。該標記將指向一個大的版本，但PHP文件返回一個小的版本。所有這一切都可以配置的。
他同樣指出，race condition的結果不會是下載好幾個圖像。我認為race condition還存在好幾個不同的缺陷，但我還將繼續和Matt進行探討。
我也忽略了一個事實，即不管圖像大小如何，url都是一樣的，這可能導致CDN以及代理緩存方面的問題，就和前面提到的一樣。
Yiibu profile approach
Brian 和 Stephanie Rieger在突破性的開發大會上展示了他們為browser.nokia.com所作的工作。在這個項目中，他們提出了一種新的方式來將客戶端的信息和設備檢測結合起來。
當一個瀏覽器除此從服務器端請求某些東西時，它們對設備一無所知。因此它們就會查詢一個設備檢測數據庫來看是否能得到屏幕大小(以及其他一些細節)。接下來，它們會查詢本地數據庫獲得默認信息。它們利用數據庫中信息來決定瀏覽器工作的細節，發送合適的HTML、Javascript以及圖像。
一旦瀏覽器獲知這些信息，一個Javascript會開始運行來檢測包括屏幕大小在內的瀏覽器的不同方面。然后它將這些信息存儲在一個profile cookie中。
在第二次請求的時候，服務器端會接收到profile cookie并將它與默認數據庫中的信息進行比較。它可能更新默認數據庫。它會將服務器端的信息和客戶端的特征檢測數據結合起來放在一個修訂后的文件(a revised profile)中。
我描述的可能不是特別清楚，你可以看看他們的幻燈片：
◆ 適應：為什么響應式設計是從服務器端開始的(Adaptation: Why responsive design actually begins on the server )
◆ 務實的響應式設計(Pragmatic Responsive Design )
這種混合式技術解決了初次加載的問題，并且不會引起race conditions以及其他一些只依賴于客戶端的方案可能有的問題。這種技術不局限于圖像，還可以用來解決內容以及Javascript上的問題。
聽起來很不錯。有什么收獲?
這是很復雜的系統，需要對架構做很大的改變以獲得支持。Bryan 和Stephanie公布了這個方法，但是代碼還不能夠下載。也許代碼很快就能下載到了，但是他們在這個Nokia Browser project之后享受了一個假期。
也許最大的問題在于我們大多數都不是Riegers。他們已經在移動網絡上開發多年，他們對于設備的默認知識是超群的。天才們的成功總是很難復制的。
同樣的例子還有波士頓環球時報的項目。這個團隊包括jQuery Mobile team的重心力量以及提出了響應式Web設計的人。我們的項目很少能有這樣的配置。
總結
在我回顧這些不同技術的時候，我一直在想Andy Hume在part 1中回復的話：
我們現有的解決方案對于你提到的瀏覽器現有的(以及未定義的)行為有太多依賴。例如，如果某種特定的超前預分析器(a particular type of look-ahead pre-parser (http://goo.gl/TyzTi))在對HTML進行解析或者執行script之前就開始進行下載，那么現有的響應式圖像設計就會失效了。(我隱約覺得我們總有一天會在這個上面跌跟頭。)一種可能的方式是我們和瀏覽器供應商協調以便讓瀏覽器是未來友好的(future-friendly.)。
這的確是事實。這些技術都基于一個期待，即瀏覽器下載事物的順序和我們現在看到的一樣。如果順序改變了或者瀏覽器開始更多地進行預解析了，所有的一切都灰飛煙滅了。
這個系列的第三部分，我將繼續關注改變圖像標簽或者替換它的方法，看有沒有針對多文件源的更好的方法。
一些資源和致謝
這這篇文章中，我敘述了18種不同技術。我的筆記被發表在一個Google spreadsheet中，你可以來查看更為詳細的評論。感謝公布了他們的想法和實驗的每一個人，我從每一個人身上都學到了很多。
這篇文章如果沒有Scott Jehl、 Bryan 和Stephanie Rieger的協助是寫不出來的。尤其是Scott，他幫助我整理出主要的響應式圖像的JS庫的問題。感謝你們三個人，提出了很多真誠的問題，并拿出時間來解釋你們一直以來做的工作。
原文：http://www.cloudfour.com/responsive-imgs-part-2/
譯文：http://www.webapptrend.com/2012/01/1355.html
【編輯推薦】
