摘要:每種可解析的格式必須具有由詞匯及語法規則組成的特定的文法,這被稱為上下文無關文法。解析器將會從詞法分析器獲取一個新符號,并且嘗試用某一種語法規則去匹配它。第二個匹配到規則的是,它匹配到第三條語法規則。
銜接
接著上文繼續。
在構建好render樹后,瀏覽器就開始進行布局了。這意味著瀏覽器會給每個節點正確的坐標,讓它們出現在該出現的地方。下一步就是進行繪制了,瀏覽器將會遍歷render樹,每一個節點都會被UI后端層所繪制。
很重要的一點是,這整個過程是漸進性的。為了更好的用戶體驗,渲染引擎會盡快地解析內容到屏幕上。它并不會等到html完全被解析才開始創建和布局render樹。一部分內容被解析了,那它就會立刻被繪制到頁面上,這這個過程中,瀏覽器可能還在請求剩余部分的內容。
主要流程實例圖3 :Webkit 主要流程
圖4 :Mozilla 的Gecko渲染引擎主要流程
從圖3和圖4你可以看到,雖然Webkit和Gecko在某些術語上稍有不同,但是主要流程是基本相同的。
Gecko把可見的格式化元素組成的樹為“Frame”樹。每一個元素都是一個frame。Webkit則把每一個渲染對象組成的樹稱為render樹。對每一個元素的定位,Webkit稱為布局,而Gecko稱為回流。Webkit稱利用dom節點及樣式信息去構建render樹的過程為attachment,Gecko在html和dom樹之間附加了一層,這層稱為內容接收器,相當制造dom元素的工廠。下面將討論流程中的各個階段。
解析
解析是渲染引擎執行過程中非常重要的部分,我們將會稍微深入地去探討一下。讓我們先來簡單介紹一下什么是解析。
解析一個文檔意味著需要將內容翻譯成某種編碼能夠理解和使用的結構。而解析的結果通常是能夠表達文檔結構的節點樹。它被稱為解析樹或語法樹。
舉例來說,解析表達式“2+3-1”,應該返回如下的樹:
圖5:數學表達式的樹結構
語法
解析過程依賴于文檔遵從的語法規則——文檔的語言或格式。每種可解析的格式必須具有由詞匯及語法規則組成的特定的文法,這被稱為上下文無關文法。人類的語言不具有這一特點,所以不能被常規的解析技術所解析。
解析器-詞法分析器
解析過程可以被分為兩個過程-詞法分析和語法分析。
詞法分析是把輸入解釋成符號的過程,而符號,是組成語言的基本有效單元。它相當于字典中所有的單詞,用以組成和表現人類語言。
語法分析是指應用語法規則。
通常情況下,解析器將工作分配給兩個組件 - 詞法分析器(有時也被稱作標記解析器)主要負責把輸入分解成合法的符號,語法分析器主要負責依靠語法規則來分析文檔結構,并構建出解析樹。詞法分析器知道如何跳過類似空白符或者換行符之類的無關字符。
圖6:從源文檔到解析樹
解析過程是重復迭代的。解析器將會從詞法分析器獲取一個新符號,并且嘗試用某一種語法規則去匹配它。如果有規則匹配到了,那么該符號相應的節點將會被添加到解析樹中,然后解析器會接著解析下一個符號。
如果沒有規則可以匹配該符號,解析器將會在內部保存下這個符號,并繼續獲取下一個符號,直到有一條語法規則可以匹配所有內部存儲的符號。如果到最后還是沒有找到能夠匹配的規則,那么解析器將會拋出一個異常。這意味著該文檔不合法或者有語法錯誤。
轉換過程
通常情況下,解析樹并不是最終的結果。解析通常在轉換過程中使用,而轉換用于將輸入文檔轉成另一種格式。編譯過程就是一個例子。編譯器將源代碼編譯成機器碼時,首先做的就是把它解析成解析樹,然后再將解析樹轉化成機器碼文檔。
圖7:編譯流程
解析實例
在圖5中,我們基于一段數學表達式創建了一棵解析樹。讓我們來嘗試定義一門簡單的數學語言,然后看看解析過程。
詞匯表:我們的語言包括了整數、加號和減號。
語法:
我們的語言的基本組成時表達式、術語和操作符
可以包含多個表達式
兩個術語(term)通過操作符連接,這就形成一個表達式
操作符只能是加號或減號
一個術語(term)只能是一個整數或者一個表達式
讓我們來分析一下輸入“2+3-1”后發生了什么。
第一個匹配到規則的子串是“2”,根據規則5,它是一個術語(term)。第二個匹配到規則的是“2+3”,它匹配到第三條語法規則。下一次匹配將會在這個輸入的最后?!?+3-1”是一段表達式,因為我們已經知道“2+3”是一個術語(term),接下去的“-”是一個操作符,再后面“1”是一個整數,也就是術語(term),這匹配了規則3。而“2++”不會匹配任何語法,所以它是一個非法輸入。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/50724.html
摘要:值得注意的是,谷歌瀏覽器和大多數瀏覽器不同,每一個選項卡都是渲染引擎的一個實例,都擁有獨立的進程。組件之間的通信火狐和谷歌都發展了一個特殊的通信結構,后面我們將會單獨來講。渲染引擎我們所討論的幾款瀏覽器火狐谷歌都是基于兩種渲染引擎建立的。 寫在前面 這篇文章是一篇譯文,年代有點久,部分內容有過時,請讀者仔細閱讀,翻譯自How browser work,原文地址為點擊這里查看原文 簡介 ...
摘要:絕對底部前端掘金來自國外的設計達人,純,可以實現當正文內容很少時,底部位于窗口最下面。有效解決圖片使用單位邊角缺失的問題前端掘金起因在移動端使用布局時圖片也需要用單位。 CSS 絕對底部 - 前端 - 掘金來自國外的設計達人,純CSS,可以實現: 當正文內容很少時,底部位于窗口最下面。當改變窗口高度時,不會出現重疊問題。甚至,創造該CSS的人還專門成立一個網站介紹這個CSS底部布局方案...
摘要:從最開始的到封裝后的都在試圖解決異步編程過程中的問題。為了讓編程更美好,我們就需要引入來降低異步編程的復雜性。寫一個符合規范并可配合使用的寫一個符合規范并可配合使用的理解的工作原理采用回調函數來處理異步編程。 JavaScript怎么使用循環代替(異步)遞歸 問題描述 在開發過程中,遇到一個需求:在系統初始化時通過http獲取一個第三方服務器端的列表,第三方服務器提供了一個接口,可通過...
閱讀 2601·2021-11-15 11:38
閱讀 2618·2021-11-04 16:13
閱讀 17981·2021-09-22 15:07
閱讀 1014·2019-08-30 15:55
閱讀 3261·2019-08-30 14:15
閱讀 1663·2019-08-29 13:59
閱讀 3207·2019-08-28 18:28
閱讀 1575·2019-08-23 18:29