jQuery選擇器引擎和Sizzle介紹
首先介紹一下什麽是Sizzle：
Sizzle是一個純javascript CSS選擇器引擎。jquery1.3開始使用sizzle，Sizzle一反傳統采取了相反的Right To Left的查詢匹配方式,效率提高.Sizzle是jQuery作者John Resig新寫的DOM選擇器引擎,速度號稱業界第一.Sizzle完全獨立於jQuery，若不想用jQuery,你可只用Sizzle實現,壓縮3K多http://url.cn/J73IkN
這是一篇yleo77的關於介紹jQuery Sizzle選擇器的文章，由其和obility共同完成。現在收藏在此學習研究。
在文中，我們試圖用自己的語言配以適量的代碼向讀者展現出Sizzle在處理選擇符時的流程原理，以及末了以少許文字給你展示出如何借用Sizzle之手實現自定義選擇器（也許更標準的叫法叫做過濾符）和它與YUI 選擇器的大致比較。
前序
jQuery相比1.2的版本，在內部代碼的構造上已經出現了巨大的變化，其之一便是模塊的分發.我記得09年在jquery 9月開的一次大會上 john放出的一張ppt上 也指出了當前的jquery下一步目標，不僅僅是除了sizzle選擇器的分離，屆時core，attribute，css以及manipulation，包括event也都會獨立成單獨的js文件.（1.4的文件結構，其實已經分成單獨的16個模塊的組成）
隨著jQuery被用來構建web app的場合愈來愈多，它的性能自然受到了大部分開發者的高度關註，它的內部實現機理又是如何，比如選擇器的實現。
Sizzle，作為一個獨立全新的選擇器引擎，出現在jQuery 1.3版本之後，並被John Resig作為一個開源的項目，可以用於其他框架：Mool, Dojo，YUI等。
好了，現在來看為什麽Sizzle選擇器如此受歡迎，使它能夠在常用dom匹配上都快於其他選擇器而讓這些框架們都垂青於它。
概要
一般選擇器的匹配模式（包括jq1.2之前），都是一個順序的思維方式，在需要遞進式匹配時，比如$(‘div span’) 這樣的匹配時，執行的操作都是先匹配頁面中div然後再匹配它的節點下的span標簽，之後返回結果。
Sizzle則采取了相反Right To Left的實現方式，先搜尋頁面中所有的span標簽，再其後的操作中才去判斷它的父節點（包括父節點以上）是否為div，是則壓入數組，否則pass，進入下一判斷，最後返回該操作序列。
性能上得到了提升，對比性能參考下圖
另外，在很多細節上也進行了優化。
淺析源碼
在探索 $ 符 和 Sizzle的協同工作原理前，先引用一張圖片
開始吧。（$符在這裏不作過多的介紹）.
當我們給$符傳遞進一個參數（也可能是多個）時，此時它會根據參數的類型（domElement | string | fn | array）進入不同的流程，在此，重點看 string 類型的處理，因為只有它才可以觸發Sizzle。首先調用正則匹配看是否為創建dom節點的操作，然後看是否為簡單id匹配，這一步也由正則匹配完成，否則進入jQuery.fn.find()函數，由此進入Sizzle的天地。
當進入Sizzle時，一般情況下會配備三參：所要匹配的選擇符，上下文，匹配的結果集。調用正則對傳入的selector做一次”預匹配”.
var chunker = /((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|[‘"][^‘"]*[‘"]|[^[\]‘"]+)+\]|\\.|[^ >+~,(\[\\]+)+|[>+~])(\s*,\s*)?/g,
讓我們看一下一個簡單選擇器的實現過程：比如 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用了截然相反的步驟：
1.先查找頁面上所有的p
2.循環所有的p，查找每個p的父元素
1.如果不是div，遍歷上一層。
2.如果已經是頂層，排除此p。
3.如果是div，則保存此p元素。
由子元素來查找父元素，能得到更好的效率。看，打破常規思維後不僅步驟更簡單了，而且效率上也得到了些許提升。
所有的選擇器都可以這樣解析嗎？不是，采用right -> left的順序是有前提條件的：沒有位置關系的約束。
比如如下這段html：
<div> <p id="p1">p1content <p id="p2">p2content </div> <div> <p id="p3">p3content <p id="p4">p4content </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所處理的數據格式所決定的
源碼片段a: — posProcess函數匹配核心
//如果存在偽類選擇符，從selector中移除，並保存在later中 // 這樣一來，匹配對象便分離出來：selector（簡單選擇符存儲器）和later（偽類選擇符存儲器）。 while ( (match = Expr.match.PSEUDO.exec( selector )) ) { later += match[0]; selector = selector.replace( Expr.match.PSEUDO, "" ); } //構造selector，並調用Sizzle進行匹配,將結果存儲在tmpSet中 selector = Expr.relative[selector] ? selector + "*" : selector; for ( var i = 0, l = root.length; i < l; 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)的循環處理及後續
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,完成整個流程。
源碼片段f: — find 函數核心
//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 expr = expr.replace( Expr.match[ type ], "" ); break; } } } } return {set: set, expr: expr}; };
在所返回的對象中，expr的作用便是為了輔佐filter這把大器所需要完成任務的工具,到此就可以調用Sizzle.filter對ret.set再做一次精確匹配(匹配規則即ret.expr),以及tag間的位置約束關系的匹配（這部分同1中類似）.
源碼片段g: — 和源碼片段d有類似之處。不作詳述
while ( parts.length ) { var cur = parts.pop(), pop = cur; // 是否存在 類似這樣的匹配 eg: ‘+‘, ‘>‘等 if ( !Expr.relative[ cur ] ) { cur = ""; } else { //如果存在層間關系的約束 則修復 cur 和pop的指向 // eg [‘div‘, ‘+‘, ‘span‘] => pop = div; cur = ‘+‘; 並進入 relative的匹配。 pop = parts.pop(); } // 確保擁有上下文 代碼略過 Expr.relative[ cur ]( checkSet, pop, isXML(context) ); }
之後便接近sizzle尾聲：結果集的處理(將所匹配的結果set 追加進 result中)。當然，如果有多表達式,便會再一次調用。
實例
以’div > span p span:last’這個選擇符為例，看看它的調用鏈是如何順次完成的。
根據對源碼的剖析，理解如下：
- jquery.init -> jquery.prototype.find
- 進入Sizzle(對xml的判斷) -> 設置parts數組等在匹配中所需要的元素 -> 根據數組長度以及調用origPos進行判斷，來決定進入哪個分支，在這個實例下進入分支1
- 循環調用Sizzle進行匹配，將結果存入set中(因為在這一過程中是循環調用，所以對Sizzle的判斷也是需要多次，進入哪一分支當然也會是不一樣的，比如第二輪循環判斷則進入分支2中進行處理) ,對於>號的處理，也會將它合並在其後的span中，構成新的選擇符 ‘>span’,然後進入Expr.relative進行匹配，同時調用posProcess。
- 調用Sizzle.find 匹配除偽類以外的部分(即這裏的選擇器不包含:last),首先會調用Expr.find的find方法來判斷是否為哪一類匹配，在這一實例中，為TAG匹配。
- 對從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.返回結果數組。
前向兼容
querySelectorAll
其實不止這一處，在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){ context = 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的表現更加出眾，在高級的瀏覽器中的對比卻沒有那麽大的差別。
擴展
如何定義自己的選擇器呢.如果項目中頻繁使用某些過濾規則，是不是把它作為一個選擇器更有效呢。
既然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這一特定的數據結構，使其每次的匹配能夠更精準,以此獲得引擎效率上的提升。
我們可否多想想，在思維的開拓上能給我們留下多少財富。很多問題的解決，在換一種新的思維方式後，是不是常常會有柳暗花明的感覺呢。
相關參考：
W3C css selector:CSS1,CSS2,CSS3
CSS Support History -Brian Wilson
CSS Selectors and Pseudo Selectors and browser support – kimblim.dk
Javascript CSS Selector Engine Timeline – Paul Irish
Sizzle Documentation
jQuery選擇器引擎和Sizzle介紹