[點(diǎn)晴永久免費(fèi)OA][轉(zhuǎn)帖]瀏覽器工作原理
有許多瀏覽器正在被使用,截至2022年,使用最多的是:谷歌瀏覽器、蘋果的Safari、微軟的Edge和火狐。 但是,它們實(shí)際上是如何工作的,從我們?cè)诘刂窓谥墟I入網(wǎng)絡(luò)地址開始,到我們?cè)噲D訪問(wèn)的頁(yè)面顯示在屏幕上,會(huì)發(fā)生什么? 關(guān)于這個(gè)問(wèn)題的答案,一個(gè)極其簡(jiǎn)化的版本是:
很直接,對(duì)嗎?是的,但在這個(gè)看似超級(jí)簡(jiǎn)單的過(guò)程中還涉及更多的內(nèi)容。在這個(gè)系列中,我們將討論 1.導(dǎo)航導(dǎo)航是加載網(wǎng)頁(yè)的第一步。它指的是當(dāng)用戶通過(guò) DNS 查詢(解決網(wǎng)址問(wèn)題)導(dǎo)航到一個(gè)網(wǎng)頁(yè)的第一步是找到該網(wǎng)頁(yè)的靜態(tài)資源位置(HTML、CSS、Javascript和其他類型的文件)。如果我們導(dǎo)航到 example.com ,HTML 頁(yè)面位于 IP 地址為 93.184.216.34 的服務(wù)器上(對(duì)我們來(lái)說(shuō),網(wǎng)站是域名,但對(duì)計(jì)算機(jī)來(lái)說(shuō),它們是 IP 地址)。如果我們以前從未訪問(wèn)過(guò)這個(gè)網(wǎng)站,就必須進(jìn)行域名系統(tǒng)(DNS)查詢。
因此,當(dāng)我們請(qǐng)求進(jìn)行 DNS 查詢時(shí),我們實(shí)際做的是與這些服務(wù)器中的一個(gè)進(jìn)行對(duì)話,要求找出與example.com 名稱相對(duì)應(yīng)的IP地址。如果找到了一個(gè)對(duì)應(yīng)的 IP,就會(huì)返回。如果發(fā)生了一些情況,查找不成功,我們會(huì)在瀏覽器中看到一些錯(cuò)誤信息。 在這個(gè)最初的查詢之后,IP 地址可能會(huì)被緩存一段時(shí)間,所以下次訪問(wèn)同一個(gè)網(wǎng)站會(huì)更快,因?yàn)椴恍枰M(jìn)行 DNS 查詢(記住,DNS 查詢只發(fā)生在我們第一次訪問(wèn)一個(gè)網(wǎng)站時(shí))。 TCP (Transmission Control Protocol) 握手一旦瀏覽器知道了網(wǎng)站的 IP 地址,它將嘗試通過(guò) TCP 三次握手(也稱為 SYN-SYN-ACK,或者更準(zhǔn)確的說(shuō)是 SYN、SYN-ACK、ACK,因?yàn)?TCP 有三個(gè)消息傳輸,用于協(xié)商和啟動(dòng)兩臺(tái)計(jì)算機(jī)之間的TCP 會(huì)話),與持有資源的服務(wù)器建立連接。
TCP 握手是一種機(jī)制,旨在讓兩個(gè)想要相互傳遞信息的實(shí)體(在我們的例子中是瀏覽器和服務(wù)器)在傳輸數(shù)據(jù)之前協(xié)商好連接的參數(shù)。 因此,如果瀏覽器和服務(wù)器是兩個(gè)人,他們之間的對(duì)話會(huì)是這樣的: 瀏覽器向服務(wù)器發(fā)送一個(gè) SYNC 消息,要求進(jìn)行同步(同步意味著連接)
然后,服務(wù)器將回復(fù)一個(gè) SYNC-ACK 消息( SYNChronization 和 ACKnowledgement) 在最后一步,瀏覽器將回復(fù)一個(gè) ACK 信息 現(xiàn)在,TCP連接(雙向連接)已經(jīng)通過(guò)3次握手建立,TLS協(xié)商可以開始。 TLS協(xié)商對(duì)于通過(guò) HTTPS 建立的安全連接,需要進(jìn)行另一次握手。這種握手(TLS協(xié)商)決定了哪個(gè)密碼將被用于加密通信,驗(yàn)證服務(wù)器,并在開始實(shí)際的數(shù)據(jù)傳輸之前建立一個(gè)安全的連接。
在這一步驟中,瀏覽器和服務(wù)器之間還交換了一些信息
現(xiàn)在可以開始從服務(wù)器請(qǐng)求和接收數(shù)據(jù)了 2.獲取數(shù)據(jù)在上一節(jié)中,我們談到了 HTTP 請(qǐng)求在我們與服務(wù)器建立安全連接后,瀏覽器將發(fā)送一個(gè)初始的 HTTP GET 請(qǐng)求。首先,瀏覽器將請(qǐng)求頁(yè)面的 HTML 文件。它將使用 HTTP 協(xié)議來(lái)做這件事。
請(qǐng)求方法 - POST, GET, PUT, PATCH, delete 等 URI - 是統(tǒng)一資源識(shí)別符的縮寫。URIs 用于識(shí)別互聯(lián)網(wǎng)上的抽象或物理資源,如網(wǎng)站或電子郵件地址等資源。一個(gè) URI 最多可以有 5 個(gè)部分 scheme:用于說(shuō)明使用的是什么協(xié)議 authority:用于識(shí)別域名 path:用于顯示資源的確切路徑 query:用于表示一個(gè)請(qǐng)求動(dòng)作 fragment:用來(lái)指代資源的一部分 // URI parts scheme :// authority path ? query # fragment //URI example <https://example.com/users/user?name=Alice#address> https: // scheme name example.com // authority users/user // path name=Alice // query address // fragment HTTP 頭字段 - 是瀏覽器和服務(wù)器在每個(gè) HTTP 請(qǐng)求和響應(yīng)中發(fā)送和接收的字符串列表(它們通常對(duì)終端用戶是不可見的)。在請(qǐng)求的情況下,它們包含關(guān)于要獲取的資源或請(qǐng)求資源的瀏覽器的更多信息。 如果你想看看這些請(qǐng)求頭字段是什么樣子的,請(qǐng)進(jìn)入 Chrome 瀏覽器并打開開發(fā)者工具(F12)。進(jìn)入 Network 標(biāo)簽,選擇 HTTP 響應(yīng)一旦服務(wù)器收到請(qǐng)求,它將對(duì)其進(jìn)行處理并回復(fù)一個(gè) 狀態(tài)代碼 - 例如:200、400、401、504網(wǎng)關(guān)超時(shí)等(我們的目標(biāo)是 200 狀態(tài)代碼,因?yàn)樗嬖V我們一切正常,請(qǐng)求是成功的) 響應(yīng)頭字段 - 保存關(guān)于響應(yīng)的額外信息,如它的位置或提供它的服務(wù)器。 一個(gè) HTML 文檔的例子可以是這樣的 <!doctype HTML> <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title>我的頁(yè)面</title> <link rel="stylesheet" src="styles.css"/> <script src="mainscripts.js"></script> </head> <body> <h1 class="heading">這個(gè)是我的頁(yè)面</h1> <p>一個(gè)段落和一個(gè) <a href="<https://example.com/about>">鏈接</a></p> <div> <img src="myImage.jpg" alt="image description"/> </div> <script src="sideEffectsscripts.js"></script> </body> </html> 對(duì)于我前面提到的同一個(gè)搜索,響應(yīng)頭是這樣的 如果我們看一下HTML文檔,我們會(huì)發(fā)現(xiàn)它引用了不同的 CSS 和 Javascript 文件。這些文件不會(huì)被請(qǐng)求。在這個(gè)時(shí)候,只有 HTML 被請(qǐng)求并從服務(wù)器接收。 這個(gè)初始請(qǐng)求的響應(yīng)包含收到的第一個(gè)字節(jié)的數(shù)據(jù)。第一個(gè)字節(jié)的時(shí)間(TTFB)是指從用戶提出請(qǐng)求(在地址欄中輸入網(wǎng)站名稱)到收到第一個(gè) HTML 數(shù)據(jù)包(通常為14kb)的時(shí)間。 TCP 慢啟動(dòng)和擁塞算法
3.HTML 解析到目前為止,我們討論了導(dǎo)航和數(shù)據(jù)獲取。 今天我們將討論解析,特別是 我們看到在向服務(wù)器發(fā)出初始請(qǐng)求后,瀏覽器如何收到包含我們嘗試訪問(wèn)的網(wǎng)頁(yè)的 HTML 資源(第一塊數(shù)據(jù))的響應(yīng)。 現(xiàn)在瀏覽器的工作就是開始解析數(shù)據(jù)。
換句話說(shuō),解析意味著將我們編寫的代碼作為文本(HTML、CSS)并將其轉(zhuǎn)換為瀏覽器可以使用的內(nèi)容。 解析將由瀏覽器引擎完成(不要與瀏覽器的 Javascript 引擎混淆)。 瀏覽器引擎是每個(gè)主要瀏覽器的核心組件,它的主要作用是結(jié)合結(jié)構(gòu) (HTML) 和樣式 (CSS),以便它可以在我們的屏幕上繪制網(wǎng)頁(yè)。 它還負(fù)責(zé)找出哪些代碼片段是交互式的。 我們不應(yīng)將其視為一個(gè)單獨(dú)的軟件,而應(yīng)將其視為更大軟件(在我們的例子中為瀏覽器)的一部分。 有許多瀏覽器引擎,但大多數(shù)瀏覽器使用這三個(gè)活躍且完整引擎之一: Gecko 它是由 Mozilla 為 Firefox 開發(fā)的。 過(guò)去,它曾為其他幾種瀏覽器提供支持,但目前,除了 Firefox,Tor 和 Waterfox 是唯一仍在使用 Gecko 的瀏覽器。 它是用 C++ 和 Javascript 編寫的,自 2016 年起,還用 Rust 編寫。 WebKit 它主要由 Apple 為 Safari 開發(fā)。 它還為 GNOME Web (Epiphany) 和 Otter 提供支持。 (令人驚訝的是,在 iOS 上,包括 Firefox 和 Chrome 在內(nèi)的所有瀏覽器也由 WebKit 提供支持)。 它是用 C++ 編寫的。 Blink,Chromium 的一部分 它最初是 WebKit 的一個(gè)分支,主要由 Google 為 Chrome 開發(fā)。 它還為 Edge、Brave、Silk、Vivaldi、Opera 和大多數(shù)其他瀏覽器項(xiàng)目(一些通過(guò) QtWebEngine)提供支持。 它是用 C++ 編寫的。 現(xiàn)在我們了解了誰(shuí)將進(jìn)行解析,讓我們看看在從服務(wù)器接收到第一個(gè) HTML 文檔后到底發(fā)生了什么。 讓我們假設(shè)文檔如下所示: <!doctype HTML> <html> <head> <title>This is my page</title> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> </head> <body> <h1>This is my page</h1> <h3>This is a H3 header.</h3> <p>This is a paragraph.</p> <p>This is another paragraph,</p> </body> </html> 即使請(qǐng)求頁(yè)面的 HTML 大于初始的 14KB 數(shù)據(jù)包,瀏覽器也會(huì)開始解析并嘗試根據(jù)其擁有的數(shù)據(jù)呈現(xiàn)體驗(yàn)。 HTML 解析涉及兩個(gè)步驟:詞法分析 和 樹構(gòu)造(構(gòu)建稱為 DOM 樹的東西)。 詞法分析
詞法分析過(guò)程結(jié)束時(shí)的結(jié)果是一系列 0 個(gè)或多個(gè)以下標(biāo)簽:DOCTYPE、開始標(biāo)簽 ( 構(gòu)建 DOM創(chuàng)建第一個(gè) token 后, DOM 樹描述了 HTML 文檔的內(nèi)容。 實(shí)際上,DOM 比我們?cè)谠撃J街锌吹降母鼜?fù)雜,但我保持簡(jiǎn)單以便更好地理解(另外,我們將在以后的文章中更詳細(xì)地討論 DOM 及其重要性)。 此構(gòu)建階段是 解析器從上到下逐行工作。 當(dāng)解析器遇到非阻塞資源(例如圖像)時(shí),瀏覽器會(huì)向服務(wù)器請(qǐng)求這些圖像并繼續(xù)解析。 另一方面,如果它遇到阻塞資源(CSS 樣式表、在 HTML 的 部分添加的 Javascrpt 文件或從 CDN 添加的字體),解析器將停止執(zhí)行,直到所有這些阻塞資源都被下載。 這就是為什么,如果你正在使用 Javascript,建議在 HTML 文件的末尾添加 預(yù)加載器 & 使頁(yè)面更快Internet Explorer、WebKit 和 Mozilla 都在 2008 年實(shí)現(xiàn)了預(yù)加載器,作為處理阻塞資源的一種方式,尤其是腳本(我們之前說(shuō)過(guò),當(dāng)遇到腳本標(biāo)簽時(shí),HTML 解析將停止,直到腳本被下載并執(zhí)行)。 使用預(yù)加載器,當(dāng)瀏覽器卡在腳本上時(shí),第二個(gè)較輕的解析器會(huì)掃描 HTML 以查找需要檢索的資源(樣式表、腳本等)。 然后預(yù)加載器開始在后臺(tái)檢索這些資源,目的是在主 HTML 解析器到達(dá)它們時(shí)它們可能已經(jīng)被下載(如果這些資源已經(jīng)被緩存,則跳過(guò)此步驟)。 4.解析 CSS解析完 HTML 之后,就該解析 CSS(在外部 CSS 文件和樣式元素中找到)并構(gòu)建 CSSOM 樹(CSS 對(duì)象模型)。 當(dāng)瀏覽器遇到 CSS 樣式表時(shí),無(wú)論是外部樣式表還是嵌入式樣式表,它都需要將文本解析為可用于設(shè)置布局樣式的內(nèi)容。 瀏覽器將 CSS 變成的數(shù)據(jù)結(jié)構(gòu)稱為 CSSOM。 DOM 和 CSSOM 遵循相似的概念,因?yàn)樗鼈兌际菢?,但它們?code>不同的數(shù)據(jù)結(jié)構(gòu)。 就像從我們的 HTML 構(gòu)建 DOM 一樣,從 CSS 構(gòu)建 CSSOM 被認(rèn)為是一個(gè)「渲染阻塞 」過(guò)程。 詞法分析和構(gòu)建 CSSOM與 HTML 解析類似,CSS 解析從詞法分析開始。 CSS 解析器獲取字節(jié)并將它們轉(zhuǎn)換為字符,然后是標(biāo)簽,然后是節(jié)點(diǎn),最后它們被鏈接到 CSSOM 中。 瀏覽器會(huì)執(zhí)行一些稱為 瀏覽器從適用于節(jié)點(diǎn)的最通用規(guī)則開始(例如:如果節(jié)點(diǎn)是 body 元素的子節(jié)點(diǎn),則所有 body 樣式都由該節(jié)點(diǎn)繼承),然后通過(guò)應(yīng)用更具體的規(guī)則遞歸地優(yōu)化計(jì)算出的樣式。 這就是為什么我們說(shuō)樣式規(guī)則是級(jí)聯(lián)的。 假設(shè)我們有下面的 HTML 和 CSS: body { font-size: 16px; color: white; } h1 { font-size: 32px; } section { color: tomato; } section .mainTitle { margin-left: 5px } div { font-size: 20px; } div p { font-size: 8px; color: yellow; } 這段代碼的 CSSOM 看起來(lái)像這樣: 請(qǐng)注意,在上面的模式中,嵌套元素既有 由于我們的 CSS 可以有多個(gè)來(lái)源,并且它們可以包含適用于同一節(jié)點(diǎn)的規(guī)則,因此瀏覽器必須決定最終應(yīng)用哪個(gè)規(guī)則。 這就是 想象一下,您在機(jī)場(chǎng)尋找您的朋友 John。 如果你想通過(guò)喊他的名字找到他,你可以喊 “ John ”。 可能不止一個(gè) John 會(huì)同時(shí)出現(xiàn)在機(jī)場(chǎng),所以他們可能都會(huì)做出回應(yīng)。 更好的方法是用他的全名打電話給你的朋友,這樣當(dāng)你喊“John Doe”時(shí),你就有更好的機(jī)會(huì)找到他,因?yàn)椤?John Doe ”比“ John ”更具體。 同樣,假設(shè)我們有這個(gè)元素:
<a href="<https://dev.to/>">This is just a link!</a> </p> 以及這些 CSS 樣式: a { color: red; } p a { color: blue; } 您認(rèn)為瀏覽器會(huì)應(yīng)用哪條規(guī)則? 答案是第二條規(guī)則,因?yàn)?p 標(biāo)簽中的所有 a 標(biāo)簽選擇器比所有a 標(biāo)簽選擇器都具有更高的優(yōu)先級(jí)。 如果你想玩玩優(yōu)先級(jí),你可以使用這個(gè) 優(yōu)先級(jí)計(jì)算器。 重點(diǎn)CSS 規(guī)則是從右到左閱讀的,這意味著如果我們有這樣的代碼: 5. 執(zhí)行 Javascript在解析 CSS 并創(chuàng)建 CSSOM 的同時(shí),還會(huì)下載其他資產(chǎn),包括 Javascript 文件。 這要?dú)w功于我們?cè)谥拔恼轮刑岬降念A(yù)加載器。
所以,當(dāng)我們從服務(wù)器獲取 Javascript 文件后,代碼被解釋、編譯、解析和執(zhí)行。 計(jì)算機(jī)無(wú)法理解 Javascript 代碼,只有瀏覽器可以。 JS 代碼需要被翻譯成計(jì)算機(jī)可以使用的東西,這是 Javascript 瀏覽器引擎的工作(不要與瀏覽器引擎混淆)。 根據(jù)瀏覽器的不同,JS 引擎可以有不同的名稱和不同的工作方式。 Javascript 引擎javascript 引擎(有時(shí)也稱為 ECMAscript 引擎)是一種在瀏覽器中執(zhí)行(運(yùn)行)Javascript 代碼的軟件,而不僅僅是零部件(例如,V8 引擎是 Node.js 環(huán)境的核心組件)。 Javascript 引擎通常由 Web 瀏覽器供應(yīng)商開發(fā),每個(gè)主要瀏覽器都有一個(gè)。 我們說(shuō)過(guò),目前使用最多的瀏覽器是 Chrome、Safari、Edge 和 Firefox。 每個(gè)都使用不同的 Javascript 引擎,它們是: V8 V8 是 Google 的高性能 Javascript 引擎。 它是用 C++ 編寫的,用于 Chrome 和 Node.js 等。 它實(shí)現(xiàn)了 ECMAscript(一種 Javascript 標(biāo)準(zhǔn),旨在確保網(wǎng)頁(yè)在不同 Web 瀏覽器之間的互操作性)和 WebAssembley。 它實(shí)現(xiàn)了 ECMA-262。 JavascriptCore JavascriptCore 是 WebKit 的內(nèi)置 Javascript 引擎,它為 Safari 瀏覽器、郵件和 macOS 上使用的其他應(yīng)用程序提供支持。 它目前按照 ECMA-262 規(guī)范實(shí)現(xiàn) ECMAscript。 它也被稱為 SquirrelFish 或 SquirrelFish Extreme。 Chakra Chakra 是微軟為其 Microsoft Edge 網(wǎng)絡(luò)瀏覽器和其他 Windows 應(yīng)用程序開發(fā)的 Javascript 引擎。 它實(shí)現(xiàn)了 ECMAscript 5.1,并且對(duì) ECMAscript 6 有部分(不斷增加的)支持。它是用 C++ 編寫的。 SpiderMonkey SpiderMonkey 是 Mozilla 的 Javascript 和 WebAssembly 引擎。 它是用 C++、Javascript 和 Rust 編寫的,用于為 Firefox、Servo 和其他項(xiàng)目提供支持。 一開始,Javascript 引擎只是簡(jiǎn)單的解釋器。 我們今天使用的現(xiàn)代瀏覽器能夠執(zhí)行稱為即時(shí) (JIT) 編譯的功能,這是編譯和解釋的混合體。 編譯 在編譯過(guò)程中,一個(gè)稱為 解釋 在解釋過(guò)程中,解釋器逐行檢查 Javascript 代碼并立即執(zhí)行。 沒(méi)有進(jìn)行編譯,因此沒(méi)有創(chuàng)建目標(biāo)代碼(代碼的輸出由解釋器本身使用其內(nèi)部機(jī)制創(chuàng)建)。 舊版本的 Javascript 使用這種類型的代碼執(zhí)行。 即時(shí)編譯( JIT Compilation ) 即時(shí)編譯是給定語(yǔ)言的解釋器的一個(gè)特性,它試圖同時(shí)利用編譯和解釋。 是在純編譯期間,代碼是在執(zhí)行之前被編譯,然而在 JIT 編譯中,代碼在執(zhí)行時(shí)(在運(yùn)行時(shí))被編譯。 所以我們可以說(shuō)源代碼是動(dòng)態(tài)轉(zhuǎn)換為機(jī)器代碼的。 較新版本的 Javascript 使用這種類型的代碼執(zhí)行。 JIT 編譯的一個(gè)很重要的方面就是將源代碼編譯成當(dāng)前正在運(yùn)行的機(jī)器的機(jī)器碼指令。 這意味著生成的機(jī)器代碼是針對(duì)正在運(yùn)行的機(jī)器的 CPU 架構(gòu)進(jìn)行了優(yōu)化。 簡(jiǎn)而言之,這三個(gè)過(guò)程可以總結(jié)為:
今天, 請(qǐng)注意,我提到了舊版本和新版本的 Javascript。 不支持較新版本語(yǔ)言的瀏覽器將解釋代碼,而支持的瀏覽器將使用某些版本的 JIT 來(lái)執(zhí)行代碼(V8、Chakra JavascriptCore 和 SpiderMonkey 引擎都使用 JIT)。 事實(shí)上,盡管 Javascript 是一種解釋型語(yǔ)言(它不需要編譯),但如今大多數(shù)瀏覽器都會(huì)使用 JIT 編譯來(lái)運(yùn)行代碼,而不是純粹的解釋型語(yǔ)言。 Javascript 代碼是如何處理的當(dāng) Javascript 代碼進(jìn)入 Javascript 引擎時(shí),它首先被解析。 這意味著代碼被讀取,并且在這種情況下,代碼被轉(zhuǎn)換為稱為 假設(shè)我們有一個(gè)文件,其中包含一個(gè)只做一件事的程序,那就是定義一個(gè)變量: js復(fù)制代碼const age = 25; 這就是這行非常簡(jiǎn)單的代碼看起來(lái)像抽象語(yǔ)法樹的方式(我正在使用@babel/parser-7.16.12): 如果你想將一些 Javascript 轉(zhuǎn)換為抽象語(yǔ)法樹,你可以使用這個(gè)工具。 編寫變量后得到的 AST 實(shí)際上要大得多,在屏幕截圖中隱藏了更多節(jié)點(diǎn)。 構(gòu)建 AST 后,它會(huì)被翻譯成機(jī)器代碼并立即執(zhí)行,因?yàn)楝F(xiàn)代 Javascript 使用即時(shí)編譯。 這段代碼的執(zhí)行將由 Javascript 引擎完成,利用稱為“調(diào)用堆棧”的東西。
6.創(chuàng)建可訪問(wèn)(無(wú)障礙)樹除了我們一直在討論的所有這些樹(DOM、CSSOM 和 AST)之外,瀏覽器還構(gòu)建了一種稱為
一般而言,殘疾用戶可以并且確實(shí)在使用具有各種輔助技術(shù)的網(wǎng)頁(yè)。 他們使用屏幕閱讀器、放大鏡、眼動(dòng)追蹤、語(yǔ)音命令等。 為了讓這些技術(shù)發(fā)揮作用,它們需要能夠訪問(wèn)頁(yè)面的內(nèi)容。 由于他們無(wú)法直接讀取 DOM,因此 ACT 開始發(fā)揮作用。 可訪問(wèn)性樹是使用 DOM 構(gòu)建的,稍后輔助設(shè)備將使用它來(lái)解析和解釋我們正在訪問(wèn)的網(wǎng)頁(yè)的內(nèi)容。 ACT 就像 DOM 的語(yǔ)義版本,每次 DOM 更新時(shí)它都會(huì)更新。 每個(gè)需要暴露給輔助技術(shù)的 DOM 元素都會(huì)在 ACT 中有一個(gè)對(duì)應(yīng)節(jié)點(diǎn)。 在未構(gòu)建 ACT 之前,屏幕閱讀器無(wú)法訪問(wèn)內(nèi)容。 要查看可訪問(wèn)性樹的實(shí)際的樣子,您可以通過(guò) Google Chrome 瀏覽器。 打開調(diào)試器 (F12) 并轉(zhuǎn)到“元素”選項(xiàng)卡。 從那里,你可以在右側(cè)選擇“輔助功能”窗格。
我去 Google 并檢查了搜索輸入,這是我在“計(jì)算”屬性下的“輔助功能”窗格中得到的: 使用語(yǔ)義 HTML 的重要性超出了本文的范圍,但作為開發(fā)人員,我們都應(yīng)該記住,我們構(gòu)建的網(wǎng)站應(yīng)該可供所有希望使用它們的人使用。 如果您想閱讀有關(guān)該主題的更多信息,可以在此處找到一篇關(guān)于 Web 可訪問(wèn)性的很好的介紹性文章。 據(jù)互聯(lián)網(wǎng)協(xié)會(huì)無(wú)障礙訪問(wèn)特別興趣小組稱,目前全世界有超過(guò) 13 億人(約占世界人口的 15%)患有某種形式的殘疾。 7.渲染樹在解析階段構(gòu)建的樹(DOM、CSSOM)被組合成一種叫做 DOM 和 CSSOM 是使用 HTML 和 CSS 文件創(chuàng)建的。 這兩個(gè)文件包含不同類型的信息,樹的結(jié)構(gòu)也不同,那么渲染樹是如何創(chuàng)建的呢? 結(jié)合 DOM 和 CSSOM
以上步驟的結(jié)果將是一個(gè)包含所有可見節(jié)點(diǎn)、內(nèi)容和樣式的 布局(回流)階段渲染樹包含有關(guān)顯示哪些節(jié)點(diǎn)及其計(jì)算樣式的信息,但不包含每個(gè)節(jié)點(diǎn)的尺寸或位置。 接下來(lái)需要做的是計(jì)算這些節(jié)點(diǎn)在設(shè)備視口(瀏覽器窗口內(nèi))內(nèi)的確切位置及其大小。 這個(gè)階段稱為布局(在 Chrome、Opera、Safari 和 Internet Explorer 中)或重排(在 Firefox 中),但它們的意思相同。 瀏覽器在渲染樹的根部開始這個(gè)過(guò)程并遍歷它。 回流步驟不會(huì)只發(fā)生一次,而是每次我們更改 DOM 中影響頁(yè)面布局的某些內(nèi)容時(shí),即使是部分更改,都會(huì)觸發(fā)回流。 重新計(jì)算元素位置的情況示例如下:
讓我們來(lái)看一個(gè)非?;镜?HTML 示例,其中內(nèi)嵌了一些 CSS: html復(fù)制代碼<!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width,initial-scale=1" /> <title>Reflow</title> </head> <body> <div style="width: 100%; height: 50%"> <div style="width: 50%; height: 50%">This is the reflow stage!</div> </div> </body> </html> 上面的代碼只是說(shuō)在視口內(nèi)我們應(yīng)該有兩個(gè) div,其中第二個(gè)嵌套在第一個(gè)里面。 父 div 占據(jù)視口寬度的 100%和高度的 50%。第二個(gè) div 占據(jù)父 div 的 50% 這看起來(lái)像這樣: 這個(gè)過(guò)程的輸出是一個(gè) 繪畫(重繪)階段在瀏覽器決定哪些節(jié)點(diǎn)需要可見并計(jì)算出它們?cè)谝暱谥械奈恢煤螅涂梢栽谄聊簧侠L制它們(渲染像素)了。 這個(gè)階段也被稱為 就像布局階段一樣,繪畫階段不會(huì)只發(fā)生一次,而是每次我們改變屏幕上元素的外觀時(shí)。 這些情況的例子是:
繪畫意味著瀏覽器需要將元素的每個(gè)視覺(jué)部分繪制到屏幕上,包括文本、顏色、邊框、陰影和替換元素(如按鈕和圖像),并且需要超快地完成。 為了確保重繪可以比初始繪制更快地完成,屏幕上的繪圖通常被分解成幾層。 如果發(fā)生這種情況,則需要進(jìn)行合成。 分層和合成傳統(tǒng)意義上,網(wǎng)絡(luò)瀏覽器完全依賴 CPU 來(lái)呈現(xiàn)網(wǎng)頁(yè)內(nèi)容。 但現(xiàn)在即使是最小的設(shè)備也有高性能的 GPU,所有大部分實(shí)現(xiàn)方案都圍繞著 GPU 來(lái)尋求更好的體驗(yàn)。
通常,只有特定的任務(wù)會(huì)被重定向到 GPU,而這些任務(wù)可以由合成器線程單獨(dú)處理。 為了找出哪些元素需要在哪一層,主線程遍歷布局樹并創(chuàng)建層樹。 默認(rèn)情況下,只有一層(這些層的實(shí)現(xiàn)方式因?yàn)g覽器而異),但我們可以找到會(huì)觸發(fā)重繪的元素,并為每個(gè)元素創(chuàng)建一個(gè)單獨(dú)的層。 這樣,重繪不應(yīng)應(yīng)用于整個(gè)頁(yè)面,而且此過(guò)程將可以使用到 GPU 如果我們想向?yàn)g覽器提示某些元素應(yīng)該在一個(gè)單獨(dú)的層上,我們可以使用 謹(jǐn)記上面討論的兩種操作,回流和重繪,都是昂貴的,尤其是在像手機(jī)這樣處理能力低的設(shè)備上。 這就是為什么在處理 DOM 更改時(shí)我們應(yīng)該嘗試優(yōu)化它們(我將在我的 DOM 系列的未來(lái)一篇文章中詳細(xì)討論這一點(diǎn))。 有些動(dòng)作只會(huì)觸發(fā)重繪,有些動(dòng)作會(huì)同時(shí)觸發(fā)回流和重繪。
鏈接:https://juejin.cn/post/7204806134935306301 該文章在 2023/5/25 18:17:19 編輯過(guò) |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |