前言
本文是筆者對(duì)Mario Kosaka寫(xiě)的inside look at modern web browser系列文章的翻譯。這里的翻譯不是指直譯，而是結(jié)合個(gè)人的理解將作者想表達(dá)的意思表達(dá)出來(lái)，而且會(huì)盡量補(bǔ)充一些相關(guān)的內(nèi)容來(lái)幫助大家更好地理解相速。
到達(dá)合成線程的輸入
這篇文章是探究Chrome內(nèi)部工作原理的四集系列文章中的最后一篇了伸眶。在上一篇文章中，我們探討了一下瀏覽器渲染頁(yè)面的過(guò)程以及學(xué)習(xí)了一些關(guān)于合成線程的知識(shí)
滤奈，在本篇文章中，我們要看一下當(dāng)用戶(hù)在網(wǎng)頁(yè)上輸入內(nèi)容的時(shí)候蠢甲，合成線程（compositor）做了些什么來(lái)保證流暢的用戶(hù)體驗(yàn)的僵刮。
從瀏覽器的角度來(lái)看輸入事件
當(dāng)你聽(tīng)到“輸入事件”（input events）的時(shí)候据忘，你可能只會(huì)想到用戶(hù)在文本框中輸入內(nèi)容或者對(duì)頁(yè)面進(jìn)行了點(diǎn)擊操作，可是從瀏覽器的角度來(lái)看的話搞糕，輸入其實(shí)代表著來(lái)自于用戶(hù)的任何手勢(shì)動(dòng)作（gesture）勇吊。所以用戶(hù)滾動(dòng)頁(yè)面，觸碰屏幕以及移動(dòng)鼠標(biāo)等操作都可以看作來(lái)自于用戶(hù)的輸入事件窍仰。
當(dāng)用戶(hù)做了一些諸如觸碰屏幕的手勢(shì)動(dòng)作時(shí)汉规，瀏覽器進(jìn)程（browser process）是第一個(gè)可以接收到這個(gè)事件的地方【运保可是瀏覽器進(jìn)程只能知道用戶(hù)的手勢(shì)動(dòng)作發(fā)生在什么地方而不知道如何處理针史，這是因?yàn)闃?biāo)簽內(nèi)（tab）的內(nèi)容是由頁(yè)面的渲染進(jìn)程（render process）負(fù)責(zé)的。因此瀏覽器進(jìn)程會(huì)將事件的類(lèi)型（如touchstart）以及坐標(biāo)（coordinates）發(fā)送給渲染進(jìn)程碟狞。為了可以正確地處理這個(gè)事件啄枕，渲染進(jìn)程會(huì)找到事件的目標(biāo)對(duì)象（target）然后運(yùn)行這個(gè)事件綁定的監(jiān)聽(tīng)函數(shù)（listener）。
<p align="center">點(diǎn)擊事件從瀏覽器進(jìn)程路由到渲染進(jìn)程</p>
合成線程接收到輸入事件
在上一篇文章中族沃，我們查看了合成線程是如何通過(guò)合并頁(yè)面已經(jīng)光柵化好的層來(lái)保障流暢滾動(dòng)體驗(yàn)（scroll smoothly）的频祝。如果當(dāng)前頁(yè)面不存在任何用戶(hù)事件的監(jiān)聽(tīng)器（event listener），合成線程完全不需要主線程的參與就能創(chuàng)建一個(gè)新的合成幀來(lái)響應(yīng)事件脆淹〕？眨可是如果頁(yè)面有一些事件監(jiān)聽(tīng)器（event listeners）呢？合成線程是如何判斷出這個(gè)事件是否需要路由給主線程處理的呢盖溺？
了解非快速滾動(dòng)區(qū)域 - non-fast scrollable region
因?yàn)轫?yè)面的JavaScript腳本是在主線程（main thread）中運(yùn)行的漓糙，所以當(dāng)一個(gè)頁(yè)面被合成的時(shí)候，合成線程會(huì)將頁(yè)面那些注冊(cè)了事件監(jiān)聽(tīng)器的區(qū)域標(biāo)記為“非快速滾動(dòng)區(qū)域”（Non-fast Scrollable Region）烘嘱。由于知道了這些信息昆禽，當(dāng)用戶(hù)事件發(fā)生在這些區(qū)域時(shí)，合成線程會(huì)將輸入事件發(fā)送給主線程來(lái)處理拙友。如果輸入事件不是發(fā)生在非快速滾動(dòng)區(qū)域为狸，合成線程就無(wú)須主線程的參與來(lái)合成一個(gè)新的幀。
<p align="center">非快速滾動(dòng)區(qū)域有用戶(hù)事件發(fā)生時(shí)的示意圖</p>
當(dāng)你寫(xiě)事件監(jiān)聽(tīng)器的時(shí)候留點(diǎn)心眼
Web開(kāi)發(fā)的一個(gè)常見(jiàn)的模式是事件委托（event delegation）遗契。由于事件會(huì)冒泡辐棒，你可以給頂層的元素綁定一個(gè)事件監(jiān)聽(tīng)函數(shù)來(lái)作為其所有子元素的事件委托者，這樣子節(jié)點(diǎn)的事件就可以統(tǒng)一被頂層的元素處理了牍蜂。因此你可能看過(guò)或者寫(xiě)過(guò)類(lèi)似于下面的代碼：
document.body.addEventListener('touchstart', event => {
if (event.target === area) {
event.preventDefault()
}
})
只用一個(gè)事件監(jiān)聽(tīng)器就可以服務(wù)到所有的元素漾根，乍一看這種寫(xiě)法還是挺實(shí)惠的■昃海可是辐怕，如果你從瀏覽器的角度去看一下這段代碼，你會(huì)發(fā)現(xiàn)上面給body元素綁定了事件監(jiān)聽(tīng)器后其實(shí)是將整個(gè)頁(yè)面都標(biāo)記為一個(gè)非快速滾動(dòng)區(qū)域从绘，這就意味著即使你頁(yè)面的某些區(qū)域壓根就不在乎是不是有用戶(hù)輸入寄疏，當(dāng)用戶(hù)輸入事件發(fā)生時(shí)是牢，合成線程每次都會(huì)告知主線程并且會(huì)等待主線程處理完它才干活。因此這種情況下合成線程就喪失提供流暢用戶(hù)體驗(yàn)的能力了（smooth scrolling ability）陕截。
<p align="center">當(dāng)整個(gè)頁(yè)面都是非快速滾動(dòng)區(qū)域時(shí)頁(yè)面的事件處理示意圖</p>
為了減輕這種情況的發(fā)生驳棱，您可以為事件監(jiān)聽(tīng)器傳遞passive：true選項(xiàng)。 這個(gè)選項(xiàng)會(huì)告訴瀏覽器您仍要在主線程中偵聽(tīng)事件农曲，可是合成線程也可以繼續(xù)合成新的幀社搅。
document.body.addEventListener('touchstart', event => {
if (event.target === area) {
event.preventDefault()
}
}, {passive: true});
查找事件的目標(biāo)對(duì)象（event target）
當(dāng)合成線程向主線程發(fā)送輸入事件時(shí)，主線程要做的第一件事是通過(guò)命中測(cè)試（hit test）去找到事件的目標(biāo)對(duì)象（target）乳规。具體的命中測(cè)試流程是遍歷在渲染流水線中生成的繪畫(huà)記錄（paint records）來(lái)找到輸入事件出現(xiàn)的x, y坐標(biāo)上面描繪的對(duì)象是哪個(gè)形葬。
<p align="center">主線程通過(guò)遍歷繪畫(huà)記錄來(lái)確定在x，y坐標(biāo)上的是哪個(gè)對(duì)象</p>
最小化發(fā)送給主線程的事件數(shù)
上一篇文章中我們有說(shuō)過(guò)顯示器的刷新頻率通常是一秒鐘60次以及我們可以通過(guò)讓JavaScript代碼的執(zhí)行頻率和屏幕刷新頻率保持一致來(lái)實(shí)現(xiàn)頁(yè)面的平滑動(dòng)畫(huà)效果（smooth animation）暮的。對(duì)于用戶(hù)輸入來(lái)說(shuō)笙以，觸摸屏一般一秒鐘會(huì)觸發(fā)60到120次點(diǎn)擊事件，而鼠標(biāo)一般則會(huì)每秒觸發(fā)100次事件青扔，因此輸入事件的觸發(fā)頻率其實(shí)遠(yuǎn)遠(yuǎn)高于我們屏幕的刷新頻率源织。
如果每秒將諸如touchmove這種連續(xù)被觸發(fā)的事件發(fā)送到主線程120次翩伪，因?yàn)槠聊坏乃⑿滤俣认鄬?duì)來(lái)說(shuō)比較慢微猖，它可能會(huì)觸發(fā)過(guò)量的點(diǎn)擊測(cè)試以及JavaScript代碼的執(zhí)行。
<p align="center">事件淹沒(méi)了屏幕刷新的時(shí)間軸缘屹，導(dǎo)致頁(yè)面很卡頓</p>
為了最大程度地減少對(duì)主線程的過(guò)多調(diào)用凛剥，Chrome會(huì)合并連續(xù)事件（例如wheel轻姿，mousewheel犁珠，mousemove，pointermove互亮，touchmove）犁享，并將調(diào)度延遲到下一個(gè)requestAnimationFrame之前。
<p align="center">和之前相同的事件軸豹休，可是這次事件被合并并延遲調(diào)度了</p>
任何諸如keydown炊昆，keyup，mouseup威根，mousedown凤巨，touchstart和touchend等相對(duì)不怎么頻繁發(fā)生的事件都會(huì)被立即派送給主線程。
使用getCoalesecedEvents來(lái)獲取幀內(nèi)（intra-frame）事件
對(duì)于大多數(shù)web應(yīng)用來(lái)說(shuō)洛搀，合并事件應(yīng)該已經(jīng)足夠用來(lái)提供很好的用戶(hù)體驗(yàn)了敢茁，然而，如果你正在構(gòu)建的是一個(gè)根據(jù)用戶(hù)的touchmove坐標(biāo)來(lái)進(jìn)行繪圖的應(yīng)用的話留美，合并事件可能會(huì)使頁(yè)面畫(huà)的線不夠順暢和連續(xù)彰檬。在這種情況下伸刃，你可以使用鼠標(biāo)事件的getCoalescedEvents來(lái)獲取被合成的事件的詳細(xì)信息。
<p align="center">左邊是順暢的觸摸手勢(shì)逢倍，右邊是事件合成后不那么連續(xù)的手勢(shì)</p>
window.addEventListener('pointermove', event => {
const events = event.getCoalescedEvents();
for (let event of events) {
const x = event.pageX;
const y = event.pageY;
// draw a line using x and y coordinates.
}
});
下一步
這本系列的文章中奕枝，我們以Chrome瀏覽器為例子探討了瀏覽器的內(nèi)部工作原理。如果你之前從來(lái)沒(méi)有想過(guò)為什么DevTools推薦你在事件監(jiān)聽(tīng)器中使用passive:true選項(xiàng)或者在script標(biāo)簽中寫(xiě)async屬性的話瓶堕，我希望這個(gè)系列的文章可以給你一些關(guān)于瀏覽器為什么需要這些信息來(lái)提供更快更流暢的用戶(hù)體驗(yàn)的原因隘道。
學(xué)習(xí)如何衡量性能
不同網(wǎng)站的性能調(diào)整可能會(huì)有所不同，你要自己衡量自己網(wǎng)站的性能并確定最適合提升你的網(wǎng)站性能的方案郎笆。 你可以查看Chrome DevTools團(tuán)隊(duì)的一些教程來(lái)學(xué)習(xí)如何才能衡量自己網(wǎng)站的性能谭梗。
為你的站點(diǎn)添加Feature Policy
如果你想更進(jìn)一步，你可以了解一下Feature Policy這個(gè)新的Web平臺(tái)功能宛蚓，這個(gè)功能可以在你構(gòu)建項(xiàng)目的時(shí)候提供一些保護(hù)讓您的應(yīng)用程序具有某些行為并防止你犯下錯(cuò)誤激捏。例如，如果你想確保你的應(yīng)用代碼不會(huì)阻塞頁(yè)面的解析（parsing）凄吏，你可以在同步腳本策略（synchronius scripts policy）中運(yùn)行你的應(yīng)用远舅。具體做法是將sync-script設(shè)置為'none'，這樣那些會(huì)阻塞頁(yè)面解析的JavaScript代碼會(huì)被禁止執(zhí)行痕钢。這樣做的好處是避免你的代碼阻塞頁(yè)面的解析图柏，而且瀏覽器無(wú)須擔(dān)心解析器（parser）暫停。
總結(jié)
以上就是所有和瀏覽器架構(gòu)和運(yùn)行原理相關(guān)的內(nèi)容了任连，我們以后在開(kāi)發(fā)web應(yīng)用的時(shí)候蚤吹，不應(yīng)該只考慮代碼的優(yōu)雅性，還要多多從瀏覽器是如何解析運(yùn)行我們的代碼的方面進(jìn)行思考随抠，從而為用戶(hù)提供更好的用戶(hù)體驗(yàn)裁着。
持續(xù)關(guān)注我的技術(shù)動(dòng)態(tài)
我是進(jìn)擊的大蔥，關(guān)注我和我一起進(jìn)步成獨(dú)當(dāng)一面的全棧工程師拱她！
文章首發(fā)于：窺探現(xiàn)代瀏覽器架構(gòu)(四)
關(guān)注我的個(gè)人公眾號(hào)獲取我的最新技術(shù)推送二驰！
[圖片上傳失敗...(image-104d3d-1578641898409)]
