摘要：但對于很多資源，則可以利用協(xié)議減少網(wǎng)絡(luò)負(fù)載。采用的是多進(jìn)程的資源加載機(jī)制。目前大多數(shù)瀏覽器都有磁盤緩存機(jī)制，因?yàn)榫彺鏅C(jī)制確實(shí)能夠提高網(wǎng)頁的加載速度。

微信公眾號(hào)：愛寫bugger的阿拉斯加
如有問題或建議，請后臺(tái)留言，我會(huì)盡力解決你的問題。

此文章是我最近在看的【W(wǎng)ebKit 技術(shù)內(nèi)幕】一書的一些理解和做的筆記。
而【W(wǎng)ebKit 技術(shù)內(nèi)幕】是基于 WebKit 的 Chromium 項(xiàng)目的講解。
書接上文 瀏覽器內(nèi)核之WebKit 架構(gòu)與模塊

網(wǎng)絡(luò)和資源加載是網(wǎng)頁的加載和渲染過程中的第一步，加載的資源包括以下內(nèi)容：

在資源類的前面加上 “Cached” 字樣，是因?yàn)樾蕟栴}而引入的緩存機(jī)制，所有對資源的請求都會(huì)先獲取緩存中的信息， 以決定是否向服務(wù)器提出資源請求。

資源的緩存機(jī)制是提高資源使用效率的有效方法。

它的基本思想是建立一個(gè)資源的緩存池。

當(dāng) WebKit 需要請求資源的時(shí)候，先從資源池中查找是否存在相應(yīng)的資源。如果有，WebKit 則取出以便使用；如果沒有，WebKit 創(chuàng)建一個(gè)新的 CachedResource 子類的對象，并發(fā)送真正的請求給服務(wù)器，WebKit 收到資源后將其設(shè)置到該資源類的對象中去，以便于緩存后下次使用。這里緩存指的是內(nèi)存緩存，而不同于后面在網(wǎng)絡(luò)棧部份的磁盤緩存。

WebKit 從資源池中查找資源的關(guān)鍵字是 URL, 因?yàn)闃?biāo)記資源唯一的特征就是資源的 URL 。這也意味著，假如兩個(gè)資源有不同的 URL ，但是它們的內(nèi)容完全一樣，也被認(rèn)為是兩個(gè)不同的資源。其實(shí)，上面是個(gè)簡單的示意圖，真實(shí)的過程比這里要復(fù)雜，這其中涉及到了資源的生命周期和失效機(jī)制。

按照加載器的類型來分，WebKit 總共有三種類型的加載器。

由于從網(wǎng)絡(luò)獲取資源是一個(gè)非常耗時(shí)的過程，通常一些資源的加載是異步執(zhí)行的，也就是說網(wǎng)絡(luò)資源的獲取和加載不會(huì)阻礙當(dāng)前 WebKit 的渲染過程，例如圖片、CSS 文件。

當(dāng)然，網(wǎng)頁也存在某些特別的資源會(huì)阻礙主線程的渲染過程，例如 Javascript 代碼文件。這會(huì)嚴(yán)重影響 WebKit 下載資源的效率。因?yàn)橹骶€程被阻礙了，后面的解析工作沒有辦法繼續(xù)往下進(jìn)行，所以對于 HTML 網(wǎng)頁中后面使用的資源也沒有辦法知道并發(fā)送下載請求。

這時(shí)候，WebKit 會(huì)這樣：當(dāng)前的主線程被阻礙時(shí)，WebKit 會(huì)啟動(dòng)另外一個(gè)線程去遍歷后面的 HTMl 網(wǎng)頁，收集需要的資源 URL，然后發(fā)送請求，這樣就可以避免被阻礙。與此同時(shí)，WebKit 能夠并發(fā)下載這些資源，甚至并發(fā)下載 JavaScript 代碼資源。這種機(jī)制對于網(wǎng)頁的加載提速很是明顯。

資源池中的生命周期是什么呢？資源池不能無限大，必須要用相應(yīng)的機(jī)制來替換其中的資源，從而加入新的資源。資源池使用的機(jī)制其實(shí)很簡單，就是采用 LRU（Lease Recent Used 最近最少使用）算法。

另外一方面，當(dāng)一個(gè)資源加載后，通常它會(huì)被放入資源池，以便之后使用。問題是，WebKit 如何判斷下次使用的時(shí)候是否需要更新該資源從而對服務(wù)器重新請求？因?yàn)榉?wù)器可能在某段時(shí)間之后更新了該資源。

考慮這樣的場景，當(dāng)用戶打開網(wǎng)頁后，他想刷新當(dāng)前的頁面。這種情況下，資源池會(huì)出現(xiàn)怎樣的情況呢？是清除所有的資源，重新獲得？還是直接利用當(dāng)前的資源？都不是。對于某些資源，WebKit 需要直接重新發(fā)送請求，要求服務(wù)器將內(nèi)容重新發(fā)送過來。但對于很多資源，WebKit 則可以利用 HTTP 協(xié)議減少網(wǎng)絡(luò)負(fù)載。在 HTTP 協(xié)議的規(guī)范中對此有規(guī)定，瀏覽器可以發(fā)送消息確認(rèn)是否需要更新，如果有，瀏覽器則重新獲取該資源；否則就需要利用該資源。

WebKit 的做法是，首先判斷資源是否在資源池中，如果是，那么發(fā)送一個(gè) HTTP 請求給服務(wù)器，說明該資源在本地的一些信息，例如該資源什么時(shí)間修改的，服務(wù)器則根據(jù)該信息作判斷，如果沒有更新，服務(wù)器則發(fā)送回狀態(tài)碼 304 ，表明無需更新，那么直接利用資源池中原來的資源；否則。WebKit 申請下載最新的資源內(nèi)容。

資源的實(shí)際加載在各個(gè) WebKit 移植中有不同的實(shí)現(xiàn)。Chromium 采用的是多進(jìn)程的資源加載機(jī)制。

圖4-11 描述了關(guān)于 Chromium 如何利用多進(jìn)程架構(gòu)來完成資源的加載，主要是多個(gè) Render 進(jìn)程和 Browser 進(jìn)程之間的調(diào)用棧涉及的主要類。

Render 進(jìn)程在網(wǎng)頁的加載過程中需要獲取資源，但是由于安全性（實(shí)際上，當(dāng)沙箱模型打開的時(shí)候，Render 進(jìn)程是沒有權(quán)限去獲取資源的）和效率上（資源共享等問題）的考慮，Render 進(jìn)程的資源獲取實(shí)際上是通過進(jìn)程間通信將任務(wù)交給 Browser 進(jìn)程來完成，Browser 進(jìn)程有權(quán)限從網(wǎng)絡(luò)或者本地獲取資源。

在 Chromium 架構(gòu)的 Renderer 進(jìn)程中，ResourceHandleInternal 類通過 IPCResource-LoaderBridge 類同 Browser 進(jìn)程通信。IPCResourceLoaderBridge 類繼承自 ResourceLoaderBridge 類，其作用是負(fù)責(zé)發(fā)起請求的對象和回復(fù)結(jié)果的解釋工作，實(shí)際消息的接收和派發(fā)交給 ResourceDispatcher 類來處理。

資源統(tǒng)一交由 Browser 進(jìn)程來處理，這使得資源在不同網(wǎng)頁間的共享變得很容易。因?yàn)槊總€(gè) Renderer 進(jìn)程某段時(shí)間內(nèi)可能有多個(gè)請求，同時(shí)還有多個(gè) Renderer 進(jìn)程，Browser 進(jìn)程需要處理大量的資源請求，這就需要一個(gè)處理這些請求的調(diào)度器，這就是 Chromium 中的 ResourceScheduler。

上圖4-13 是 “ent” 所包括的主要子目錄，也是 Chromium 網(wǎng)絡(luò)棧的主要模塊。這里面除了一些基礎(chǔ)的部分，例如 HTTP 協(xié)議。NDS 解析等模塊，還包含了 Chromium 為了減少網(wǎng)絡(luò)時(shí)間 而引入的新技術(shù)，例如 SPDY 、QUIC 等

圖4-14 描述了從 URLRequest 類到 Socket 類之間的調(diào)用過程。以 HTTP 協(xié)議為例，圖中列出了建立 TCP 的 socket 連接過程中涉及的類。

首先是 URLRequest 類被上層調(diào)用并啟動(dòng)請求的時(shí)候，它會(huì)根據(jù) URL 的 “scheme” 來決定需要?jiǎng)?chuàng)建什么類型的請求?！皊cheme” 也就是 URL 的協(xié)議類型，例如 “http://”、“file://” ，也可以是自定義的 scheme ，例如 Android 系統(tǒng)的 “file://android_asset/”。 URLRequest 對創(chuàng)建的是一個(gè) URLRequestJob 子類的一個(gè)對象，例如圖中的 URLRequestJob 類。為了支持自定義的 scheme 處理方式， Chromium 使用工廠模式。

URLRequestJob 類和它的工廠類 URLRequestJobFactory 的管理工作都由 URLRequestJobManager 類負(fù)責(zé)?；舅悸肥牵脩艨梢栽谠擃愔凶远鄠€(gè)工廠，當(dāng)有 URLRquest 請求時(shí)，先由工廠檢查它是否需要處理該 “scheme” ,如果沒有，工廠管理類繼續(xù)交給下一個(gè)工廠類來處理。最后，如果沒有任何工廠能夠處理，Chromium 則交給內(nèi)置的工廠來檢查和處理是否為 “http://”、“ftp://”、或者 “file://” 等。

圖 4-15 就是描述這些類的關(guān)系。

當(dāng)用戶設(shè)置代理時(shí)，用戶代理依賴以下類來處理。

圖 4-17 不僅描述上面這些類，同時(shí)也描述了 Chromium 中獲取網(wǎng)絡(luò)代理的過程。圖中數(shù)據(jù)表示獲取網(wǎng)絡(luò)代理的次序，其中的分支 3.1 和 4.1 分別表示簡單的代理設(shè)置和代理腳本設(shè)置的處理過程。

如果沒有磁盤緩存，當(dāng)用戶訪問網(wǎng)頁的時(shí)候，每次瀏覽器都要需要從網(wǎng)站下載網(wǎng)頁，圖片、js 等資源，這其實(shí)費(fèi)力又不討好。解決這一問題的方法就是將之前瀏覽器下載的資源保存下來，存到磁盤中，以備今后使用。當(dāng)然，資源是有時(shí)效性的，也會(huì)變得不再有效，所以需要有相應(yīng)的退出機(jī)制來解決這一問題。目前大多數(shù)瀏覽器都有磁盤緩存機(jī)制，因?yàn)榫彺鏅C(jī)制確實(shí)能夠提高網(wǎng)頁的加載速度。

為了適應(yīng)網(wǎng)絡(luò)資源的本地緩存需求， Chromium 的本地磁盤緩存有幾個(gè)特性或者要求。

雖然需要緩存的資源可能很多，但磁盤空間不是無限大的，所以必須要有相應(yīng)的機(jī)制來移除合適的緩存資源，以便加入新的資源。

能夠確保在瀏覽器崩潰時(shí)不破壞文件，至少能夠保護(hù)原先在磁盤中的數(shù)據(jù)。

能夠高效和快速地訪問磁盤中現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)，支持同步和異步兩種訪問方式。

能夠避免同時(shí)存儲(chǔ)兩個(gè)相同的資源。

能夠很方便地從磁盤中刪除一個(gè)項(xiàng)，同時(shí)可以在操作一個(gè)項(xiàng)的時(shí)候不受其他請求的影響。

磁盤不支持多線程訪問，所以需要把所有磁盤緩存的操作放入多帶帶的一個(gè)線程。

升級(jí)版本時(shí)，如果磁盤緩存的內(nèi)部存儲(chǔ)結(jié)構(gòu)發(fā)生改變， Chromium 仍然能夠支持老版本的結(jié)構(gòu)。

內(nèi)部結(jié)構(gòu)主要有個(gè)類：Backend 和 Entry 。 Backend 類表示整個(gè)磁盤緩存，是所有針對磁盤緩存操作的主入口，表示的是一個(gè)緩存表。Entry 類指的是表中的表項(xiàng)。緩存通常是一個(gè)表，對于整個(gè)表的操作作用在 Backend 類中，包括創(chuàng)建表中的一個(gè)個(gè)項(xiàng)，每個(gè)項(xiàng)由關(guān)鍵字來唯一確定，這個(gè)關(guān)鍵字注是資源的 URL。而對項(xiàng)目內(nèi)的操作包括讀寫等都是由 Entry 類來處理。

Cookie 格式就是一系列的 “關(guān)鍵字+值” 對，一個(gè)簡單的例子如下：

test1 = webkit; test2 = chromium, Expires = Sun, 30 Oct 2016 21:35:00 GMT; Domain = .myweb.cm;

例子中包括兩個(gè)自定義的關(guān)鍵字，分別是 “test1” 和 “test2” ,它們的值分別為 “webkit” 和 “chromium” 。后面的則是預(yù)定義的關(guān)鍵字 “Expires” 和 “Domain”,表示的是該 Cookie 的失敗時(shí)間和該 Cookie 對應(yīng)的域。基于安全性考慮，一個(gè)網(wǎng)頁的 Cookie 只能被該網(wǎng)頁（或者說是該域的網(wǎng)頁）訪問。

根據(jù) Cookie 的時(shí)效性可以將 Cookie 分成兩種類型，第一種是會(huì)話型 Cookie （Session Cookie）。如果 Cookie 沒有設(shè)置失效時(shí)間，就是會(huì)話型 Cookie。第二種是持續(xù)型 Cookie （Persistent Cookie），也就是當(dāng)瀏覽器退出的時(shí)候，仍然保留 Cookie 的內(nèi)容。該類型的 Cookie 有一個(gè)有效期，在有效期內(nèi)，每次訪問該 Cookie 所屬域的時(shí)候，都需要將該 Cookie 發(fā)送給服務(wù)器，這樣服務(wù)器能夠有效追蹤用戶的行為。

Chromium 中支持 Cookie 的機(jī)制也較為簡單和清晰，如圖 4-23 所示的是 Chromium 所設(shè)計(jì)和使用的主要類及其關(guān)系。CookieMonster 是Cookie 機(jī)制中最重要的類，實(shí)際上相當(dāng)于 Cookie 管理器。

它包括幾個(gè)作用：

第一是實(shí)現(xiàn) CookieStore 的接口，它是對外的接口，調(diào)用者可以設(shè)置和獲得 Cookie；

第二是報(bào)告各種 Cookie 的事件，例如更新信息等，主要使用 Delegate 類，

第三是 Cookie 對象的集合，也就是 CanonicalCookie 的集合，每個(gè) CanonicalCookie 對象都是保存在內(nèi)存中的，當(dāng)需要存儲(chǔ)到磁盤的時(shí)候使用 PersistentCookieStore 類，具體由 SQLitePersistentCookieStore 類負(fù)責(zé)實(shí)際的存儲(chǔ)動(dòng)作。

HTTP 是一種使用明文來傳輸數(shù)據(jù)的應(yīng)用層協(xié)議。構(gòu)建在 SSL 之上的 HTTPS 提供了安全的網(wǎng)絡(luò)傳輸機(jī)制，現(xiàn)已被廣泛應(yīng)用于網(wǎng)絡(luò)上。典型的是電子商務(wù)、銀行支付方面的應(yīng)用。基本上所有的瀏覽器都支持該協(xié)議， Chromium 當(dāng)然也不例外。

不僅如此，Chromium 也支持一種新的標(biāo)準(zhǔn)，這就是 HSTS (HTTP Strict TransportSecurity)。該協(xié)議能夠讓網(wǎng)絡(luò)服務(wù)器聲明它只支持 HTTPS 協(xié)議，所以瀏覽器能夠理解服務(wù)器的聲明，發(fā)送基于 HTTPS 的連接和請求。通常情況下，瀏覽器用戶不會(huì)輸入 “scheme（http://）”，瀏覽器的補(bǔ)充功能通常會(huì)加入該 “scheme” ,但是，服務(wù)器可能需要輸入 ”https://“ 。在這樣子的情況下，該協(xié)議就顯得非常有用。一般情況下，服務(wù)在返回的消息頭中加入以下信息表明它支持該標(biāo)準(zhǔn)：

Strict-Transport-Security: max-age=16070400; includeSubDomains

Chromium 的網(wǎng)絡(luò)模塊有兩個(gè)重要目標(biāo)，其一是安全，其二是速度。為此，該項(xiàng)目引入了很多 WebKit 所沒有的新技術(shù)。

一次 DNS 查詢的平均時(shí)間大概是 60 ~ 120ms 之間或者更長，而 TCP 的三次握手時(shí)間大概也是幾十毫秒或者更長。為了有效減少這段時(shí)間，Chromium 引入了 DNS 預(yù)取和 TCP 預(yù)連接，它們都是由 Chromium 的 ”Predictor“ 機(jī)制來實(shí)現(xiàn)的。

首先是 DNS 預(yù)取技術(shù)。它的主要思想是利用現(xiàn)有的 DNS 機(jī)制，提前解析網(wǎng)頁中可能的網(wǎng)絡(luò)連接。具體來講，當(dāng)用戶正在瀏覽當(dāng)前網(wǎng)頁的時(shí)候，Chromium 提取網(wǎng)頁中的超鏈接，將域名抽取出來，利用比較少的 CPU 和網(wǎng)絡(luò)帶寬來解析這些域名或者 IP 地址，這樣一來，用戶根本感覺不到這一過程。當(dāng)用戶單擊這些鏈接的時(shí)候，可以節(jié)省不少時(shí)間，特別在域名解析比較慢的時(shí)候，效果特別明顯。

DNS 預(yù)取技術(shù)是利用系統(tǒng)的域名解析機(jī)制，好處是它不會(huì)阻礙當(dāng)前網(wǎng)絡(luò)棧的工作。DNS 預(yù)取技術(shù)針對多個(gè)域名采取并行處理的方式，每個(gè)域名的解析須由新開啟的一個(gè)線程來處理，結(jié)束后此線程即退出。

當(dāng)然， DNS 預(yù)取技術(shù)不僅應(yīng)用于網(wǎng)頁中的超鏈接，當(dāng)用戶在地址欄中輸入地址后，候選項(xiàng)同輸入的地址很匹配的時(shí)候，在用戶敲下回車鍵獲取網(wǎng)頁之前， Chromium 已經(jīng)開始使用 DNS 預(yù)取技術(shù)解析該域名了。

Chromium 使用追蹤技術(shù)來獲取用戶從什么網(wǎng)頁跳轉(zhuǎn)到另外一個(gè)網(wǎng)頁?？梢岳眠@些數(shù)據(jù)，一些啟發(fā)式規(guī)則和其他一些暗示來預(yù)測用戶下面會(huì)單擊什么超鏈接，當(dāng)有足夠的把握時(shí)，它便先 DNS 預(yù)取，更進(jìn)一步，還可以預(yù)先建立 TCP 連接。聽起來夠智能的吧，是的。但是這對用戶的隱私是一個(gè)極大的挑戰(zhàn)，它甚至能預(yù)測你單擊什么超鏈接。

同 DSN 預(yù)取技術(shù)一樣，追蹤技術(shù)不會(huì)應(yīng)用于網(wǎng)頁中的超鏈接，當(dāng)用戶在地址欄中輸入地址，如候選項(xiàng)同輸入的地址很匹配，則在用戶敲擊下回車鍵獲取該網(wǎng)頁之前，Chromium 就已經(jīng)開始嘗試建立 TCP 連接了。

很多時(shí)候，服務(wù)器和瀏覽器通話是按順序來的，瀏覽器發(fā)送一個(gè)請求給服務(wù)器，等到服務(wù)器的回復(fù)后，才會(huì)發(fā)送另外一個(gè)請求。弊端是效率極差。

HTTP 1.1 開始增加了管線化技術(shù)，Chromium 也支持這一技術(shù)，但它需要服務(wù)器的支持兩者配合才能實(shí)現(xiàn) HTTP 管線化。HTTP 管線化技術(shù)是一項(xiàng)同時(shí)將多個(gè) HTTP 請求一次性提交給服務(wù)器的技術(shù)，因此無需等待服務(wù)器的回復(fù)，因?yàn)樗赡軐⒍鄠€(gè) HTTP 請求填充在一個(gè) TCP 數(shù)據(jù)包內(nèi)。HTTP 管線化需要在網(wǎng)絡(luò)上傳輸較少的 TCP 數(shù)據(jù)包，因此減少了網(wǎng)絡(luò)負(fù)載。

圖4-24 描述了 HTTP 管線化技術(shù)是如何傳送請求和回復(fù)的。

請求結(jié)果的管線化使得 HTML 網(wǎng)頁加載時(shí)間動(dòng)態(tài)提升，特別是在具體有高延遲的連接環(huán)境下。在速度較快的網(wǎng)絡(luò)連接環(huán)境下，提速可能不是很明顯。因?yàn)檫@些請求還是有明顯的先后順序的。管線化機(jī)制需要通過永久連接（Persistent Connection）完成，并且只有 GET 和 HEAD 等請求可以進(jìn)行管線化，使用場景有很大的限制。

SPDY 就是為了解決網(wǎng)絡(luò)延遲和安全性問題。根據(jù) Google 的官方數(shù)據(jù)，使用 SPDY 協(xié)議的服務(wù)器和客戶端可以將網(wǎng)絡(luò)加載的時(shí)間減少 64。

SPDY 協(xié)議是一種新的會(huì)話層協(xié)議，因?yàn)榫W(wǎng)絡(luò)協(xié)議 是一種棧式結(jié)構(gòu)，它被定義在 HTTP 協(xié)議和 TCP 協(xié)議之間，SPDY 協(xié)議的核心思想 是多數(shù)復(fù)用，僅使用一個(gè)連接來傳輸一個(gè)網(wǎng)頁中的眾多資源。

QUIC 是一種新的網(wǎng)絡(luò)傳輸協(xié)議，主要目標(biāo)是改進(jìn) UDP 數(shù)據(jù)協(xié)議的能力。同 SPDY 建立在傳輸層之上不同，QUIC 所要解決的問題就是傳輸層的傳輸效率，并提供了數(shù)據(jù)的加密，所以，SPDY 可以在 QUIC 之上工作。

WebKit 和 Chromium 為了高效率地下載資源，設(shè)計(jì)出了各種各樣的策略和新技術(shù)。
## 12.1 DNS 和 TCP 連接

DNS 和 TCP 連接占用大量的時(shí)間，所以為了高效地加載網(wǎng)頁，網(wǎng)頁開發(fā)者可以從以下方面著手改變以減少這一部分的時(shí)間。

減少鏈接的重定向。有些網(wǎng)頁中使用了大量重定向，可能還會(huì)有很多次重定向，還不僅要求瀏覽器建立多次鏈接，同時(shí)還需要多次 DNS 解析，這會(huì)阻礙 DNS 預(yù)取技術(shù)的應(yīng)用，應(yīng)該盡量避免。

利用DNS預(yù)取機(jī)制。網(wǎng)頁的開發(fā)者當(dāng)然知道需要鏈接的 URL,為了讓瀏覽器也知道這些鏈接，開發(fā)者可以指定需要預(yù)取的 URL。

搭建支持 SPDY 協(xié)議的服務(wù)器，當(dāng)然指的是那些需要使用 HTTPS 協(xié)議的網(wǎng)站。

避免錯(cuò)誤的鏈接請求。有些網(wǎng)頁中包含了一些失效的鏈接，當(dāng)瀏覽器試圖獲取該鏈接對應(yīng)的資源的時(shí)候，就會(huì)占用網(wǎng)絡(luò)資源。

我們也可以通過減少網(wǎng)頁中所需的資源數(shù)量來改善網(wǎng)頁的加載：

在 HTML 網(wǎng)頁中內(nèi)嵌小型的資源，也就是當(dāng)資源比較小的時(shí)候，可以將它們直接放在網(wǎng)頁中，可能的資源如 CSS、JavaScript 和圖片等。比如圖片 用 webpack 直接打包成 base64。

合并一些資源，例如 CSS、JavaScript 和圖片。常見的就是一些網(wǎng)頁中大量使用的小圖片，可以將它們合并成一張大的圖片以供使用。

對于每個(gè)資源而言，通過減少它的數(shù)據(jù)量來提高網(wǎng)頁的加載速度：

使用瀏覽器本地磁盤緩存機(jī)制。因?yàn)?HTTP 協(xié)議支持資源的失效機(jī)制，通過對資源設(shè)置適當(dāng)?shù)氖趤頊p少瀏覽器對資源的重復(fù)獲取。

啟用資源的壓縮技術(shù)。例如，對于圖片而言，可以使用 zip 壓縮技術(shù)，然后在 HTTP 消息頭中說明該資源經(jīng)過壓縮，這樣可以有效減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。

希望本文對你有點(diǎn)幫助。

下期分享 第五章 HTML解釋器與模型 敬請期待。

對 全棧開發(fā) 有興趣的朋友可以掃下方二維碼關(guān)注我的公眾號(hào) —— 愛寫bugger的阿拉斯加

分享 web 開發(fā)相關(guān)的技術(shù)文章，熱點(diǎn)資源，全棧程序員的成長之路。

大家一起交流成長。

只要關(guān)注公眾號(hào)并回復(fù) 福利 便送你六套、并且每套價(jià)值 3999 元的視頻資源： Python、Java、Linux、Go、vue、react、javaScript