博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
jQuery 2.0.3 源码分析Sizzle引擎 - 超级匹配
阅读量:5872 次
发布时间:2019-06-19

本文共 6918 字,大约阅读时间需要 23 分钟。

 声明:本文为原创文章,如需转载,请注明来源并保留原文链接,谢谢!

通过Expr.find[ type ]我们找出选择器最右边的最终seed种子合集

通过Sizzle.compile函数编译器,我们把tokenize词法元素编译成闭包函数

超级匹配superMatcher,用佳的方式从seed种子集合筛选出需要的数据

也就是通过seed与compile的匹配,得出最终的结果了

 


 superMatcher 函数

这个方法并不是一个直接定义的方法,通过matcherFromGroupMatchers( elementMatchers, setMatchers )方法return出来的一个curry化的函数,但是最后执行起重要作用的是它。

注意是compile()().

compile( selector, match )(        seed,        context,        !documentIsHTML,        results,        rsibling.test( selector ) && testContext( context.parentNode ) || context    );

superMatcher方法会根据参数seed 、expandContext和context确定一个起始的查询范围

elems = seed || byElement && Expr.find["TAG"]( "*", outermost ),

有可能是直接从seed中查询过滤,也有可能在context或者context的父节点范围内。如果不是从seed开始,那只能把整个DOM树节点取出来过滤了,把整个DOM树节点取出来过滤了,它会先执行Expr.find["TAG"]( "*", outermost )这句代码等到一个elems集合(数组合集)

context.getElementsByTagName( tag );

可以看出对于优化选择器,最右边应该写一个作用域的搜索范围context比较好

 

开始遍历这个seed种子合集了

while ( (matcher = elementMatchers[j++]) ) {    if ( matcher( elem, context, xml ) ) {        results.push( elem );        break;    }}

elementMatchers:就是通过分解词法器生成的闭包函数了,也就是“终极匹配器”

为什么是while?

前面就提到了,tokenize选择器是可以用过 “,”逗号分组 group,所以就就会有个合集的概念了

matcher就得到了每一个终极匹配器

通过代码很能看出来matcher方法运行的结果都是bool值

对里面的元素逐个使用预先生成的matcher方法做匹配,如果结果为true的则直接将元素堆入返回结果集里面。

 


matcher

matcher 就是 elementMatcher函数的包装

整个匹配的核心就在这个里面了

function( elem, context, xml ) {            var i = matchers.length;            while ( i-- ) {                if ( !matchers[i]( elem, context, xml ) ) {                    return false;                }            }            return true;        } :

我们先来回顾下这个matchers的组合原理

这个地方是最绕的,也是最晕的,所以还是要深入的理解才行哦

先上个简单的流程图:

画的不好 哈哈

 

执行分解:

第一步:

div > p + div.aaron input[type="checkbox"]

从右边剥离出原生API能使用的接口属性

context.getElementsByTagName( input )

所以找到了input ,因为只可以用 tag是查询,但是此时结果是个合集,引入seed的概念,称之为种子合集

 

第二步:

div > p + div.aaron [type="checkbox"]'

重组选择器,踢掉input,得到新的tokens词法元素哈希表

 

第三步:

通过matcherFromTokens函数,然后根据 关系选择器 【'>',"空","~","+"】拆分分组,因为DOM中的节点都是存在关系的,所以引入

Expr.relative -> first:true 两个关系的“紧密”程度, 用于组合最佳的筛选

一次按照如下顺序解析并且编译闭包函数

编译规则:div > p + div.aaron [type="checkbox"]' 编译成4组闭包函数,然后在前后在合并组合成一组
div >p +div.aaron input[type="checkbox"]

 

先看构造一组编译函数

A: 抽出div元素, 对应的是TAG类型
B: 通过Expr.filter找到对应匹配的处理器,返回一个闭包处理器
如:TAG方法

"TAG": function( nodeNameSelector ) {            var nodeName = nodeNameSelector.replace( runescape, funescape ).toLowerCase();            return nodeNameSelector === "*" ?                function() { return true; } :                function( elem ) {                    return elem.nodeName && elem.nodeName.toLowerCase() === nodeName;                };        },

C:将返回的curry方法放入到matchers匹配器组中,继续分解

D:抽出子元素选择器 '>' ,对应的类型 type">" 

E:通过Expr.relative找到elementMatcher方法分组合并多个词素的的编译函数

function( elem, context, xml ) {            var i = matchers.length;            while ( i-- ) {                if ( !matchers[i]( elem, context, xml ) ) {                    return false;                }            }

所以这里其实就是执行了各自Expr.filter匹配中的的判断方法了,看到这里matcher方法原来运行的结果都是bool值,

所以这里只返回了一个组合闭包,通过这个筛选闭包,各自处理自己内部的元素

F:返回的这个匹配器还是不够的,因为没有规范搜索范围的优先级,所以这时候还要引入addCombinator方法

G:根据Expr.relative -> first:true 两个关系的“紧密”程度

如果是是亲密关系addCombinator返回

function( elem, context, xml ) {    while ( (elem = elem[ dir ]) ) {        if ( elem.nodeType === 1 || checkNonElements ) {            return matcher( elem, context, xml );        }    }}

所以可见如果是紧密关系的位置词素,找到第一个亲密的节点,立马就用终极匹配器判断这个节点是否符合前面的规则

 

这是第一组终极匹配器的生成流程了

可见过程极其复杂,被包装了三层

依次

addCombinator

elementMatcher
Expr.relative

 

三个方法嵌套处理出来的结构

 

然后继续分解下一组,遇到关系选择器又继续依照以上的过程分解

但是有一个不同的地方,下一个分组会把上一个分组给一并合并了

所以整个关系就是一个依赖嵌套很深的结构

最终暴露出来的终极匹配器其实只有一个闭包,但是有内嵌很深的分组闭包了

依照从左边往右依次生成闭包,然后把上一组闭包又push到下一组闭包

就跟栈是一种后进先出的数据结构一样处理了

所以在最外层也就是

type=["checkbox"]

 


我们回到superMatcher方法的处理了

在遍历seed种子合集,依次匹配matchers闭包函数,传入每一个seed的元素与之匹配(这里就是input),在对应的编译处理器中通过对input的处理,找到最优匹配结果

function( elem, context, xml ) {    var i = matchers.length;    while ( i-- ) {        if ( !matchers[i]( elem, context, xml ) ) {            return false;        }    }    return true;} :

这里注意了,是i--,从后往前找

所以第一次开始匹配的就是

check: "checkbox"name: "type"operator: "="

那么就找到对应的Attr处理方法

//属性元匹配器工厂//name :属性名//operator :操作符//check : 要检查的值//例如选择器 [type="checkbox"]中,name="type" operator="=" check="checkbox"Expr.filter["ATTR"] = function( name, operator, check ) {   //返回一个元匹配器  return function( elem ) {    //先取出节点对应的属性值    var result = Sizzle.attr( elem, name );     //看看属性值有木有!    if ( result == null ) {      //如果操作符是不等号,返回真,因为当前属性为空 是不等于任何值的      return operator === "!=";    }    //如果没有操作符,那就直接通过规则了    if ( !operator ) {      return true;    }     //转成字符串    result += "";      return       //如果是等号,判断目标值跟当前属性值相等是否为真      operator === "=" ? result === check :       //如果是不等号,判断目标值跟当前属性值不相等是否为真      operator === "!=" ? result !== check :       //如果是起始相等,判断目标值是否在当前属性值的头部      operator === "^=" ? check && result.indexOf( check ) === 0 :       //这样解释: lang*=en 匹配这样 的节点      operator === "*=" ? check && result.indexOf( check ) > -1 :       //如果是末尾相等,判断目标值是否在当前属性值的末尾      operator === "$=" ? check && result.slice( -check.length ) === check :       //这样解释: lang~=en 匹配这样 的节点      operator === "~=" ? ( " " + result + " " ).indexOf( check ) > -1 :       //这样解释: lang=|en 匹配这样 的节点      operator === "|=" ? result === check || result.slice( 0, check.length + 1 ) === check + "-" :      //其他情况的操作符号表示不匹配      false;  };},

 

Sizzle.attr( elem, name )

传入elem元素就是seed中的input元素,找到是否有'type'类型的属性,

比如

"

所以第一次匹配input就出错了,返回的type是text,而不是我们需要的'checkbox'

这里返回的结果就是false,所以整个之后的处理就直接return了

 


 

继续拿出第二个input

继续上一个流程,这时候发现检测到的属性

var result = Sizzle.attr( elem, name );
result: "checkbox"

此时满足第一条匹配,然后继续 i = 0

!matchers[i]( elem, context, xml )

找到第0个编译函数

addCombinator
while ( (elem = elem[ dir ]) ) {    if ( elem.nodeType === 1 || checkNonElements ) {        outerCache = elem[ expando ] || (elem[ expando ] = {});        if ( (cache = outerCache[ dir ]) && cache[0] === dirkey ) {            if ( (data = cache[1]) === true || data === cachedruns ) {                return data === true;            }        } else {            cache = outerCache[ dir ] = [ dirkey ];            cache[1] = matcher( elem, context, xml ) || cachedruns;            if ( cache[1] === true ) {                return true;            }        }    }}
如果是不紧密的位置关系
那么一直匹配到true为止
如祖宗关系的话,就一直找父亲节点直到有一个祖先节点符合规则为止
直接递归调用
matcher( elem, context, xml )

其实就是下一组闭包队列了,传入的上下文是 div.aaron,也就是<input type="checkbox"的父节点

function (elem, context, xml) {                var i = matchers.length;                //从右到左开始匹配                while (i--) {                    //如果有一个没匹配中,那就说明该节点elem不符合规则                    if (!matchers[i](elem, context, xml)) {                        return false;                    }                }                return true;        }

依照上面的规则,这样递归下去了,一层一层的匹配

 


可见它原来不是一层一层往下查,却有点倒回去向上做匹配、过滤的意思。Expr里面只有find和preFilter返回的是集合。

尽管到这里暂时还带着一点疑问,就是最后它为什么用的是逐个匹配、过滤的方法来得到结果集,但是我想Sizzle最基本的“编译原理”应该已经解释清楚了。

本文转自艾伦 Aaron博客园博客,原文链接:http://www.cnblogs.com/aaronjs/p/3332805.html,如需转载请自行联系原作者

你可能感兴趣的文章
linux 添加永久路由的几种方法。
查看>>
解决vim中文乱码问题
查看>>
给apm换一个软件源
查看>>
Autobook中文版(七)—9.一个小的GNU Autotools项目
查看>>
Linux故障之grub
查看>>
linux操作系统-SSH原理介绍与免密运用与远程命令操作
查看>>
如何把hadoop源码关联到eclipse工程中
查看>>
Windows server 2008 R2搭建主域控制器 + 辅域控制器
查看>>
apache+tomcat小记
查看>>
Linux管道命令
查看>>
Vsftpd 虚拟用户配置参考---终极版
查看>>
我的友情链接
查看>>
亿级用户下的新浪微博平台架构
查看>>
公开课视频-浅谈前端性能测试
查看>>
SqlServer数据库同步方案详解
查看>>
mongodb集群分片环境搭建
查看>>
自定义可扩展叠加头部的下拉控件
查看>>
基础篇5-python基本数据类型讲解1.1
查看>>
[20190402]对比_mutex_wait_scheme不同模式cpu消耗.txt
查看>>
[Django学习] Django基础(5)_优化分页器
查看>>