注：這篇文章發(fā)表于September 30th, 2011 ，作者是Jason Grigsby

在響應(yīng)式圖像Part 1中，我站在一個(gè)比較概況的層面，解釋了什么是響應(yīng)式圖像，這其中需要解決的問題以及一些共同面臨的議題。在這篇文章中，我會(huì)對(duì)于響應(yīng)式圖像中設(shè)計(jì)的具體技術(shù)做一個(gè)更詳細(xì)的論述，并且來看看這些技術(shù)的可用性。如果你還沒有讀過part 1，也許你會(huì)想要先讀一下以便了解我在文中用到的一些術(shù)語。

當(dāng)我兩個(gè)月以前開始做這個(gè)工作的時(shí)候，我覺得工作的最后我可以說，“這是最有效的三種方法。去下載它們并整合進(jìn)你的系統(tǒng)吧。”現(xiàn)在看來，這實(shí)在是太天真了。

現(xiàn)在我發(fā)現(xiàn)的是并沒有一個(gè)綜合的解決方案。相反，我們做了好幾個(gè)月實(shí)驗(yàn)，每個(gè)實(shí)驗(yàn)都有它的優(yōu)點(diǎn)與缺點(diǎn)。

因?yàn)檫@個(gè)原因，我們應(yīng)該了解一些通用的元素和挑戰(zhàn)，這樣，對(duì)于我們的解決方案中的每個(gè)部分，我們就能選擇相應(yīng)最好的技術(shù)了。

被放棄的一些方法

動(dòng)態(tài)庫標(biāo)簽(Dynamic Base Tag)

很多早期技術(shù)都使用Javascript來動(dòng)態(tài)改變庫標(biāo)簽。新的庫標(biāo)簽將會(huì)在路徑中加入用于指示需要解析的圖像大小的信息。文件加載以后，庫標(biāo)簽就會(huì)移除。

但是，這種方法會(huì)遇到我在part 1中所說的race conditions的問題。

(譯者注：關(guān)于race conditons，參見http://linux.chinaitlab.com/man/linux/HOWTO/Secure-Programs-HOWTO/avoid-race.html，race condition是由于事件發(fā)生的相對(duì)時(shí)間之間的依賴而引起的異常行為問題。)

我發(fā)現(xiàn)Google Chrome會(huì)同時(shí)下載移動(dòng)端和桌面端的圖片。Scott Jehl發(fā)現(xiàn)這個(gè)問題是由于內(nèi)部和外部Javascript不同處理方式間的區(qū)別引起的。他對(duì)webkit提交了一個(gè)bug，并將其標(biāo)記為“不可修復(fù)”的，原因如下：

插入庫標(biāo)簽會(huì)改變頁面上隨后的所有的URLs。任何腳本都有可能插入一個(gè)庫標(biāo)簽來避免雙重加載，除非有一個(gè)掛起的腳本(a pending script)加載，否則不會(huì)加載任何事物。這意味著預(yù)加載被禁止了，這就脫離了討論范圍了。

在理論上說，你仍然可以使用內(nèi)聯(lián)動(dòng)態(tài)庫標(biāo)簽，但是Filament Group主要使用的還是基于cookies的辦法，因?yàn)檫@種方法似乎更安全。

暫時(shí)的圖像(Temporary images)

另外一個(gè)早期的技術(shù)是讓圖像的src指向一個(gè)暫時(shí)的圖像，然后讓Javascript用一個(gè)正確的文件路徑來替換這個(gè)圖像的源。在大多數(shù)情況下，這個(gè)圖像是一個(gè)一像素的透明的gif圖像，它使用了緩存技術(shù)，這樣，無論它在頁面中被引用多少次，瀏覽器都只需要請(qǐng)求一次。

這種技術(shù)的問題在于一旦Javascript失效，瀏覽器將永遠(yuǎn)不會(huì)加載圖像。

基于Javascript的解決方案

你在哪里存儲(chǔ)不同版本圖像的路徑?

如果圖像指向的是‘small.jpg’，那么，對(duì)于需要加載大圖像的大屏幕，你將‘large.jpg’的信息放在哪里?

URL參數(shù)

一種解決方法是將不同版本圖像的路徑作為url參數(shù)放在圖像屬性中。它最簡(jiǎn)單的形式如下：

<img src=”small.jpg?full=large.jpg”> 

如果你有好幾個(gè)不同大小的圖像，只需要在url中增加一部分值就可以了。這種方法的關(guān)鍵在于將其和一個(gè).htaccess文件綁定。

潛在的CDN，代理，以及緩存問題

使用URL參數(shù)的最大缺點(diǎn)在于在內(nèi)容分發(fā)網(wǎng)絡(luò)以及使用代理(代理在對(duì)內(nèi)容進(jìn)行緩存的時(shí)候不會(huì)注意到url參數(shù))的情況下會(huì)引起問題。一些緩存算法會(huì)忽略任何有url參數(shù)的內(nèi)容，這意味著由于圖像不會(huì)被緩存，頁面會(huì)變慢。

另外一些緩存算法只會(huì)緩存它們看到的第一種版本的圖像。如果使用代理緩存看到圖像的第一個(gè)人恰好是在移動(dòng)終端上看到圖像的，那么隨后使用同樣的代理緩存的人訪問網(wǎng)站的人看到的都將是適用于移動(dòng)端大小的圖像，不論他們使用什么平臺(tái)，除非這樣的緩存過期了。

這在多大程度上會(huì)成為一個(gè)問題呢?就此我詢問了Steve Souders。他說這足以構(gòu)成一個(gè)問題因此你不能忽略它。這引發(fā)了Bryan 和Stephanie Rieger對(duì)于緩存和CDNs的一些評(píng)論。

因此，我認(rèn)為我們應(yīng)該找到一些不需要使用url參數(shù)的技術(shù)。

這種方法的一些例子：

響應(yīng)式圖像JS主分支(https://github.com/filamentgroup/Responsive-Images)

響應(yīng)式圖像切換(https://github.com/allmarkedup/responsive-images-alt )

響應(yīng)式圖像及能感知上下文的大小改變(http://www.craig-russell.co.uk/responsive-images-and-context-aware-image-sizing/)

使用Doubletake.js的響應(yīng)式圖像(http://www.grahambird.co.uk/lab/doubletake/ )

使用PHP及jQuery的響應(yīng)式圖像(http://www.jamesfairhurst.co.uk/posts/view/responsive_images_with_php_and_jquery/)

使用cookies的響應(yīng)式圖像(http://blog.keithclark.co.uk/responsive-images-using-cookies/ )

感知上下文的響應(yīng)式圖像(https://github.com/ahume/Responsive-Images )

數(shù)據(jù)屬性

文件路徑不是放在url參數(shù)中，而是放在一個(gè)或者更多的數(shù)據(jù)屬性中。例如：

<img src=”small.r.jpg” data-fullsrc=”large.jpg”> 

哪一個(gè)元素要加入數(shù)據(jù)屬性以及要加入多少都是依賴于具體技術(shù)。

循環(huán)檢查每一個(gè)圖像

我所知道的這種技術(shù)的唯一的缺點(diǎn)是需要循環(huán)檢查每一個(gè)圖像的數(shù)據(jù)屬性，然后根據(jù)屏幕大小修改源屬性。這對(duì)于臺(tái)式機(jī)瀏覽器來說可能不是個(gè)大問題，因?yàn)樵谂_(tái)式機(jī)中是循環(huán)被大量使用的地方。

這種方法的一些例子：

響應(yīng)式圖像基于數(shù)據(jù)屬性的JS分支(https://github.com/filamentgroup/Responsive-Images/tree/data-attribute-based )

測(cè)試響應(yīng)式圖像(http://www.monoliitti.com/images/ )

使用noscript標(biāo)記創(chuàng)建響應(yīng)式圖像(http://www.headlondon.com/our-thoughts/technology/posts/creating-responsive-images-using-the-noscript-tag)

約定的文件存儲(chǔ)結(jié)構(gòu)

在這種方法中，文件路徑不是包含在HTML文件中，而是假定圖像在服務(wù)器上是一種約定俗成的方式放置的。例如，所有的小圖像可能都是在/images/sml/文件夾中，而大圖像都是在/images/lrg/圖像中。

如果是這樣的話，html頁面就不用為兩種圖像都提供路徑。它只需要提供圖像的文件名(例如，boat.jpg)，然后讓Javascript來修改圖像源以便與屏幕大小適應(yīng)(例如，如果是臺(tái)式機(jī)，圖片源就是/images/lrg/boat.jpg for desktop)。

這種方法的一些例子：

響應(yīng)式圖像切換(https://github.com/allmarkedup/responsive-images-alt )

自適應(yīng)的圖像(http://adaptive-images.com/ )

動(dòng)態(tài)文件名

我在part 1中提到我們或許需要任意圖像尺寸。這個(gè)問題的一些解決方案是基于一種假設(shè)，即你可以通過url傳遞你所想要的大小，然后得到這樣大小的圖像。

因?yàn)閳D像大小調(diào)整是即時(shí)完成的，因此沒有必要在Html文件中存儲(chǔ)不同文件路徑。Javascript會(huì)修改文件名，將類似于‘boat.jpg’的名字改成‘boat-480×200.jpg’。同時(shí)，也不存在緩存或者CDNs的問題，因?yàn)槿魏我粋€(gè)圖像都是獨(dú)特的。

有些圖像確實(shí)不能被調(diào)整大小

這種方法對(duì)于人工選擇不同大小的圖像并沒有提供很好的解決方案。它假設(shè)大小調(diào)整后的圖像能在任何情況下工作，這顯然是不能的。

這種方法的一些例子：

響應(yīng)式圖像JS中有意義的一些分支(https://github.com/filamentgroup/Responsive-Images/tree/meaningful-base)

響應(yīng)式圖像及tinySrc(http://blog.trasatti.it/2011/05/responsive-images-and-tinysrc.html )

.htaccess的角色(或類似的重寫規(guī)則)

這種解決方案是基于服務(wù)器重寫規(guī)則的。例子通常是使用Apache 的.htaccess文件寫的，單它們可能是任何類型的重寫規(guī)則。

我們來看看一個(gè).htaccess文件的片段(來源于Responsive Images JS cookie-based branch)，來看重寫規(guī)則是如何使用的：

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:第一條開啟了重寫規(guī)則。接下來是一對(duì)條件(RewriteCond)。第一個(gè)條件檢查是否有一個(gè)名為rwd-screensize值為large的cookie。第二個(gè)條件檢查url的查詢語句是否包含一個(gè)針對(duì)大圖像的值。這個(gè).htaccess文件試圖找到一些：

<img src=”small.jpg?largelarge=large.jpg”> 

如果兩個(gè)條件都滿足——cookie被設(shè)置為針對(duì)大圖像且查詢語句中有針對(duì)大圖像的值——則重寫規(guī)則會(huì)發(fā)送在查詢語句中指定的文件(在上面的例子中，是large.jpg)。

rwd-screensize的cookie值是通過Javascript測(cè)試屏幕大小以后進(jìn)行設(shè)置的。

你如何避免瀏覽器下載好幾個(gè)圖像?

排除了一些基本的方式，我們現(xiàn)在開始談?wù)撟罴值牟糠?。正如?部分所提到的，在瀏覽器開始下載圖像之前攔截瀏覽器，以便可以評(píng)估并改變這些圖像的來源是棘手的問題，并可能導(dǎo)致race conditions。

現(xiàn)在，動(dòng)態(tài)庫標(biāo)簽已被排除，還剩下兩種主要技術(shù)。

設(shè)置cookie

這是Filament Group為Boston Globe提出的解決方法。在文件頭部加入了Javascript，這樣就能很快做出評(píng)估了。

在它決定了屏幕大小以后，它就會(huì)設(shè)置一個(gè)cookie。每個(gè)隨后的圖像請(qǐng)求都會(huì)包含這個(gè)cookie，服務(wù)器端可以使用cookie來決定發(fā)送給用戶的最好圖像。

可能存在的問題

如果瀏覽器不支持cookie或者用戶禁用了它們，插入到文件頭部的Javascript就不起作用了。

另外，Yoav Weiss做過一些測(cè)試，證明IE9在這種情況下仍然會(huì)重復(fù)下載文件，F(xiàn)irefox在腳本處于外部的時(shí)候也會(huì)重復(fù)下載文件。這意味著cookies可能帶來race condition的問題，而正是這個(gè)問題讓我們放棄了動(dòng)態(tài)庫標(biāo)簽方法。

這種方法的一些例子：

響應(yīng)式圖像的cookie分支(https://github.com/filamentgroup/Responsive-Images/tree/cookie-driven)

使用cookies的響應(yīng)式圖像(http://blog.keithclark.co.uk/responsive-images-using-cookies/)

響應(yīng)式圖像切換(https://github.com/allmarkedup/responsive-images-alt )

#p#

Noscript標(biāo)記

在過去的幾個(gè)月里，使用noscript標(biāo)記作為一種阻止多余下載的新的技術(shù)已經(jīng)出現(xiàn)了。我看到的第一個(gè)使用這種技術(shù)的是Mairead Buchan，她描述這種技術(shù)有著“涉水河馬的優(yōu)雅( the elegance of a wading hippo)”。我認(rèn)為這種技術(shù)還是有一定前景的。

Antti Peisa獨(dú)立實(shí)現(xiàn)了一個(gè)更為清晰的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));  
}); 

這些代碼檢索了整個(gè)文件來找到有合適數(shù)據(jù)屬性的noscript標(biāo)記。它對(duì)屏幕大小進(jìn)行了測(cè)試，然后插入一個(gè)有著合適文件路徑的新的圖像標(biāo)記。

No race conditions!

當(dāng)使用noscript標(biāo)記時(shí)，沒有給定的race conditions。在noscript標(biāo)記中的圖像從來不會(huì)開始下載。Mairead解釋說“這是有效的，因?yàn)閚oscript標(biāo)記的孩子不會(huì)被添加到DOM中”

這是有道理的。瀏覽器知道在它開始加載頁面之前Javascript是否有效。如果Javascript有效，就不用擔(dān)心noscript標(biāo)記中的項(xiàng)目了。如果它們沒有被添加到DOM中，則它們肯定不會(huì)被下載了。

這種技術(shù)同樣是有缺點(diǎn)的，當(dāng)Javascript沒有啟用或者是不依賴于cookies或htaccess文件時(shí)，這種方法就不太有效。

可能的陷阱

最大的陷阱是聲稱支持Javascript但是卻實(shí)現(xiàn)得很糟糕的設(shè)備。例如，黑莓4.5有Javascript，但是Javascript不能操作DOM。在Ergo中，noscript不會(huì)被用到因?yàn)楸M管腳本是可用的，但是腳本不能成功加載一個(gè)新的圖像標(biāo)記，所以沒有圖像會(huì)顯示出來。

需要注意的是，這是我的估計(jì)。我知道黑莓4.5是如何工作的，但是我并沒有做過實(shí)際測(cè)試。

盡管這種方法不會(huì)引起race condition，但要確保Javascript執(zhí)行的速度夠快。插進(jìn)所有這些圖像可能需要瀏覽器將頁面回流(reflow the page)。這也可能導(dǎo)致瀏覽器加載變慢因?yàn)樗荒茴A(yù)加載。

由于對(duì)執(zhí)行速度有一定需求，因此將jQuery對(duì)Antti’s javascript的依賴移除并將代碼放在文件頭部是一種較好的做法。

這種方法的一些例子

使用noscript標(biāo)記創(chuàng)建響應(yīng)式圖像（ http://www.headlondon.com/our-thoughts/technology/posts/creating-responsive-images-using-the-noscript-tag)

測(cè)試響應(yīng)式圖像(http://www.monoliitti.com/images/ )

沒有cookies或者服務(wù)器端邏輯的響應(yīng)式的感知上下文的圖像(https://gist.github.com/1200270)

屏幕大小是正確的依據(jù)嗎?

這些技術(shù)大多數(shù)都是依據(jù)屏幕大小來決定應(yīng)該使用什么尺寸的圖像。Andy Hume指出屏幕大小可能是具有誤導(dǎo)性的。他寫到：

解決這個(gè)問題的內(nèi)容驅(qū)動(dòng)的方法是根據(jù)圖像是否會(huì)被拉伸來決定應(yīng)該加載什么圖像。如果一個(gè)圖像被拉伸了，它看起來就會(huì)像素化或者模糊。在這種情形下，我們會(huì)想要加載一個(gè)粳稻分辨率的圖像。

Andy為響應(yīng)式圖像提出的解決方案可以解決這個(gè)問題(并提供了對(duì)nginx的支持)。

波士頓環(huán)球時(shí)報(bào)的響應(yīng)式圖像失敗了

我期待環(huán)球時(shí)報(bào)的發(fā)布有一陣子了，因?yàn)樗枪こ桃约霸O(shè)計(jì)的壯舉。它的大瀏覽量使得它可以用來測(cè)試響應(yīng)式圖像的不同方法并來看看什么方法才是有效的。

他們選用的技術(shù)結(jié)合了數(shù)據(jù)屬性和cookies。不幸的是，環(huán)球時(shí)報(bào)網(wǎng)站上的響應(yīng)式圖像以及失效了。這個(gè)問題大家有目共睹，他們正在想辦法解決。

這一結(jié)果的后果是我們還沒有任何一項(xiàng)響應(yīng)式圖像相關(guān)的技術(shù)的大規(guī)模部署，因此也就不能依靠實(shí)踐來證明什么技術(shù)是經(jīng)過實(shí)踐檢驗(yàn)有效的。

Most promising javascript only techniques

在我看來，cookies加上數(shù)據(jù)源(data-src)以及noscript是最有希望的兩種技術(shù)。兩種技術(shù)都存在問題，但是與其他方法相比它們的缺陷更少。

Server端的解決方案

大多數(shù)Javascript技術(shù)都幾乎不需要來自于服務(wù)器端的支持。有一些替代方案可以用來平衡服務(wù)器端的負(fù)載。

用戶代理字符串解析

一些人已經(jīng)提出了一些解決方案，這些方案包含輕量級(jí)的用戶代理字符串解析來區(qū)別不同手機(jī)。如果用戶代理可以確認(rèn)是iPhone或者Android，那么也就意味著移動(dòng)設(shè)備是iPhone或者Android，可以根據(jù)這個(gè)信息來設(shè)置合適大小的圖像。

不像其他的很多開發(fā)者，在利用用戶代理字符串進(jìn)行設(shè)備檢測(cè)時(shí)，我沒有遇到什么問題。如果你想要在手機(jī)上進(jìn)行試驗(yàn)，你需要通過WURFL, Device Atlas等來進(jìn)行真實(shí)的設(shè)備檢測(cè)。簡(jiǎn)單化的正則表達(dá)式匹配和有關(guān)屏幕尺寸的假設(shè)是行不通的。

設(shè)備檢測(cè)

有幾個(gè)不同的方法依靠設(shè)備檢測(cè)以確定屏幕尺寸并提供適當(dāng)?shù)膱D像。設(shè)備檢測(cè)數(shù)據(jù)庫包含了一些基本信息如屏幕尺寸。

Sencha.io Src (舊稱 TinySRC)

James Pearce創(chuàng)建了一個(gè)非常棒的服務(wù)TinySRC。他后來為Sencha工作，TinySRC成為了Sencha.io Src。Sencha.io Src能自動(dòng)為你修改圖像大小。你需要在你的圖像標(biāo)簽中以如下方式引用Sencha.io Src：

http://src.sencha.io/http://www.myapp.com/myimg.jpg

當(dāng)一個(gè)瀏覽器請(qǐng)求了上述地址時(shí)，Sencha.io Src會(huì)查找發(fā)出請(qǐng)求的設(shè)備的用戶代理，以決定什么樣的圖像尺寸是合適的。然后它會(huì)從你的服務(wù)器抓取圖像并修改圖像大小。然后它會(huì)將大小修改過以后的圖像進(jìn)行緩存以便后來的請(qǐng)求可以更快響應(yīng)。

除了上述的自動(dòng)模式，Sencha.io Src還可以讓你自己指定圖像修改以后的大小。

將Responsive Images JS與 Sencha.io Src結(jié)合

Andrea Trasatti引用了Scott Jehl的Responsive Images JS方法來將Responsive Images JS與Tinysrc結(jié)合起來。腳本利用Javascript找到屏幕大小然后使用htaccess來從Sencha.io Src請(qǐng)求正確大小的圖像。

Andrea的這個(gè)方法很早就寫成了。它仍然使用動(dòng)態(tài)庫標(biāo)簽、url參數(shù)，并且會(huì)引起“對(duì)每一個(gè)圖像都有一個(gè)HTTP請(qǐng)求，這個(gè)請(qǐng)求本可能避免的”。但是所有這些缺陷都可以通過結(jié)合一些新的方法來修復(fù)。

可能的缺陷

首先，如果你對(duì)設(shè)備檢測(cè)有反感的話，那么你就會(huì)不太想用Sencha.io Src或者你需要在使用它時(shí)來自己指定你想要的圖像大小。

順便說一句，我發(fā)現(xiàn)一件很有趣的事情，人們講設(shè)備的檢測(cè)和用戶代理字符串的壞話，但接下來卻建議使用TinySRC。我曾經(jīng)看到一個(gè)幻燈片，前面駁回了設(shè)備檢測(cè)，后面的好幾張卻在講TinySRC是多么出色。在一個(gè)更為實(shí)際的層面，你需要評(píng)估一下這個(gè)服務(wù)是否會(huì)長(zhǎng)期存在并考慮一下如果所有指向sencha的url突然間消失了會(huì)發(fā)生什么。我非常了解James，他當(dāng)然是想要盡可能地讓這個(gè)服務(wù)永遠(yuǎn)運(yùn)行下去。但盡管如此，一個(gè)服務(wù)的長(zhǎng)期可用性仍然是需要考慮的。

基于WURFL的解決方案

WURFL是最大的開源設(shè)備數(shù)據(jù)庫。在這個(gè)月早期參加了突破性的開發(fā)(Breaking Development)會(huì)議以后，Carson McDonald收到啟發(fā)，開發(fā)出一個(gè)針對(duì)圖像的基于WURFL的解決方案。

(順便說一句，突破性的開發(fā)(Breaking Development)會(huì)議是北美移動(dòng)網(wǎng)絡(luò)相關(guān)的最好會(huì)議。你可以注冊(cè)參加一下。)

Carson指出他的方法在CDN以及及緩存方面會(huì)有一些問題，因?yàn)椴煌笮〉膱D像都是來自于同一個(gè)url。

圖像大小修改服務(wù)

Google的mod_pagespeed

Google的mod_pagespeed Apache module將很多任務(wù)自動(dòng)化了，并且包含一個(gè)選項(xiàng)讓你可以即時(shí)剪裁圖像。有很多方式剪裁圖像(GD, ImageMagick等)。我之所以要提出mod_pagespeed是因?yàn)槲也辉紤]過它，直到在一個(gè)論壇看到有人推薦它。我不知道是否有人試過用它來解決響應(yīng)式圖像的問題。

將客戶端和服務(wù)器端的方法結(jié)合起來

自適應(yīng)的圖像

你現(xiàn)在應(yīng)該已經(jīng)意識(shí)到了，很少有方法是你應(yīng)用以后就可以高枕無憂的，你還需要做一些小的修改。兩種最接近即插即用的方式是Sencha.io Src和Adaptive-Images.com.

A自適應(yīng)圖像是由Matt Wilcox開發(fā)的。它在頭部修改了響應(yīng)式圖像的前提，假設(shè)頁面的標(biāo)記包含的是大的圖像而不會(huì)從移動(dòng)設(shè)備版本開始啟用。

這種方法包含三部分：

1.一個(gè)頭部的小的Javascript片段用來設(shè)置有屏幕高度和寬度的cookie。

<script>document.cookie=’resolution=’+Math.max(screen.width,screen.height)+’; path=/’;</script> 

2.一個(gè).htaccess文件將所有的對(duì)圖像的請(qǐng)求寫到了一個(gè)php文件中。你可以指定不進(jìn)行此重寫的目錄。

3.一個(gè)php文件用來在你自己配置的斷點(diǎn)之上來來圖像大小。

Matt的方法的最好的地方在于你可以將你的圖像文件分開，這樣你就可以排除那些不需要重設(shè)大小的圖像，你可以在不對(duì)現(xiàn)有方法做任何改變的情況下實(shí)現(xiàn)這個(gè)技術(shù)?，F(xiàn)有的頁面會(huì)立刻擁有不同的圖像大小。

現(xiàn)在來談?wù)剢栴}

你一定在想一切不會(huì)就這么簡(jiǎn)單，對(duì)嗎?

Matt在下面做出了評(píng)論并指出默認(rèn)的設(shè)置會(huì)導(dǎo)致如果Javascript缺失的話就會(huì)傳送一個(gè)小的圖像。該標(biāo)記將指向一個(gè)大的版本，但PHP文件返回一個(gè)小的版本。所有這一切都可以配置的。

他同樣指出，race condition的結(jié)果不會(huì)是下載好幾個(gè)圖像。我認(rèn)為race condition還存在好幾個(gè)不同的缺陷，但我還將繼續(xù)和Matt進(jìn)行探討。

我也忽略了一個(gè)事實(shí)，即不管圖像大小如何，url都是一樣的，這可能導(dǎo)致CDN以及代理緩存方面的問題，就和前面提到的一樣。

Yiibu profile approach

Brian 和 Stephanie Rieger在突破性的開發(fā)大會(huì)上展示了他們?yōu)閎rowser.nokia.com所作的工作。在這個(gè)項(xiàng)目中，他們提出了一種新的方式來將客戶端的信息和設(shè)備檢測(cè)結(jié)合起來。

當(dāng)一個(gè)瀏覽器除此從服務(wù)器端請(qǐng)求某些東西時(shí)，它們對(duì)設(shè)備一無所知。因此它們就會(huì)查詢一個(gè)設(shè)備檢測(cè)數(shù)據(jù)庫來看是否能得到屏幕大小(以及其他一些細(xì)節(jié))。接下來，它們會(huì)查詢本地?cái)?shù)據(jù)庫獲得默認(rèn)信息。它們利用數(shù)據(jù)庫中信息來決定瀏覽器工作的細(xì)節(jié)，發(fā)送合適的HTML、Javascript以及圖像。

一旦瀏覽器獲知這些信息，一個(gè)Javascript會(huì)開始運(yùn)行來檢測(cè)包括屏幕大小在內(nèi)的瀏覽器的不同方面。然后它將這些信息存儲(chǔ)在一個(gè)profile cookie中。

在第二次請(qǐng)求的時(shí)候，服務(wù)器端會(huì)接收到profile cookie并將它與默認(rèn)數(shù)據(jù)庫中的信息進(jìn)行比較。它可能更新默認(rèn)數(shù)據(jù)庫。它會(huì)將服務(wù)器端的信息和客戶端的特征檢測(cè)數(shù)據(jù)結(jié)合起來放在一個(gè)修訂后的文件(a revised profile)中。

我描述的可能不是特別清楚，你可以看看他們的幻燈片：

◆ 適應(yīng)：為什么響應(yīng)式設(shè)計(jì)是從服務(wù)器端開始的(Adaptation: Why responsive design actually begins on the server )

◆ 務(wù)實(shí)的響應(yīng)式設(shè)計(jì)(Pragmatic Responsive Design )

這種混合式技術(shù)解決了初次加載的問題，并且不會(huì)引起race conditions以及其他一些只依賴于客戶端的方案可能有的問題。這種技術(shù)不局限于圖像，還可以用來解決內(nèi)容以及Javascript上的問題。

聽起來很不錯(cuò)。有什么收獲?

這是很復(fù)雜的系統(tǒng)，需要對(duì)架構(gòu)做很大的改變以獲得支持。Bryan 和Stephanie公布了這個(gè)方法，但是代碼還不能夠下載。也許代碼很快就能下載到了，但是他們?cè)谶@個(gè)Nokia Browser project之后享受了一個(gè)假期。

也許最大的問題在于我們大多數(shù)都不是Riegers。他們已經(jīng)在移動(dòng)網(wǎng)絡(luò)上開發(fā)多年，他們對(duì)于設(shè)備的默認(rèn)知識(shí)是超群的。天才們的成功總是很難復(fù)制的。

同樣的例子還有波士頓環(huán)球時(shí)報(bào)的項(xiàng)目。這個(gè)團(tuán)隊(duì)包括jQuery Mobile team的重心力量以及提出了響應(yīng)式Web設(shè)計(jì)的人。我們的項(xiàng)目很少能有這樣的配置。

總結(jié)

在我回顧這些不同技術(shù)的時(shí)候，我一直在想Andy Hume在part 1中回復(fù)的話：

我們現(xiàn)有的解決方案對(duì)于你提到的瀏覽器現(xiàn)有的(以及未定義的)行為有太多依賴。例如，如果某種特定的超前預(yù)分析器(a particular type of look-ahead pre-parser (http://goo.gl/TyzTi))在對(duì)HTML進(jìn)行解析或者執(zhí)行script之前就開始進(jìn)行下載，那么現(xiàn)有的響應(yīng)式圖像設(shè)計(jì)就會(huì)失效了。(我隱約覺得我們總有一天會(huì)在這個(gè)上面跌跟頭。)一種可能的方式是我們和瀏覽器供應(yīng)商協(xié)調(diào)以便讓瀏覽器是未來友好的(future-friendly.)。

這的確是事實(shí)。這些技術(shù)都基于一個(gè)期待，即瀏覽器下載事物的順序和我們現(xiàn)在看到的一樣。如果順序改變了或者瀏覽器開始更多地進(jìn)行預(yù)解析了，所有的一切都灰飛煙滅了。

這個(gè)系列的第三部分，我將繼續(xù)關(guān)注改變圖像標(biāo)簽或者替換它的方法，看有沒有針對(duì)多文件源的更好的方法。

一些資源和致謝

這這篇文章中，我敘述了18種不同技術(shù)。我的筆記被發(fā)表在一個(gè)Google spreadsheet中，你可以來查看更為詳細(xì)的評(píng)論。感謝公布了他們的想法和實(shí)驗(yàn)的每一個(gè)人，我從每一個(gè)人身上都學(xué)到了很多。

這篇文章如果沒有Scott Jehl、 Bryan 和Stephanie Rieger的協(xié)助是寫不出來的。尤其是Scott，他幫助我整理出主要的響應(yīng)式圖像的JS庫的問題。感謝你們?nèi)齻€(gè)人，提出了很多真誠(chéng)的問題，并拿出時(shí)間來解釋你們一直以來做的工作。

原文：http://www.cloudfour.com/responsive-imgs-part-2/

譯文：http://www.webapptrend.com/2012/01/1355.html

【編輯推薦】

1. 響應(yīng)式Web設(shè)計(jì)之初探圖像處理
2. 什么是響應(yīng)式Web設(shè)計(jì)？怎樣進(jìn)行？
3. 響應(yīng)設(shè)計(jì)的技巧，秘訣和最佳實(shí)踐
4. 高性能WEB開發(fā)之減少請(qǐng)求、響應(yīng)的數(shù)據(jù)量
5. 移動(dòng)Web開發(fā)指南