欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

淺談Sizzle的“編譯原理”

 更新時間:2015年04月14日 10:05:49   投稿:hebedich  
正在學(xué)習(xí)Sizzle源碼或有一定前端基礎(chǔ)的同學(xué)們,可以一邊看源碼一邊看這些文章進(jìn)行驗證,所以雖然我會分析源碼中的正則表達(dá)式,有大量的注釋,但不會講正則表達(dá)式的基本用法!

Sizzle,是jQuery作者John Resig寫的DOM選擇器引擎,速度號稱業(yè)界第一。作為一個獨立全新的選擇器引擎,出現(xiàn)在jQuery 1.3版本之后,并被John Resig作為一個開源的項目。Sizzle是獨立的一部分,不依賴任何庫,如果你不想用jQuery,可以只用Sizzle,也可以用于其他框架如:Mool, Dojo,YUI等。

前幾天在準(zhǔn)備一個關(guān)于jQuery的分享PPT,問同事關(guān)于jQuery除了使用方法之外還有沒有其他特別想了解一下的,有人提到了想了解下它的選擇器是怎么實現(xiàn)的,也有人提到j(luò)Query的查詢速度跟其他框架比怎么樣。關(guān)于速度,sizzle的官方網(wǎng)站上可以下載測試的例子,速度確實很有優(yōu)勢。但是它為什么會有這樣高效的運行速度,就跟這里想探討的實現(xiàn)原理有關(guān)系了。

在了解Sizzle之前必須要先了解它的選擇器是怎么回事,這里有一個簡單的例子,熟悉jQuery的同學(xué)也一定很熟悉這樣的選擇器格式:

復(fù)制代碼 代碼如下:

tag #id .class , a:first

它基本上是從左到右層層深入過濾去查找匹配的dom元素,這個語句還不算復(fù)雜。假設(shè)我們自己來實現(xiàn)這一條查詢語句的話,也不難。但是,查詢語句只有基本的規(guī)則,沒有固定的選擇符個數(shù)和順序,我們自己寫代碼怎樣能適應(yīng)這種隨意的排列組合?Sizzle就能做到各種情況的正常解析、執(zhí)行。

Sizzle的源碼確實錯綜復(fù)雜不容易理清楚它的思路。先拋開外面層層的包裹,直接看看我個人認(rèn)為整個實現(xiàn)里很核心的三個方法:

第一個核心方法。源碼第1052行有一個tokenize函數(shù):

復(fù)制代碼 代碼如下:

function tokenize(selector, parseOnly ) { }

第二個參數(shù)parseOnly為false的意思是只做token序列化操作,不返回結(jié)果,這個情況下序列化的結(jié)果會被緩存起來備用。Selector就是查詢語句了。

經(jīng)過這個函數(shù)處理后,比如selector="#idtag.class , a:first"傳進(jìn)去,可以得到一個格式類似于下面的結(jié)果:

[
[
{matches:" id ",type:"ID"},
{matches:" tag ",type:"TAG"},
{matches:" class ",type:"CLASS"},
...
],
[
    {matches:" a",type:"TAG"},
    ...
],
[…],
…
]


看到tokenize這個函數(shù)的命名和它的作用,讓我很容易就聯(lián)想起“編譯原理”這個詞了。這里就有點像是詞法分析了,不過這個詞法分析比程序編譯時做的詞法分析簡單。

tokenize方法會根據(jù)selector里面的逗號,空格和關(guān)系選擇符的正則表達(dá)式做“分詞”,得到一個二維數(shù)組(請允許我冒用這個不是很準(zhǔn)確的稱呼),其中第一維數(shù)組是根據(jù)逗號分隔出來的,在源代碼里面被稱作groups。

我們再看源代碼第405行開始有一個Expr = Sizzle.selectors = {}的定義,其中到567行的時候有一個filter的定義,這里我們能找到基本的過濾類型:"ID"、"TAG"、"CLASS"、"ATTR"、"CHILD"、"PSEUDO",tokenize最終分類出來的type也就是這幾種。

“分詞”完成之后,依舊看在405行定義的Expr= Sizzle.selectors = {}。這里面能找到我們熟悉的所有選擇符,每個選擇符對應(yīng)一個方法定義。到這里應(yīng)該想到Sizzle其實是不是就是通過對selector做“分詞”,打散之后再分別從Expr里面去找對應(yīng)的方法來執(zhí)行具體的查詢或者過濾的操作?

答案基本是肯定的。但是Sizzle有更具體和巧妙的做法。再來看我認(rèn)為很核心的第二個方法:

源代碼1293行有一個matcherFromTokens函數(shù):

復(fù)制代碼 代碼如下:

function matcherFromTokens(tokens) { }

傳入的參數(shù)正是從tokenize方法得到的。Matcher可以理解成是“匹配程序”的意思,光從字面上看這個函數(shù)起的作用就是通過tokens生成匹配程序。事實上確實如此。限于篇幅,這篇文章暫且只分享我理解到的一些Sizzle的實現(xiàn)原理,不貼源碼。后面有時間我或者再整理一篇更詳盡的源碼分析的文章。

matcherFromTokens方法證實了前面的設(shè)想,它充當(dāng)了selector“分詞”與Expr中定義的匹配方法的串聯(lián)與紐帶的作用,可以說選擇符的各種排列組合都是能適應(yīng)的了。Sizzle巧妙的就是它沒有直接將拿到的“分詞”結(jié)果與Expr中的方法逐個匹配逐個執(zhí)行,而是先根據(jù)規(guī)則組合出一個大的匹配方法,最后一步執(zhí)行。但是組合之后怎么執(zhí)行的,還得再看關(guān)鍵的第三個方法:

源代碼1350行有一個superMatcher方法:

復(fù)制代碼 代碼如下:

superMatcher = function( seed, context, xml, results, expandContext ) { }

這個方法并不是一個直接定義的方法,而是通過1345行的matcherFromGroupMatchers( elementMatchers, setMatchers )方法return出來的,但是最后執(zhí)行起重要作用的是它。

superMatcher方法會根據(jù)參數(shù)seed、expandContext和context確定一個起始的查詢范圍,有可能是直接從seed中查詢過濾,也有可能在context或者context的父節(jié)點范圍內(nèi)。如果不是從seed開始,那么它會先執(zhí)行Expr.find["TAG"]( "*", expandContext && context.parentNode || context )這句代碼等到一個elems集合(數(shù)組)。然后對elems做一個遍歷,對里面的元素逐個使用預(yù)先生成的matcher方法做匹配,如果結(jié)果為true的則直接將元素堆入返回結(jié)果集里面。

好吧,看到這里matcher方法原來運行的結(jié)果都是bool值,我們再返回405行看一下Expr里面filter包含的方法,都是返回bool值的。包括PSEUDO(偽類)對應(yīng)的更多的偽類方法都一樣。似乎有點顛覆我最初的設(shè)想,它原來不是一層一層往下查,卻有點倒回去向上做匹配、過濾的意思。Expr里面只有find和preFilter返回的是集合。

盡管到這里暫時還帶著一點疑問,就是最后它為什么用的是逐個匹配、過濾的方法來得到結(jié)果集,但是我想Sizzle最基本的“編譯原理”應(yīng)該已經(jīng)解釋清楚了。

但是疑問不能留著,我們繼續(xù)。其實這篇文章本身已經(jīng)有點倒過來寫的味道了。有興趣看源碼的同學(xué)不會一開始就看到這三個關(guān)鍵的方法。實際上Sizzle在進(jìn)入這三個方法之前,還做了一系列的其他工作。

Sizzle的真正入口可以說是在源碼的220行:

復(fù)制代碼 代碼如下:

function Sizzle( selector, context, results, seed ){ }

這個方法前面一段比較容易懂,如果能匹配到selector是單一的ID選擇符(#id),則先根據(jù)id就直接用context.getElementById( m )方法把元素找出來。如果能匹配到selector是單一的TAG選擇符,也先直接用context.getElementsByTagName( selector )方法把相關(guān)的元素找出來。如果當(dāng)前瀏覽器只是原生的getElementsByClassName,并且匹配到selector是單一的CLASS選擇符,也會也用context.getElementsByClassName( m )方法把相關(guān)的元素找出來。這個三個方法,都是瀏覽器支持的原生方法,執(zhí)行效率肯定是最高的。

如果最基本的方法都用不上的話,才會進(jìn)入到select方法。源碼1480行有它的定義:

復(fù)制代碼 代碼如下:

function select( selector, context, results, seed, xml ) { }

在select方法里面,首先會對selector做我們前面提到的“分詞”操作。但是這個操作之后并沒有直接開始組裝匹配方法,而是先做了一些find的操作。這里的find操作就可以對應(yīng)到Expr里面的find,它執(zhí)行的是查詢操作,返回的是結(jié)果集。

可以這樣理解,select利用“分詞”得到的選擇符根據(jù)它的type先將可以用find方法查找的結(jié)果集查出來。做find操作的時候,是按照選擇符的順序從左到右縮小結(jié)果集范圍的。如果一個遍歷下來,selector中的所有選擇符都可以執(zhí)行find操作,則直接將結(jié)果返回。否則,就進(jìn)入前面介紹的“編譯”執(zhí)行過濾的流程了。

到這里,也可以順過來,基本上理清楚Sizzle的工作流程了。前面留下的疑問到此時其實也不算疑問了,因為執(zhí)行反向匹配過濾的時候,它的查找范圍已經(jīng)是經(jīng)過層層過濾的最小集合了。而反向匹配過濾的方法對于它所對應(yīng)的那些選擇符,比如偽類之類的,其實也已經(jīng)是一個高效的選擇。

再來簡單總結(jié)為什么Sizzle很高效。

首先,從處理流程上,它總是先使用最高效的原生方法來做處理。前面一直在介紹的還只是Sizzle自身的選擇器實現(xiàn)方法,真正Sizzle執(zhí)行的時候,它還會先判斷當(dāng)前瀏覽器是否支持querySelectorAll原生方法(源代碼1545行)。如果支持的話,則優(yōu)先選用此方法,瀏覽器原生支持的方法,效率肯定比Sizzle自己js寫的方法要高,優(yōu)先使用也能保證Sizzle更高的工作效率。(關(guān)于querySelectorAll可以上網(wǎng)查閱更多資料)。在不支持querySelectorAll方法的情況下,Sizzle也是優(yōu)先判斷是不是可以直接使用getElementById、getElementsByTag、getElementsByClassName等方法解決問題。

其次,相對復(fù)雜的情況,Sizzle總是選擇先盡可能利用原生方法來查詢選擇來縮小待選范圍,然后才會利用前面介紹的“編譯原理”來對待選范圍的元素逐個匹配篩選。進(jìn)入到“編譯”這個環(huán)節(jié)的工作流程有些復(fù)雜,效率相比前面的方法肯定會稍低一些,但Sizzle在努力盡量少用這些方法,同時也努力讓給這些方法處理的結(jié)果集盡量小和簡單,以便獲得更高的效率。

再次,即便進(jìn)入到這個“編譯”的流程,Sizzle還做了我們前面為了優(yōu)先解釋清楚流程而暫時忽略、沒有介紹的緩存機(jī)制。源代碼1535行是我們所謂的“編譯”入口,也就是它會調(diào)用第三個核心方法superMatcher。跟蹤進(jìn)去看1466行,compile方法將根據(jù)selector生成的匹配函數(shù)緩存起來了。還不止如此,再到1052行看tokenize方法,它其實也將根據(jù)selector做的分詞結(jié)果緩存起來了。也就是說,當(dāng)我們執(zhí)行過一次Sizzle (selector)方法以后,下次再直接調(diào)用Sizzle (selector)方法,它內(nèi)部最耗性能的“編譯”過程不會再耗太多性能了,直接取之前緩存的方法就可以了。我在想所謂“編譯”的最大好處之一可能也就是便于緩存,所謂“編譯”在這里可能也就可以理解成是生成預(yù)處理的函數(shù)存儲起來備用。

到此我希望基本能夠解答之前關(guān)心選擇器實現(xiàn)原理和執(zhí)行效率問題的同學(xué)的疑問了。另外本文分析結(jié)論源自于Sizzle最新版本源碼,文中提到的代碼行號以此版本源碼為準(zhǔn),可以從http://sizzlejs.com/下載。時間倉促,分析有不周到的地方拍磚請手下留情,還有疑問的同學(xué)歡迎線下繼續(xù)交流。

以上所述就是本文的全部內(nèi)容了,希望大家能夠喜歡。

相關(guān)文章

  • 淺談Sizzle的“編譯原理”

    淺談Sizzle的“編譯原理”

    正在學(xué)習(xí)Sizzle源碼或有一定前端基礎(chǔ)的同學(xué)們,可以一邊看源碼一邊看這些文章進(jìn)行驗證,所以雖然我會分析源碼中的正則表達(dá)式,有大量的注釋,但不會講正則表達(dá)式的基本用法!
    2015-04-04
  • requireJS使用指南

    requireJS使用指南

    如今最常用的JavaScript庫之一是RequireJS。最近我參與的每個項目,都用到了RequireJS,或者是我向它們推薦了增加RequireJS。在這篇文章中,我將描述RequireJS是什么,以及它的一些基礎(chǔ)場景。 
    2016-04-04
  • TypeScript中的遞歸類型示例解析

    TypeScript中的遞歸類型示例解析

    這篇文章主要為大家介紹了TypeScript中的遞歸類型示例解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-04-04
  • 使用three.js 畫漸變的直線

    使用three.js 畫漸變的直線

    這篇文章主要介紹了使用three.js 畫漸變的直線的相關(guān)資料以及具體的實例代碼,有需要的小伙伴可以參考下
    2016-06-06
  • TypeScript數(shù)組實現(xiàn)棧與對象實現(xiàn)棧的區(qū)別詳解

    TypeScript數(shù)組實現(xiàn)棧與對象實現(xiàn)棧的區(qū)別詳解

    這篇文章主要為大家介紹了TypeScript數(shù)組實現(xiàn)棧與對象實現(xiàn)棧的區(qū)別詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-09-09
  • js庫Modernizr的介紹和使用

    js庫Modernizr的介紹和使用

    Modernizr是一個開源的JS庫,它使得那些基于訪客瀏覽器的不同(指對新標(biāo)準(zhǔn)支持性的差異)而開發(fā)不同級別體驗的設(shè)計師的工作變得更為簡單
    2015-05-05
  • laytpl 精致巧妙的JavaScript模板引擎

    laytpl 精致巧妙的JavaScript模板引擎

    laytpl是一款顛覆性的JavaScript模板引擎,它用巧妙的實現(xiàn)方式,將自身的體積變得小巧玲瓏,不僅性能接近極致,并且還具備傳統(tǒng)前端引擎的幾乎所有功能
    2014-08-08
  • Underscore.js常用方法總結(jié)

    Underscore.js常用方法總結(jié)

    這篇文章主要介紹了Underscore.js常用方法總結(jié),本文講解了Underscore.js概述、在node.js下安裝、與集合有關(guān)的方法、與對象有關(guān)的方法、與函數(shù)相關(guān)的方法等內(nèi)容,需要的朋友可以參考下
    2015-02-02
  • 移動設(shè)備web開發(fā)首選框架:zeptojs介紹

    移動設(shè)備web開發(fā)首選框架:zeptojs介紹

    這篇文章主要介紹了移動設(shè)備web開發(fā)首選框架:zeptojs介紹,他兼容jquery的API,所以學(xué)起來或用起來并不吃力,需要的朋友可以參考下
    2015-01-01
  • require.js使用方法的簡單代碼講解筆記

    require.js使用方法的簡單代碼講解筆記

    頁面需要加載多個js文件時,加載時瀏覽器會停止網(wǎng)頁渲染,加載文件越多,網(wǎng)頁失去響應(yīng)的時間就會越長;由于js文件之間存在依賴關(guān)系,必須嚴(yán)格保證加載順序,當(dāng)依賴關(guān)系很復(fù)雜的時候,代碼的編寫和維護(hù)都會變得困難。這種情況下require.js插件應(yīng)運而生。
    2022-12-12

最新評論