转：初探 jQuery 的 Sizzle 选择器
這是一篇關于介紹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
轉載于:https://www.cnblogs.com/qinxg/articles/2465177.html
總結
以上是生活随笔為你收集整理的转：初探 jQuery 的 Sizzle 选择器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 求一个剪了短发的个性签名
- 下一篇： [转载]C# 二进制与十进制,十进制与十