jQuery相比1.2的版本，在內部代碼的構造上已經出現了巨大的變化，其之一便是模塊的分發。隨著jQuery被用來構建web app的場合愈來愈多，它的性能自然受到了大部分開發者的高度關注，它的內部實現機理又是如何，比如選擇器的實現。

關于jQuery更多內容，歡迎訪問： jQuery從入門到精通

Sizzle，作為一個獨立全新的選擇器引擎，出現在jQuery 1.3版本之后，并被John Resig作為一個開源的項目，可以用于其他框架：Mool, Dojo，YUI等。好了，現在來看為什么Sizzle選擇器如此受歡迎，使它能夠在常用dom匹配上都快于其他選擇器而讓這些框架們都垂青于它。（相關文章推薦：改變獲取對象方式 萬能的jQuery選擇器）

概要

一般選擇器的匹配模式（包括jq1.2之前），都是一個順序的思維方式，在需要遞進式匹配時，比如$(‘div span’) 這樣的匹配時，執行的操作都是先匹配頁面中div然后再匹配它的節點下的span標簽，之后返回結果。

Sizzle則采取了相反Right To Left的實現方式，先搜尋頁面中所有的span標簽，再其后的操作中才去判斷它的父節點（包括父節點以上）是否為div，是則壓入數組，否則pass，進入下一判斷，最后返回該操作序列。另外，在很多細節上也進行了優化。

淺析源碼

當我們給$符傳遞進一個參數（也可能是多個）時，此時它會根據參數的類型（domElement | string | fn | array）進入不同的流程，在此，重點看 string 類型的處理，因為只有它才可以觸發Sizzle。首先調用正則匹配看是否為創建dom節點的操作，然后看是否為簡單id匹配，這一步也由正則匹配完成，否則進入jQuery.fn.find()函數，由此進入Sizzle的天地。

當進入Sizzle時，一般情況下會配備三參：所要匹配的選擇符，上下文，匹配的結果集。調用正則對傳入的selector做一次”預匹配”.

讓我們看一下一個簡單選擇器的實現過程：比如 div > p。我們要先找出符合條件的div[div]，再找出符合條件的p[p]，最后在上下文里[div]過濾出符合條件”>”的p[p];抽象一點的說法就是：在已知的上下文里，根據關系找出相應的節點。他們靠關系聯系起來。那么對于選擇器的操作也就是根據關系來分組。一次次縮小上下文，直到找出符合條件的節點。回到我們的話題，還是先看看這個令人費解的正則，相信你會有更好的分析方法，但是眼下，我還是一點點的拆分，讓它表達的更清晰一點。先按照分組拆，即():

((?:\((?:\([^()]+\)|[^()]+)+\)|\  
[(?:\[[^\[\]]*\]|['"][^'"]*['"]|  
[^\[\]'"]+)+\]|\\.|[^ >+~,(\[\\]+)+|[>+~])  
(\s*,\s*)?((?:.|\r|\n)*) 

第一行還是有點長，用’|'拆分它:

1. (?:\((?:\([^()]+\)  
2.[^()]+)+\)  
3. \[(?:\[[^[\]]*\]  
4. [^[\]]+)+\]|\\.  
5.[^ >+~,(\[]+)+6.[>+~] 

對于如div > p。會得到數組結果['div','>','p']。對于更復雜的選擇器，如div.classname > p.classname。會得到結果['div.classname','>','p.classname']。對于具有合并的‘,’,只是遞歸調用下獲取結果再合并而已。過程開始變得簡單起來。對于普通的解析過程，我們遵循著從左到右的順序即可完成我們的目標。讓我們總結下步驟：

1.先查找頁面上所有的div

2.循環所有的div，查找每個div下的p

3.合并結果

Sizzle用了截然相反的步驟：

◆先查找頁面上所有的p

◆循環所有的p，查找每個p的父元素

◆如果不是div，遍歷上一層。

◆如果已經是頂層，排除此p。

◆如果是div，則保存此p元素。

由子元素來查找父元素，能得到更好的效率。打破常規思維后不僅步驟更簡單了，而且效率上也得到了些許提升。所有的選擇器都可以這樣解析嗎？不是，采用right -> left的順序是有前提條件的：沒有位置關系的約束。比如如下這段html：

<div>p1contentp2content </div>   
<div>p3contentp4content </div> 

對于選擇器：$(“div p:first”)只會返回["#p1"]。而$(“div p:first-child”)則返回["#p1", "#p3"]。兩者的區別在于位置filter的結果依賴于它前面的selector解析的結果，而其它 filter，只依賴于當前元素本身，就可以判斷它是否滿足filter。那Sizzle是通過什么來判定進入哪一個流程呢，答案是origPOS的正則匹配,origPos指向了Expr中match對象的POS屬性,而POS中存儲了五花八門的位置類約束，如下：

/:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/     //POS的值
 

這樣一來，第一步的流程判斷就已明朗。

當處于1的情況時:

首先根據需要對當前處理的A數組元素進行一系列修正操作（Expr.relative主刀）。然后調用posProcess函數對修復后的元素進行匹配.

其中，還需一層判斷，如果有層級約束，eg ‘>,’:input’ 會轉化為 ‘> :input’,因為在最初調用chunker進行預匹配的時候，這些是會被分割為單個數組元素的，但在這里需要將它們做一次合并，這是由posProcess所處理的數據格式所決定的。

//如果存在偽類選擇符，從selector中移除，并保存在later中   
// 這樣一來，匹配對象便分離出來：selector（簡單選擇符存儲器）和later（偽類選擇符存儲器）。   
while ( (match = Expr.match.PSEUDO.exec( selector )) )   
{    later += match[0];    selectorselector = selector.replace( Expr.match.PSEUDO, "" ); }   
//構造selector，并調用Sizzle進行匹配,將結果存儲在tmpSet中  
selector = Expr.relative[selector] ? selector + "*" : selector;   
for ( var i = 0, l = root.length; i <  ; i++ )  
 {    Sizzle( selector, root[i], tmpSet ); }  
 // 最后便是filter的過濾 return Sizzle.filter( later, tmpSet ); 

源碼片段b: — 對預匹配后的數組A中元素的處理：

//這個為特例，被正則分割的A數組長度為2，則合并數組元素，上下文則原封不動為Sizzle傳遞進來的context。  
 if ( parts.length === 2 && Expr.relative[ parts[0] ] )   
{      
// 完成一次匹配， 由posProcess 內部調用 filter進行匹配      
// 但在匹配前，完成了一次連接選擇符的操作      
// 存入set，注 set 當前還不是最終的結果，其這里的set和上面的tmpSet一樣，都是一個"暫時性"的結果集      
set = posProcess( parts[0] + parts[1], context ); 

源碼片段c: — 如果存在位置約束關系， 正向匹配。

set = Expr.relative[ parts[0] ] ?      
[ context ] :      
// 否則對隊列首元素進行一次簡單匹配操作      
Sizzle( parts.shift(), context ); 

分析Expr.relative，可以看出，它包含了4種dom元素間關系的判斷，分別是 “+”, “>”, “”, “~”。每一輪的匹配，都會先判斷A數組的首元素是不是代表tag間關系符(+,>等) ，而做后續處理.同時對A數組進行循環，依次做類似的處理。源碼片段d — 對A數組(parts)的循環處理及后續。

#p#

while ( parts.length ) {      
// 依次對 所匹配到的 數組中元素進行 遞進匹配      
selector = parts.shift();      
//   '>'  -> '>input' 的形式      
if ( Expr.relative[ selector ] )          
selector += parts.shift();       
set = posProcess( selector, set ); 

當處于2的情況時：源碼片段e: — 根據當前流程設置ret(兩種情況)。

//為ret綁定正確的返回值 var ret = seed ?         
//seed 為上一次調用sizzle返回值， 即前文中提到的set|tmpset     
 //將預匹配后的A數組(parts)中的最后元素設置為ret的expr屬性，set屬性設為上一次匹配的結果集。      
{ expr: parts.pop(), set: makeArray(seed) } :      
//如果是第一次調用，則進行匹配操作,調用find函數      
// 以parts數組最末元素為當前選擇符，進行匹配操作，同時設置與之相關的context     
Sizzle.find( parts.pop(), parts.length === 1 && context.parentNode   
? context.parentNode : context, isXML(context) ); 

2的情況為一般邏輯處理，從這小段代碼便可得到Sizzle的匹配機制，每一次的調用都以數組末元素為基準，以上一次（或預設context）為上下文約束關系以右到左的匹配,最后返回匹配結果。結合了DOM結構的特性，性能上也得到了大幅的提升。

我們知道選擇器的類型是有效率差別的，id選擇器效率最高，其次是class、name、tag、最后是最差的*表達式。在Sizzle.find函數中，會按照這個效率的順序查找元素，如果沒有id就找class，依次下去。當然，class的支持需要方法getElementsByClassName。如果沒有，就只好從id跳到name。

if ( document.getElementsByClassName && document.documentElement.getElementsByClassName ) (function()  
{      
// ...    // 如果支持直接獲取，則將獲取class的方法 直接添加進 Expr.order中     
['ID', 'NAME', 'TAG']    Expr.order.splice(1, 0, "CLASS");      
//同時在find中追加對class的獲取    Expr.find.CLASS = function(match, context, isXML) {         
 if ( typeof context.getElementsByClassName !== "undefined" && !isXML )   
{            return context.getElementsByClassName(match[1]);          
}      
};})(); 

在Sizzle.find函數中，做了一系列的邏輯判斷，來保證返回結果的正確性，首先在進入find時，保證了expr不為空的，然后根據表達式類型(id|name|tag|class?)來選擇與之對應的匹配分支進行實現，最后再做適當的收尾工作，將返回結果定義為對象，來移交給filter,完成整個流程。

//order: [ "ID", "NAME", "TAG" ]   
// 當然，如果瀏覽器支持對class的直接獲取時，order中就會出現class的相關匹配規則   
for ( var i = 0, l = Expr.order.length; i < l; i++ )   
{    var type = Expr.order[i], match;      
// 根據 type 對所傳進來的expr 進行正則匹配     
// match中通過正則限制了這三類匹配方式的條件。      
// 1. ID: /#((?:[\w\u00c0-\uFFFF_-]|\\.)+)/,      
// 2. NAME: /\[name=['"]*((?:[\w\u00c0-\uFFFF_-]|\\.)+)['"]*\]/,      
// 3. TAG: /^((?:[\w\u00c0-\uFFFF\*_-]|\\.)+)/,      
if ( (match = Expr.match[ type ].exec( expr )) )   
{        var left = RegExp.leftContext;          
//保證返回結果的正確性，如果存在\，則刪除          
if ( left.substr( left.length - 1 ) !== "\\" )   
{            match[1] = (match[1] || "").replace(/\\/g, "");              
// 根據type調用 sizzle.selector.find方法獲取結果集。             
 set = Expr.find[ type ]( match, context, isXML );              
if ( set != null ) {                  
//如果匹配成功，刪除已經匹配的expr                  
exprexpr = expr.replace( Expr.match[ type ], "" );                  
break;              
}         
 }      
} }    
return {set: set, expr: expr}; }; 

在所返回的對象中，expr的作用便是為了輔佐filter這把大器所需要完成任務的工具,到此就可以調用Sizzle.filter對ret.set再做一次精確匹配(匹配規則即ret.expr),以及tag間的位置約束關系的匹配（這部分同1中類似）。源碼片段g: — 和源碼片段d有類似之處。

實例

以’div > span p span:last’這個選擇符為例，看看它的調用鏈是如何順次完成的。根據對源碼的剖析，理解如下：

1. jquery.init -> jquery.prototype.find

2. 進入Sizzle(對xml的判斷) -> 設置parts數組等在匹配中所需要的元素 -> 根據數組長度以及調用origPos進行判斷，來決定進入哪個分支，在這個實例下進入分支1

3. 循環調用Sizzle進行匹配，將結果存入set中(因為在這一過程中是循環調用，所以對Sizzle的判斷也是需要多次，進入哪一分支當然也會是不一樣的，比如第二輪循環判斷則進入分支2中進行處理) ,對于>號的處理，也會將它合并在其后的span中，構成新的選擇符 ‘>span’,然后進入Expr.relative進行匹配，同時調用posProcess。

4. 調用Sizzle.find 匹配除偽類以外的部分(即這里的選擇器不包含:last),首先會調用Expr.find的find方法來判斷是否為哪一類匹配，在這一實例中，為TAG匹配。

5. 對從4步中生成的對象進行過濾,匹配’>’(這一步的匹配是由Sizzle.filter觸發，由Expr.relative完成),而在匹配’span:last’時則由posProcess來觸發，設置later值(:first)以及selector(span)，對span的匹配和4步驟一樣，重復匹配，而對:first的匹配則是第5步的重頭戲，也就是調用Sizzle.filter來完成, 由此便生成了最后的匹配結果。

對于有‘,’這樣需要合并的選擇器，Sizzle在獲取結果后會按照文檔流進行排序。所以，你可能會遇到這樣的問題：把一個結果集append到新的節點后，新的節點可能不會按照你書寫的選擇器的順序出現。以上，可以得出以下結論：大致通過如下步驟來完成：

1.對表達式分組。

2.選擇合適的處理順序。

3.在當前的上下文里過濾要找的節點。并更新上下文。重復這一過程，直到結尾。

4.對結果排序，如果需要的話。

5.返回結果數組。

前向兼容

其實不止這一處，在Sizzle的API手冊中Internal部分的find 函數（與filter構成了Sizzle的兩把寶劍），在傳遞進該方法的參數可以用 querySelectorAll() （依賴于當前的瀏覽器執行環境） 直接獲取時，它則直接調用該方法，既擁有了向前兼容的特性，又達到了速度的提升。雖然有些環境實現了方法querySelectorAll，但是會有bug。

//如果當前document 支持 querySelectorAll方法,則將瀏覽器可以完成的匹配完全交給瀏覽器   
if ( document.querySelectorAll ) (function(){      
var oldSizzle = Sizzle;      
// 解決Safari bug 略過 ...      
Sizzle = function(query, context, extra, seed)  
{        contextcontext = context || document;       
// 因為querySelectorAll 在domElement 節點上操作時，存在bug 所以多了這樣的判斷      
// bug info: http://ejohn.org/blog/thoughts-on-queryselectorall/         
 if ( !seed && context.nodeType === 9 && !isXML(context) )   
{            return makeArray( context.querySelectorAll(query), extra );        }          
// querySelectorAll 可用則直接返回結果，否則才調用   
sizzle        return oldSizzle(query, context, extra, seed);    };      
// oldSizzle 方法追加進 新的 Sizzle 中  })();  
 

對于任何一個開發者，我想，若瀏覽器原生已提供了實現方法，他都不會去高效而求繁瑣吧。這一點在Sizzle中得到了充分的體現，總是盡可能的使用相應環境下已實現的原生方法。所以在IE的低版本中(比如IE6)Sizzle的表現更加出眾，在高級的瀏覽器中的對比卻沒有那么大的差別。

#p#

擴展

如何定義自己的選擇器呢.如果項目中頻繁使用某些過濾規則，是不是把它作為一個選擇器更有效呢。既然javascript的對象可以任意擴充，只要我們訪問得到，那么我們就可以很輕松得創建出自己的選擇器。在jQuery.expr.filter對象中，有很多內置的選擇器，比如 'disabled','text',那我們就擴充它,比如，想尋找包含span的div元素。

// filter的簡寫  ':'jQuery.expr[":"] = jQuery.expr.filters;$.extend($.expr[':'],   
{    hasSpan: function(e) {       return $(e).find('span').length > 0;    } }); 

這樣，我們就擁有了 ':hasSpan' 的選擇器，使用當然和默認的一樣。

//直接用就可以了  
$('div:hasSpan').... 

比較

再拾YUI3，在經過大幅度變化，以全新姿態出現，從選擇器上的執行上效率不遜色于Sizzle幾毫，初看YUI時就一直對它的模塊細粒度化贊不絕口，但是從如我這樣的實用主義者的角度來看，選擇器就應該是一個單獨的模塊，就如同jQuery分離而出的Sizzle。但在YUI term眼里，為了讓代碼的組織結構看上去更加的理想化，更加具有”YUI3“的特色，將之在代碼結構上又細分出一二三，比起Sizzle的簡潔，它顯得太過學院派。

除此，在選擇器的擴展上，sizzle表現勝于YUI3 selector，在實現css1~css3選擇器的基礎上，又對常用的功能進行了擴展。比如對表單元素快捷操作。據我所知，開發者對這類型選擇器的使用頻率并不是想象中那么低。既然有了模塊的細分，為什么不將這部分作為一個可擴充性的功能點模塊融入框架中呢。Sizzle于開發者就如同一塊可口味佳的點心，滿足我們各式各樣的胃口，簡潔，不失其功能的強勁，這點非常值得稱道。

總得來看，Sizzle與YUI就好象一個面向實際與理想主義的比較。這里沒有對錯之分，從不同角度來看，都能略窺其各自的禪意。前者從如何為開發者帶來便利的角度考慮，讓開發者實時覺得它的簡單可信賴。后者，也寄托了自己對web的構想，如果瀏覽器原生全部支持css3-selector，那豈不是完全不用引入該模塊了，不過我想，真到那時候，各框架也都會有很大的變化了，只是我對這一天的到來抱有比較消極的態度，這是后話。

總結

本文從總體上討論了jQuery之Sizzle選擇器的實現原理，通過一個初步的流程分析，讓各位讀者對此有一個大致印象，毫無疑問，更深層次的匹配，也只是它的遞歸調用，再匹配而已。

這里，沒有做與其他框架在效率上的比較，如果你還對它的效率還有所懷疑的話，你可以自行比較。如果你感興趣，更推薦你繼續去探索在1.4中著重優化的api源碼，或許，會給你更多的啟示。

思考

從jQuery的角度來講，Sizzle的出現隨之也帶來了web上的一些新的局面，在追求效率的同時，即使是這類單種子模式的庫也是需要將之分離開來，來設計成能夠獨立使用，獨立維護的引擎。

從選擇器的角度來講，Sizzle這次算法的提升，我初步的結論是它結合了DOM這一特定的數據結構，使其每次的匹配能夠更精準,以此獲得引擎效率上的提升。
我們可否多想想，在思維的開拓上能給我們留下多少財富。很多問題的解決，在換一種新的思維方式后，是不是常常會有柳暗花明的感覺呢。

【編輯推薦】

1. 拋磚引玉 自定義jQuery擴展接口
2. jQuery四大天王：核心函數詳解
3. 改變獲取對象方式 萬能的jQuery選擇器