頁收發(fā)消息是一個常見的系統(tǒng)應(yīng)用場景，通常我們有兩種方式來完成消息的發(fā)送，一種是通過客戶端來拉取消息，一種是服務(wù)端推送消息，到底使用哪種方式好一點(diǎn)呢？

具體使用哪種方式，我們需要根據(jù)實(shí)際的業(yè)務(wù)場景來分析，沒有絕對正確的方式，只有適不適合。所以，我們分析一下網(wǎng)頁端的用戶一般都存在哪些應(yīng)用場景：

1. 系統(tǒng)將通知發(fā)送給用戶——這種場景下，用戶對于消息的實(shí)時性要求并不高
2. 用戶和用戶之間發(fā)送聊天消息——這種場景下，用戶就對實(shí)時性的要求很高了，越實(shí)時越好

我們拋開純技術(shù)實(shí)現(xiàn)不談，只是從解決方案來談，由于是使用的是網(wǎng)頁端，HTTP協(xié)議是通過“請求-響應(yīng)”的方式傳遞，網(wǎng)頁端和服務(wù)端之間是沒有消息通道的，那么怎么來實(shí)現(xiàn)消息的接收呢？

輪詢拉取

輪詢拉取可以說是所有消息的實(shí)現(xiàn)方案中最簡單的一種，實(shí)現(xiàn)起來也非常簡單。

大致的實(shí)現(xiàn)方法如下：

1. 發(fā)送方發(fā)送消息后，消息先進(jìn)入隊列中暫存（也可以是數(shù)據(jù)庫）
2. 網(wǎng)頁端建立一個timer，固定時間（例如：30秒）輪詢到隊列（或數(shù)據(jù)庫）中拉取消息
3. 無論有沒有拉到消息，收到返回的消息后，30秒后再次輪詢拉取

這種方式最大的優(yōu)勢就是實(shí)現(xiàn)非常簡單，而且容易理解，早期的聊天室基本都是這種實(shí)現(xiàn)方式，我曾經(jīng)給朋友做過一個答題的系統(tǒng)，有多個終端，每個終端看到的內(nèi)容需要有所不同，也是使用的這種實(shí)現(xiàn)方式。

當(dāng)然這種實(shí)現(xiàn)方式的缺點(diǎn)也是非常明顯：

1. 時效性差：隨著timer間隔時間的長短，收到消息的延時時間會被拉長，以30秒為例，消息最大的延時就會達(dá)到30秒
2. 效率差：網(wǎng)頁端會不停的請求服務(wù)器，但是發(fā)消息的頻率事實(shí)上并沒有這么高，如果10次輪詢才拉到一條消息，那么有效性只有10%，大量的浪費(fèi)了服務(wù)器資源

使用這種方式，時效性和效率是矛盾的，我降低timer的間隔時間，就可以提高時效性，但是會降低效率，例如：間隔時間降低到1秒，這種基本就可以趨近于實(shí)時了，但是可能300次輪詢才會拉到1條消息，有效性只有0.3%了。

所以，由于這個不可調(diào)和的矛盾存在，這種解決方案只能適用于一些同時在線用戶少，對實(shí)時性要求不高的場景中。

長連接

如果想要同時保證時效性和效率，其實(shí)長連接是一個不錯的選擇，一般我們的PC端聊天軟件都是使用的長連接方式來實(shí)現(xiàn)。而網(wǎng)頁端的長連接實(shí)現(xiàn)方式通常有兩種：

1. WebSocket
2. FlashSocket

FlashSocket就不說了，如果不是網(wǎng)頁游戲的話其實(shí)很少會用到這個方案來做長連接，它要求用戶必須安裝了Flash插件。如果是HTML網(wǎng)頁端的話，其實(shí)更多會選擇WebSocket這種方案，WebSocket的優(yōu)點(diǎn)非常明顯，建立一次握手以后，服務(wù)端和網(wǎng)頁端就可以雙向通信了，擺脫了HTTP的Request-Response的限制，消息的及時性和效率都大幅度的提升了。

但是WebSocket也不是那么簡單，其中的坑也非常的多，如何單個生產(chǎn)者推送給多個消費(fèi)者，如何保證不重復(fù)推送，斷線以后的重連等等。當(dāng)然更重要的是，不同的瀏覽器對于WebSocket的支持可能不同，兼容性也是一大問題，所以使用得并不是很多。

那有沒有一種更常用的方法來處理消息的接收呢？

HTTP長輪詢

想要建立一條HTTP長輪詢的通道，我們需要在瀏覽器和服務(wù)器之間建立一條通知連接。

而這條通知連接不同于普通的HTTP連接，它要有一些特殊性：

1. 這個HTTP連接只能用來收取推送的消息
2. 不同于普通的Request-Response HTTP請求，這個HTTP連接不會馬上響應(yīng)，會先被Hold在這里，知道接到通知的消息或者超過了約定的時間（我們都知道，HTTP請求是會有超時的，一般我們都會設(shè)置一個請求超時的閾值，如果超過這個閾值，那么請求就會被粗暴的斷開，返回一個錯誤消息，為了保證我們的請求不被粗暴的對待，我們需要在超時之前優(yōu)雅的返回一個結(jié)果）

怎么來Hold住這個請求呢？

場景一：隊列里面有消息

1. 發(fā)起一個通知連接HTTP請求
2. 發(fā)現(xiàn)消息隊列里面有消息，于是拿到消息然后立刻返回
3. 收到返回的消息后，立刻再次發(fā)起通知連接的請求

場景二：隊列里面沒有消息

1. 發(fā)起一個通知連接HTTP請求
2. 發(fā)現(xiàn)消息隊列里面沒有消息，于是一直等待直到達(dá)到時間閾值然后返回
3. 收到返回的消息后，立刻再次發(fā)起通知連接的請求

個人認(rèn)為，長輪詢的請求就一直保持對消息隊列的數(shù)據(jù)拉取就行，如果有實(shí)時的消息來了，也等到它進(jìn)入消息隊列以后再處理，這樣可以防止消息丟失，也可以降低系統(tǒng)的復(fù)雜度。

總的來說，網(wǎng)頁端的消息接收，用什么方式好呢？拉和推都可以，每種方式有每種方式的優(yōu)缺點(diǎn)。

1. 如果業(yè)務(wù)不復(fù)雜，實(shí)時性不高，建議輪詢拉取
2. 最佳方案是推，但是WebSocket和FlashSocket各有局限性，實(shí)現(xiàn)起來也麻煩一點(diǎn)
3. 常見方式就是長輪詢，需要開辟一條專用的消息通道

融界2024年7月9日消息，天眼查知識產(chǎn)權(quán)信息顯示，稅友軟件集團(tuán)股份有限公司取得一項名為“一種數(shù)據(jù)交互方法、系統(tǒng)、電子設(shè)備及存儲介質(zhì)“，授權(quán)公告號CN113010237B，申請日期為2021年3月。

專利摘要顯示，本發(fā)明公開了一種數(shù)據(jù)交互方法，包括：HTML程序利用HTML容器提供的服務(wù)接口生成本地資源獲取請求，并通過HTML容器的容器進(jìn)程將本地資源獲取請求發(fā)送至本地服務(wù)容器；本地服務(wù)容器利用本地服務(wù)容器中包含的業(yè)務(wù)服務(wù)對接收到的本地資源獲取請求進(jìn)行處理，得到相應(yīng)的本地資源數(shù)據(jù)，并將本地資源數(shù)據(jù)發(fā)送至HTML容器；HTML容器接收本地資源數(shù)據(jù)，并將本地資源數(shù)據(jù)發(fā)送至HTML程序；本方法中的HTML程序可直接使用HTML容器及本地服務(wù)容器進(jìn)行本地資源獲取，可確保HTML程序擺脫HTTP服務(wù)的束縛，以使HTML能夠更好地在本地程序中進(jìn)行應(yīng)用；本發(fā)明還提供數(shù)據(jù)交互系統(tǒng)、電子設(shè)備及存儲介質(zhì)，具有上述有益效果。

本文源自金融界

覽器解析HTML文件的過程是網(wǎng)頁呈現(xiàn)的關(guān)鍵步驟之一。具體介紹如下：

HTML文檔的接收和預(yù)處理

1. 網(wǎng)絡(luò)請求處理：當(dāng)用戶輸入URL或點(diǎn)擊鏈接時，瀏覽器發(fā)起HTTP請求，服務(wù)器響應(yīng)并返回HTML文件。此過程中，瀏覽器需要處理DNS查詢、建立TCP連接等底層網(wǎng)絡(luò)通信操作。
2. 預(yù)解析優(yōu)化：為了提高性能，現(xiàn)代瀏覽器在主線程解析HTML之前會啟動一個預(yù)解析線程，提前下載HTML中鏈接的外部CSS和JS文件。這一步驟確保了后續(xù)渲染過程的順暢進(jìn)行。

解析為DOM樹

3. 詞法分析和句法分析：瀏覽器的HTML解析器通過詞法分析將HTML文本標(biāo)記轉(zhuǎn)化為符號序列，然后通過句法分析器按照HTML規(guī)范構(gòu)建出DOM樹。每個節(jié)點(diǎn)代表一個HTML元素，形成了多層次的樹狀結(jié)構(gòu)。
4. 生成對象接口：生成的DOM樹是頁面元素的結(jié)構(gòu)化表示，提供了操作頁面元素的接口，如JavaScript可以通過DOM API來動態(tài)修改頁面內(nèi)容和結(jié)構(gòu)。

CSS解析與CSSOM樹構(gòu)建

5. CSS文件加載與解析：瀏覽器解析HTML文件中的<link>標(biāo)簽引入的外部CSS文件和<style>標(biāo)簽中的內(nèi)聯(lián)CSS，生成CSSOM樹。CSSOM樹反映了CSS樣式的層級和繼承關(guān)系。
6. CSS屬性計算：包括層疊、繼承等，確保每個元素對應(yīng)的樣式能夠被準(zhǔn)確計算。這些計算過程為后續(xù)的布局提供必要的樣式信息。

JavaScript加載與執(zhí)行

7. 阻塞式加載：當(dāng)解析器遇到<script>標(biāo)簽時，它會停止HTML的解析，轉(zhuǎn)而先加載并執(zhí)行JavaScript代碼。這是因?yàn)镴S可能會修改DOM結(jié)構(gòu)或CSSOM樹，從而影響已解析的部分。
8. 異步和延遲加載：為了不影響頁面的初步渲染，可以采用async或defer屬性來異步加載JS文件，這樣可以在后臺進(jìn)行JS的加載和執(zhí)行，而不阻塞HTML解析。

渲染樹的構(gòu)建

9. 合并DOM樹和CSSOM樹：有了DOM樹和CSSOM樹后，瀏覽器將它們組合成渲染樹，這個樹只包含顯示界面所需的DOM節(jié)點(diǎn)及對應(yīng)的樣式信息。
10. 不可見元素的排除：渲染樹會忽略例如<head>、<meta>等不可見元素，只關(guān)注<body>內(nèi)的可視化內(nèi)容。

布局計算（Layout）

11. 元素位置和尺寸確定：瀏覽器從渲染樹根節(jié)點(diǎn)開始，遞歸地計算每個節(jié)點(diǎn)的精確位置和尺寸，這個過程也被稱為“回流”或“重排”，是后續(xù)繪制的基礎(chǔ)。
12. 布局過程的優(yōu)化：現(xiàn)代瀏覽器會盡量優(yōu)化布局過程，例如通過流式布局的方式減少重復(fù)計算，確保高效地完成布局任務(wù)。

繪制（Paint）

13. 像素級繪制：繪制是一個將布局計算后的各元素繪制成像素點(diǎn)的過程。這包括文本、顏色、邊框、陰影以及替換元素的繪制。
14. 層次化的繪制：為了高效地更新局部內(nèi)容，瀏覽器會將頁面分成若干層次（Layer），對每一層分別進(jìn)行繪制，這樣只需更新變化的部分。

因此，我們開發(fā)中要注意以下幾點(diǎn)：

• 避免過度使用全局腳本：盡量減少使用全局腳本或者將它們放在文檔底部，以減少對HTML解析的阻塞。
• 合理組織CSS和使用CSS預(yù)處理器：合理組織CSS文件的結(jié)構(gòu)和覆蓋規(guī)則，利用CSS預(yù)處理器進(jìn)行模塊化管理。
• 利用瀏覽器緩存機(jī)制：通過設(shè)置合理的緩存策略，減少重復(fù)加載相同資源，提升二次訪問的體驗(yàn)。
• 優(yōu)化圖片和多媒體資源：適當(dāng)壓縮圖片和優(yōu)化多媒體資源的加載，減少網(wǎng)絡(luò)傳輸時間和渲染負(fù)擔(dān)。

綜上所述，瀏覽器解析HTML文件是一個復(fù)雜而高度優(yōu)化的過程，涉及從網(wǎng)絡(luò)獲取HTML文檔到最終將其渲染到屏幕上的多個步驟。開發(fā)者需要深入理解這些步驟，以優(yōu)化網(wǎng)頁性能和用戶體驗(yàn)。通過合理組織HTML結(jié)構(gòu)、優(yōu)化資源加載順序、減少不必要的DOM操作和合理安排CSS和JavaScript的加載與執(zhí)行，可以顯著提升頁面加載速度和運(yùn)行效率。