##根據選擇器查詢元素 | # IE9 (IE8部分支援), Firefox 3.5 , Chrome 4 , Safari 3.1 |
|
在Sizzle中，出於效能考慮，優先考慮使用JS的原生方法進行查詢。在上述列出的方法中，除了querySelector方法沒有被用到，其它都在Sizzle中有使用。
對於不可以使用原生方法直接取得結果的case，Sizzle就需要進行詞法分析，分解這個複雜的CSS選擇器，然後再逐項查詢過濾，取得最終符合查詢條件的元素。
有以下幾個點是為了提高這種低階查詢的速度：
#從右到左： 傳統的選擇器是從左到右，例如對於選擇器#box .cls a，它的查詢過程是先找到id=box的元素，然後在這個元素後代節點裡查找class中包含cls元素；找到後，再找出這個元素下的所有a元素。尋找完成後再回到上一層，繼續尋找下一個.cls元素，如此往復，直至完成。這樣的做法有一個問題，就是有很多不符合條件元素，在尋找也會被遍歷到。而對於從右向左的順序，它是先找到所有a的元素，然後在根據剩下的選擇器#box .cls，篩選出符合這個條件的a元素。這樣一來，等於是限定了查詢範圍，相對而言速度當然會更快。但是需要明確的一點是，並不是所有的選擇器都適合這種從右到左的方式查詢。也並不是所有的從右到左查詢都比從左至右快，只是它涵蓋了絕大多數的查詢情況。
限定種子集合： 如果只有一組選擇器，也就是不存在逗號分隔查詢條件的情況；則先找出最末級的節點，在最末級的節點集合中篩選；
限定查詢範圍： 如果父級節點只是一個ID且不包含其它限制條件，則將查詢範圍縮小到父級節點;#box a;
快取特定資料 ：主要分三類，tokenCache, compileCache, classCache;
#我們對Sizzle的查詢分為兩類：
- ##簡易流程（沒有位置偽類）
- 帶位置偽類的查詢
簡易流程簡易流程在進行查詢時，遵循從右到左的流程。
梳理一下簡易流程Sizzle流程圖（簡易版）簡易流程忽略的東西主要是和位置偽類別相關的處理邏輯，例如:nth-child之類的詞法分析詞法分析，將字串的選擇器，解析成一系列的TOKEN。 先明確TOKEN的概念，TOKEN可以看做最小的原子，不可再拆分。在CSS選擇器中，TOKEN的表現形式一般是TAG、ID、CLASS、ATTR等。一個複雜的CSS選擇器，經過詞法分析後，會產生一系列的TOKEN，然後根據這些Token進行最終的查詢和篩選。 下面舉個例子說明一下詞法分析的過程。對於字串#box .cls a的解析:
/**
* 下面是Sizzle中词法解析方法 tokennize 的核心代码 1670 ~ 1681 行
* soFar = '#box .cls a'
* Expr.filter 是Sizzle进行元素过滤的方法集合
* Object.getOwnPropertyNames(Expr.filter) // ["TAG", "CLASS", "ATTR", "CHILD", "PSEUDO", "ID"]
*/
for ( type in Expr.filter ) {
// 拿当前的选择字符串soFar 取匹配filter的类型，如果能匹配到，则将当前的匹配对象取出，并当做一个Token存储起来
// matchExpr中存储一些列正则，这些正则用于验证当前选择字符串是否满足某一token语法
if ( (match = matchExpr[ type ].exec( soFar )) && (!preFilters[ type ] ||
(match = preFilters[ type ]( match ))) ) {
matched = match.shift();
tokens.push({
value: matched,
type: type,
matches: match
});
// 截取掉匹配到选择字符串，继续匹配剩余的字符串(继续匹配是通过这段代码外围的while(soFar)循环实现的)
// matchExpr中存储的正则都是元字符“^”开头，验证字符串是否以‘xxx’开头；这也就是说， 词法分析的过程是从字符串开始位置，从左至右，一下一下地剥离出token
soFar = soFar.slice( matched.length );
}
}經過上述的解析過程後，#box .cls a會被解析成如下形式的陣列：Sizzle: tokens
編譯函數編譯函數的流程很簡單，首先根據selector去匹配器的快取中尋找對應的匹配器。
如果之前進行過相同selector的查詢並且快取還在（因為Sizzle換粗數量有限，如果超過數量限制，最早的快取會被刪掉），則直接傳回當前快取的匹配器。
如果快取中找不到，則透過matcherFromTokens() 和matcherFromGroupMatchers() 方法產生終極匹配器，並將終極匹配器快取。
根據tokens產生匹配器（matcherFromTokens）這一步驟是根據詞法分析產出的tokens，產生matchers（匹配器）。 在Sizzle中，對應的方法是
matcherFromTokens。
打個預防針，這個方法讀起來，很費神吶。
在Sizzle原始碼（sizzle.js檔）中第1705 ~ 1765 行，只有60行，卻揉進了好多工廠方法（就只指那種return值是Function類型的方法）。 我們簡化一下這個方法的流程（去掉了偽類選擇器的處理）
function matcherFromTokens( tokens ) {
var checkContext, matcher, j,
len = tokens.length,
leadingRelative = Expr.relative[ tokens[0].type ],
implicitRelative = leadingRelative || Expr.relative[" "],
i = leadingRelative ? 1 : 0,
// The foundational matcher ensures that elements are reachable from top-level context(s)
matchContext = addCombinator( function( elem ) {
return elem === checkContext;
}, implicitRelative, true ),
matchAnyContext = addCombinator( function( elem ) {
return indexOf( checkContext, elem ) > -1;
}, implicitRelative, true ),
matchers = [ function( elem, context, xml ) {
var ret = ( !leadingRelative && ( xml || context !== outermostContext ) ) || (
(checkContext = context).nodeType ?
matchContext( elem, context, xml ) :
matchAnyContext( elem, context, xml ) );
// Avoid hanging onto element (issue #299)
checkContext = null;
return ret;
} ];
// 上面的都是变量声明
// 这个for循环就是根据tokens 生成matchers 的过程
for ( ; i ', ' ', '+', '~'），则需要合并之前的matchers；
if ( (matcher = Expr.relative[ tokens[i].type ]) ) {
matchers = [ addCombinator(elementMatcher( matchers ), matcher) ];
} else {
matcher = Expr.filter[ tokens[i].type ].apply( null, tokens[i].matches );
matchers.push( matcher );
}
}
// 将所有的matchers 拼合到一起 返回一个匹配器，
// 所有的matcher返回值都是布尔值，只要有一个条件不满足，则当前元素不符合，排除掉
return elementMatcher( matchers );
}
Question：為什麼如果碰到祖先/兄弟關係（'>', ' ', ' ', '~'），則需要合併先前的matchers？
Answer:目的並不一定要合併，而是為了找到當前節點關聯節點（滿足祖先/兄弟關係['>', ' ', ' ', '~' ]），然後利用先前的匹配器驗證這個關聯節點是否滿足匹配器。而在「驗證」這個環節不一定要合併之前的matchers，只是合併起來結構會比較清楚。舉個例子：
我们需要买汽车，现在有两个汽车品牌A、B。A下面有四种车型：a1,a2,a3,a4；B下面有两种车型：b1,b2。那么我们可以的买到所有车就是
[a1,a2,a3,a4,b1,b2]。但是我们也可以这么写{A:[a1,a2,a3,a4],B:[b1,b2]}。这两种写法都可以表示我们可以买到车型。只是第二种相对前者，更清晰列出了车型所属品牌关系。
同理，在合并后，我们就知道这个合并后的matcher就是为了验证当前的节点的关联节点。
生成终极匹配器（matcherFromGroupMatchers）
主要是返回一个匿名函数，在这个函数中，利用matchersFromToken方法生成的匹配器，去验证种子集合seed，筛选出符合条件的集合。
先确定种子集合，然后在拿这些种子跟匹配器逐个匹配。在匹配的过程中，从右向左逐个token匹配，只要有一个环节不满条件，则跳出当前匹配流程，继续进行下一个种子节点的匹配过程。
通过这样的一个过程，从而筛选出满足条件的DOM节点，返回给select方法。
查询过程demo
用一个典型的查询，来说明Sizzle的查询过程。
以 p.cls input[type="text"] 为例：
解析出的tokens:
[
[
{ "value": "p", "type": "TAG", "matches": ["p"] },
{ "value": ".cls", "type": "CLASS", "matches": ["cls"] },
{ "value": " ", "type": " " },
{ "value": "input", "type": "TAG", "matches": ["input"] },
{ "value": "[type=\"text\"]", "type": "ATTR", "matches": ["type", "=", "text"]}
]
]
首先这个选择器 会筛选出所有的<input>作为种子集合seed，然后在这个集合中寻找符合条件的节点。
在寻找种子节点的过程中，删掉了token中的第四条{ "value": "input", "type": "TAG", "matches": ["input"] }。
那么会根据剩下的tokens生成匹配器
matcherByTag('p')
matcherByClass('.cls')
碰见父子关系' '，将前面的生成的两个matcher合并生成一个新的
matcher:
matcherByTag('p'),
matcherByClass('.cls')
这个matcher 是通过addCombinator()方法生成的匿名函数，这个matcher会先根据 父子关系parentNode，取得当前种子的parentNode， 然后再验证是否满足前面的两个匹配器。
碰见第四条 属性选择器，生成
至此，根据tokens已经生成所有的matchers。
终极匹配器
在matcherFromTokens()方法中的最后一行，还有一步操作，将所有的matchers通过elementMatcher()合并成一个matcher。
elementMatcher这个方法就是将所有的匹配方法，通过while循环都执行一遍，如果碰到不满足条件的，就直接挑出while循环。
有一点需要说明的就是: elementMatcher方法中的while循环是倒序执行的，即从matchers最后一个matcher开始执行匹配规则。对应上面的这个例子就是，最开始执行的匹配器是matcherByAttr('[type="text"]')。 这样一来，就过滤出了所有不满足type="text"的<input>的元素。然后执行下一个匹配条件，
Question: Sizzle中使用了大量闭包函数，有什么作用？出于什么考虑的？
Answer:闭包函数的作用，是为了根据selector动态生成匹配器，并将这个匹配器缓存(cached)。因为使用闭包，匹配器得以保存在内存中，这为缓存机制提供了支持。
这么做的主要目的是提高查询性能，通过常驻内存的匹配器避免再次消耗大量资源进行词法分析和匹配器生成。以空间换时间，提高查询速度。
Question: matcherFromTokens中， 对每个tokens生成匹配器列表时，为什么会有一个初始化的方法？
Answer: 这个初始化的方法是用来验证元素是否属于当前context。
Question: matcherFromGroupMatchers的作用？
Answer: 返回一个终极匹配器，并让编译函数缓存这个终极匹配器。 在这个终极匹配器中，会将获取到的种子元素集合与匹配器进行比对，筛选出符合条件的元素。
TODO: 编译机制也许是Sizzle为了做缓存以便提高性能而做出的选择？？
是的，详细答案待补充~~~
TODO: outermostContext的作用
细节问题，还有待研究~~~
带位置伪类的查询流程
带位置伪类的查询是 由左至右。
用选择器.mark li.limark:first.limark2 a span举例。
在根据tokens生成匹配器（matcherFromTokens）之前的过程，跟简易查询没有任何区别。
不同的地方就在matcherFromTokens()方法中。位置伪类不同于简易查询的是，它会根据位置伪类将选择器分成三个部分。对应上例就是如下
位置伪类的查询思路，是先进行位置伪类之前的查询.mark li.limark，这个查询过程当然也是利用之前讲过的简易流程(Sizzle(selector))。查询完成后，再根据位置伪类进行过滤，留下满足位置伪类的节点。如果存在第三个条件，则利用第三个条件，再进行一次过滤。然后再利用这些满足位置伪类节点作为context，进行位置伪类之后选择器 a span的查询。
上例选择器中只存在一个位置伪类；如果存在多个，则从左至右，会形成一个一个的层级，逐个层级进行查询。
下面是对应的是matcherFromTokens()方法中对位置伪类处理。
// 这个matcherFromTokens中这个for循环，之前讲过了，但是 有个地方我们跳过没讲
for ( ; i 1 && elementMatcher( matchers ), // 位置伪类之前的matcher
i > 1 && toSelector(
// If the preceding token was a descendant combinator, insert an implicit any-element `*`
tokens.slice( 0, i - 1 ).concat({ value: tokens[ i - 2 ].type === " " ? "*" : "" })
).replace( rtrim, "$1" ), // 位置伪类之前的selector
matcher, // 位置伪类本身的matcher
i <p><code>setMatcher()</code>方法的源码，在这里生成最终的matcher， return给<code>compile()</code>方法。</p><pre class="brush:php;toolbar:false">//第1个参数，preFilter，前置过滤器，相当于伪类token之前`.mark li.limark`的过滤器matcher
//第2个参数，selector，伪类之前的selector (`.mark li.limark`)
//第3个参数，matcher， 当前位置伪类的过滤器matcher `:first`
//第4个参数，postFilter，伪类之后的过滤器 `.limark2`
//第5个参数，postFinder，后置搜索器，相当于在前边过滤出来的集合里边再搜索剩下的规则的一个搜索器 ` a span`的matcher
//第6个参数，postSelector，后置搜索器对应的选择器字符串，相当于` a span`
function setMatcher( preFilter, selector, matcher, postFilter, postFinder, postSelector ) {
//TODO: setMatcher 会把这俩货在搞一次setMatcher， 还不太懂
if ( postFilter && !postFilter[ expando ] ) {
postFilter = setMatcher( postFilter );
}
if ( postFinder && !postFinder[ expando ] ) {
postFinder = setMatcher( postFinder, postSelector );
}
return markFunction(function( seed, results, context, xml ) {
var temp, i, elem,
preMap = [],
postMap = [],
preexisting = results.length,
// Get initial elements from seed or context
elems = seed || multipleContexts( selector || "*", context.nodeType ? [ context ] : context, [] ),
// Prefilter to get matcher input, preserving a map for seed-results synchronization
matcherIn = preFilter && ( seed || !selector ) ?
condense( elems, preMap, preFilter, context, xml ) :
elems,
matcherOut = matcher ?
// If we have a postFinder, or filtered seed, or non-seed postFilter or preexisting results,
postFinder || ( seed ? preFilter : preexisting || postFilter ) ?
// ...intermediate processing is necessary
[] :
// ...otherwise use results directly
results :
matcherIn;
// Find primary matches
if ( matcher ) {
// 这个就是 匹配位置伪类的 逻辑， 将符合位置伪类的节点剔出来
matcher( matcherIn, matcherOut, context, xml );
}
// Apply postFilter
if ( postFilter ) {
temp = condense( matcherOut, postMap );
postFilter( temp, [], context, xml );
// Un-match failing elements by moving them back to matcherIn
i = temp.length;
while ( i-- ) {
if ( (elem = temp[i]) ) {
matcherOut[ postMap[i] ] = !(matcherIn[ postMap[i] ] = elem);
}
}
}
if ( seed ) {
if ( postFinder || preFilter ) {
if ( postFinder ) {
// Get the final matcherOut by condensing this intermediate into postFinder contexts
temp = [];
i = matcherOut.length;
while ( i-- ) {
if ( (elem = matcherOut[i]) ) {
// Restore matcherIn since elem is not yet a final match
temp.push( (matcherIn[i] = elem) );
}
}
postFinder( null, (matcherOut = []), temp, xml );
}
// Move matched elements from seed to results to keep them synchronized
i = matcherOut.length;
while ( i-- ) {
if ( (elem = matcherOut[i]) &&
(temp = postFinder ? indexOf( seed, elem ) : preMap[i]) > -1 ) {
seed[temp] = !(results[temp] = elem);
}
}
}
// Add elements to results, through postFinder if defined
} else {
matcherOut = condense(
matcherOut === results ?
matcherOut.splice( preexisting, matcherOut.length ) :
matcherOut
);
if ( postFinder ) {
postFinder( null, results, matcherOut, xml );
} else {
push.apply( results, matcherOut );
}
}
});
}以上就是本文的全部内容，希望对大家的学习有所帮助，更多相关内容请关注PHP中文网！
相关推荐：
利用JavaScript中发出HTTP请求的方法
关于Ajax如何实现跨域访问的问题介绍
JavaScript，C和瀏覽器之間的關係May 01, 2025 am 12:06 AM
node.js流帶打字稿Apr 30, 2025 am 08:22 AM
Python vs. JavaScript：性能和效率注意事項Apr 30, 2025 am 12:08 AM
JavaScript的起源：探索其實施語言Apr 29, 2025 am 12:51 AM
幕後：什麼語言能力JavaScript？Apr 28, 2025 am 12:01 AM
Python和JavaScript的未來：趨勢和預測Apr 27, 2025 am 12:21 AM
Python vs. JavaScript：開發環境和工具Apr 26, 2025 am 12:09 AM
JavaScript是用C編寫的嗎？檢查證據Apr 25, 2025 am 12:15 AM
