jQuery核心基礎設施：數據緩存模塊進化史

　　數據緩存系統最早應該是jQuery1.2引入的，那時它的事件系統完成照搬DE大神的addEvent.js，而addEvent在實現有個缺憾，它把事件的回調都放到EventTarget之上，這會引發循環引用，如果EventTarget是window對象，又會引發全局污染。有了數據緩存系統，除了規避這兩個風險外，我們還可以有效地保存不同方法產生的中間變量，而這些變量會對另一個模塊的方法有用，解耦方法間的依賴。對於jQuery 來說，它的事件克隆乃至後來的列隊實現都是離不開緩存系統。

　　jQuery1.2 在core模塊新增了兩個靜態方法， data與removeData。data不用說，與jQuery其他方法一樣，讀寫結合。jQuery的緩存系統是把所有數據都放$.cache之上，然後為每個要使用緩存系統的元素節點，文檔對象與window對象分配一個UUID。UUID的屬性名為一個隨機的自定義屬性，"jQuery" + (new Date()).getTime()， 值為整數，從零遞增。但UUID總要附於一個對象上，如果那個對象是window，豈不是全局污染嗎，因此jQuery內部判定它是window對象時，映射為一個叫windowData的空對象，然後UUID加在它之上。有了UUID，我們在首次訪問緩存系統時，會在$.cache對象開辟一個空對象(緩存體)，用於放置與目標對象有關的東西。這有點像銀行開戶了，UUID的值就是存折。removeData則會刪掉不再需要保存數據，如果到最後，數據刪清光了，它也沒有任何鍵值對，成為空對象，jQuery就會從$.cache中刪掉此對象，並從目標對象移除UUID。

　　jQuery在1.2.3中添加了兩個同名的原型方法data與removeData，目的是方便鏈式操作與集化操作。並在data中添加getData, setData的自定義事件的觸發邏輯。

　　1.3中，數據緩存系統終於獨立成一個模塊data.js(內部開發時的劃分)，並添加了兩組方法，命名空間上的queue與dequeue，原型上的queue與dequeue。queue的目的很明顯，就是緩存一組數據，為動畫模塊服務。dequeue是從一組數據中刪掉一個。

　　fx模塊animate方法的調用示例：

　　在元素上添加自定義屬性，還會引發一個問題。如果我們對這個元素進行拷貝，就會將此屬性也會復制過去，導致兩個元素都有相同的UUID值，出現數據被錯誤操作的情況。jQuery早期的復制節點實現非常簡單，如果元素的cloneNode方法不會復制事件就使用cloneNode，否則使用元素的 outerHTML，或父節點的innerHTML，用clean方法解析一個新元素出來。但outerHTML與innerHTML都會顯式屬性寫在裡面，因此需要用正則把它們清除掉。

　　jQuery1.4發現IE如果對於object, ember, applet這三個古老的用於接入外部資源的標簽可能會拋錯。由於舊式IE的元素節點只是COM的包裝，一旦引入資源後，它就會變成那種資源的實例，而它們會有嚴格的訪問控制，不能像普通的JS對象那樣隨意添加成員。於是jQuery便一刀換，但凡是這三種標簽，就不為它緩存數據。jQuery弄了一個叫 noData的hash，用於檢測元素節點的標簽。

　　jQuery1.4還對$.data進行改進，允許第二個參數為對象，方便儲存多個數據。UUID對應的自定義屬性expando 也放進命名空間之下了。queue與dequeue方法被剝離成一個新模塊。

　　jQuery1.43帶來三項改進。

　　首先是添加changeData自定義方法。不過這套方法沒有什麼銷量，只是產品經理的自戀吧。

　　檢測元素節點是否支持添加自定義屬性的邏輯被獨立成一個叫acceptData的方法。因為jQuery團隊發現當object標簽加載的 flash資源，它還是可以添加自定義屬性的，於是決定對這種情況網開一面。IE在加載flash時，需要對object指定一個叫classId的屬性，值為clsid:D27CDB6E-AE6D-11cf-96B8-444553540000，因此檢測邏輯就變得非常復雜，由於data, removeData都要用到，獨立出來有效節省比特。

　　HTML5對人們隨便添加自定義屬性的行為做出回應，新增一種叫"data-*"的緩存機制。當用戶設置的屬性以"data-"開頭，它們會被保存到元素節點的dataset對象上。這就導致人們可能用HTML5方便緩存數據，也可能用jQuery的緩存系統保存數據，那麼data方法就變得有點不中用了。於是jQuery在原型上的data做了增強，當用戶第一次訪問此元素節點，會遍歷它所有"data-"開頭的自定義屬性(為了照顧舊式IE，不能直接遍歷dataset)，把它們放到jQuery的緩存體中。那麼當用戶取數據時，會先從緩存系統中，沒有再使用setAttribute訪問"data-"自定義屬性。但HTML5的緩存系統非常弱，只能保存字符串(這當然是出於循環引用的考量)，於是jQuery會將它們還原為各種數據類型，如"null",, "false", "true"變成null, false, true, 符合數字格式的字符串會轉換成數字，如果它是以"{"開頭"}"結尾則嘗試轉成一個對象。

　　jQuery1.5也帶來三項改進。當時jQuery已經在1.42打敗Prototype.js，如日中天，馬太效應，用戶量暴增。它的重點改為提升性能，進入fix bug階段(用戶多，相當於免費的測試員就越多，測試覆蓋面就越大)。

　　改進expando，原來是基於時間截，現在是版本號加隨機數。因此用戶可能在一個頁面引入多個版本的jQuery。

　　是否有此數據的邏輯被抽出成一個hasData方法，處理HTML5的"data-*"屬性也被抽出成一個私有方法dataAttr。它們都是為了邏輯顯得更清晰。dataAttr使用JSON.parse，由於這個JSON可能是JSON2.js引入的，而JSON2.js有個非常糟糕的地方，就是為一系列原生類型添加了toJSON方法，導致for in 循環判定是否為空對象出錯。jQuery被逼搞了個isEmptyDataObject方法做處理。

　　jQuery的數據緩存系統本來就是為事件系統服務而分化出來的，到後來，它是內部眾多模塊的基礎設施。換言之，它內部會儲存許多框架用戶的變量(系統數據)，但一旦它公開到文檔中，用戶也會使用data保存他們務業中使用的數據(用戶數據)。以前，用戶小，變量名沖突的可能性比較少，加之 jQuery為這些系統數據精挑了一些不常用的名字，__class__, __change__或加個後綴什麼的，沒有收到什麼投訴。當jQuery成為世界級的著名框架後，用戶數據名干掉系統數據名，導致事件系統或其他什麼模塊癱瘓就時有發生。jQuery開始對緩存體進行改造，原來就是一個對象，什麼數據都往裡面拋。現在它就這個緩存體內開辟一個子對象，鍵名為隨機的 jQuery.expando值，如果是系統數據就存到裡面去。但events系統數據為了向前兼容起見，還是直接放到緩存體之上。至於，如何區分是系統數據，非常簡單，直接在data方法添加第四個參數，真值時為系統數據。removeData時也相應提供第三個參數，用於刪除系統數據。還新設了一個 _data方法，專門用於操作系統數據。下面就是緩存體的結構圖：

　　jQuery1.8曾添加一個叫deleteIds的數組，用於重用UUID，但昙花一現。UUID的值從1.8起不用jQuery.uuid的了，改用jQuery.guid遞增生成。重大的改進在jQuery1.83後，操作數據的實現被抽出為私有方法，命名空間與原型上的方法只是一個代理，並分成兩組方法，操作用戶數據的data， removeData，操作系統數據的_data，_removeData。現在光是緩存系統就是一個龐大家族了。

　　說到底，數據緩存就是在目標對象與緩存體間建立一對一的關系，然後在緩存體上操作數據，復雜度都集在前者。而在一個普通JS對象進行增刪改查某屬性從來沒有難度，用戶怎麼也玩不出花招。從軟件設計原則上看，這也是最好的結果(吻合KISS原則與職責單一則)。

　　原文鏈接：http://www.cnblogs.com/rubylouvre/archive/2012/11/19/2776286.html