快捷導(dǎo)航

關(guān)于圖片的預(yù)加載過(guò)程中隱藏未知的

更新時(shí)間：2012年12月19日 16:27:36 作者：

相信大家都看到過(guò)ie下的內(nèi)存泄漏模式的文章，其中有一個(gè)模式就是循環(huán)引用，而閉包就有保存外部運(yùn)行環(huán)境的能力（依賴(lài)于作用域鏈的實(shí)現(xiàn)），所以img.onload這個(gè)函數(shù)內(nèi)部又保存了對(duì)img的引用，這樣就形成了循環(huán)引用，導(dǎo)致內(nèi)存泄漏

看完了曼聯(lián)與曼城的同城德比，還有漫長(zhǎng)的兩個(gè)小時(shí)，才能看到期待中的國(guó)家德比。無(wú)聊的很，左右無(wú)事，便來(lái)論壇閑逛。看到了一章關(guān)于圖片預(yù)加載的博文，其代碼如下：

復(fù)制代碼代碼如下:

 
function loadImage(url, callback) { 
var img = new Image(); //創(chuàng)建一個(gè)Image對(duì)象，實(shí)現(xiàn)圖片的預(yù)下載 
img.src = url; 
if (img.complete) { // 如果圖片已經(jīng)存在于瀏覽器緩存，直接調(diào)用回調(diào)函數(shù) 
callback(img); 
return; // 直接返回，不用再處理onload事件 
} 
img.onload = function () { //圖片下載完畢時(shí)異步調(diào)用callback函數(shù)。 
callback(img); 
}; 
}; 

在網(wǎng)上搜索了一下相關(guān)文章，大體上都是這個(gè)思路。
這個(gè)方法功能是ok的，但是有一些隱患。
1 創(chuàng)建了一個(gè)臨時(shí)匿名函數(shù)來(lái)作為圖片的onload事件處理函數(shù)，形成了閉包。
相信大家都看到過(guò)ie下的內(nèi)存泄漏模式的文章，其中有一個(gè)模式就是循環(huán)引用，而閉包就有保存外部運(yùn)行環(huán)境的能力（依賴(lài)于作用域鏈的實(shí)現(xiàn)），所以img.onload這個(gè)函數(shù)內(nèi)部又保存了對(duì)img的引用，這樣就形成了循環(huán)引用，導(dǎo)致內(nèi)存泄漏。（這種模式的內(nèi)存泄漏只存在低版本的ie6中，打過(guò)補(bǔ)丁的ie6以及高版本的ie都解決了循環(huán)引用導(dǎo)致的內(nèi)存泄漏問(wèn)題）。

2 只考慮了靜態(tài)圖片的加載，忽略了gif等動(dòng)態(tài)圖片，這些動(dòng)態(tài)圖片可能會(huì)多次觸發(fā)onload。
要解決上面兩個(gè)問(wèn)題很簡(jiǎn)單，其實(shí)很簡(jiǎn)單，代碼如下：

復(fù)制代碼代碼如下:

 
img.onload = function () { 
//圖片下載完畢時(shí)異步調(diào)用callback函數(shù)。 
img.onload = null; 
callback(img); }; 

這樣既能解決內(nèi)存泄漏的問(wèn)題，又能避免動(dòng)態(tài)圖片的事件多次觸發(fā)問(wèn)題。
在一些相關(guān)博文中，也有人注意到了要把img.onload 設(shè)置為null，只不過(guò)時(shí)機(jī)不對(duì)，大部分文章都是在callback運(yùn)行以后，才將img.onload設(shè)置為null，這樣雖然能解決循環(huán)引用的問(wèn)題，但是對(duì)于動(dòng)態(tài)圖片來(lái)說(shuō)，如果callback運(yùn)行比較耗時(shí)的話，還是有多次觸發(fā)的隱患的。
隱患經(jīng)過(guò)上面的修改后，就消除了，但是這個(gè)代碼還有優(yōu)化的余地：

復(fù)制代碼代碼如下:

 
if (img.complete) { 
// 如果圖片已經(jīng)存在于瀏覽器緩存，直接調(diào)用回調(diào)函數(shù) 
callback(img); 
return; // 直接返回，不用再處理onload事件 
} 

關(guān)于這段代碼，看相關(guān)博文里的敘述，原因如下：
經(jīng)過(guò)對(duì)多個(gè)瀏覽器版本的測(cè)試，發(fā)現(xiàn)ie、opera下，當(dāng)圖片加載過(guò)一次以后，如果再有對(duì)該圖片的請(qǐng)求時(shí)，由于瀏覽器已經(jīng)緩存住這張圖片了，不會(huì)再發(fā)起一次新的請(qǐng)求，而是直接從緩存中加載過(guò)來(lái)。對(duì)于 firefox和safari，它們?cè)噲D使這兩種加載方式對(duì)用戶透明，同樣會(huì)引起圖片的onload事件，而ie和opera則忽略了這種同一性，不會(huì)引起圖片的onload事件，因此上邊的代碼在它們里邊不能得以實(shí)現(xiàn)效果。

確實(shí)，在ie，opera下，對(duì)于緩存圖片的初始狀態(tài)，與firefox和safari，chrome下是不一樣的（有興趣的話，可以在不同瀏覽器下，測(cè)試一下在給img的src賦值緩存圖片的url之前，img的狀態(tài)），但是對(duì)onload事件的觸發(fā)，卻是一致的，不管是什么瀏覽器。產(chǎn)生這個(gè)問(wèn)題的根本原因在于，img的src賦值與 onload事件的綁定，順序不對(duì)（在ie和opera下，先賦值src，再賦值onload，因?yàn)槭蔷彺鎴D片，就錯(cuò)過(guò)了onload事件的觸發(fā)）。應(yīng)該先綁定onload事件，然后再給src賦值，代碼如下：

復(fù)制代碼代碼如下:

 
function loadImage(url, callback) { 
var img = new Image(); //創(chuàng)建一個(gè)Image對(duì)象，實(shí)現(xiàn)圖片的預(yù)下載 
img.onload = function(){ 
img.onload = null; 
callback(img); 
} 
img.src = url; 
} 
這樣內(nèi)存泄漏，動(dòng)態(tài)圖片的加載問(wèn)題都得到了解決，而且也以統(tǒng)一的方式，實(shí)現(xiàn)了callback的調(diào)用。 

您可能感興趣的文章: