我們知道,使用者鍵盤輸入的事件有3個:keydown、keypress、keyup。可這三位各有各的缺點,沒一個讓人省心的。
keypress,無法拿到使用者最新的輸入值,在輸入中文時還不觸發。keyup,能拿到最新輸入值了,但已經無法透過 preventDefault() 阻止輸入。
比如這個場景:把使用者輸入的小寫字母即時的轉換成大寫。
我們分別在keypress和keyup的監聽函式里執行:this.value = this.value.toUpperCase(),得到的畫面是這樣的:
keypress: keyup:
可以看到,keypress無法轉換最後一個字母,keyup有一個從小寫跳到大寫的動畫,體驗並不好。
我終於在阮一峰老師的《Javascript教程》裡看到了完美的解決方案:
<input type="text" id="haha" />
<script>
document.getElementById('haha').onkeypress = function(e) {
setTimeout(() => {
this.value = this.value.toUpperCase();
}, 0);
};
</script>
好了,本文到此為止!(狗頭)
問題已經解決了,可如果我們就此打住,我們的收穫也僅僅是這個問題而已。我們必須弄明白:為什麼會這樣?
帶著這個疑問,我們把瀏覽器的事件迴圈好好捋一下:
一、程式和執行緒
現代瀏覽器都是多程式的,主要包括:1個瀏覽器程式、1個網路程式、1個GPU程式、多個渲染程式、多個外掛程式。
其中,每個頁面標籤各自一個渲染程式(有時幾個標籤會共享一個渲染程式,詳情請看李兵老師的《瀏覽器工作原理與實踐》)。
每個渲染程式裡,會有多個執行緒。我們說JS是單執行緒的,其實是說一個渲染程式裡只有一個主執行緒。
一個渲染程式,主要有以下幾個執行緒:
(1)主執行緒:執行 JavaScript 程式碼、計算 CSS 樣式、構建和更新 DOM 樹、處理使用者互動等。
(2)渲染執行緒:負責將構建好的幀繪製到螢幕上。
(3)合成執行緒:負責頁面的滾動和動畫等操作,可以在不需要主執行緒參與的情況下獨立完成部分工作,以提高效能。
(4)GPU 執行緒:處理 GPU 任務,例如 WebGL 或者 CSS 3D 變換等。
(5)I/O 執行緒:處理磁碟和網路 I/O。
(6)工作執行緒(Worker Thread):執行 Web Worker 或 Service Worker 的程式碼。
(7)定時器執行緒:setTimeout、setInterval的計時在這上面進行。
這裡面最重要的是主執行緒和I/O執行緒,渲染程式與瀏覽器其他程式的互動,都是透過I/O執行緒來完成的。比如網路請求、頁面點選,就分別是瀏覽器程式、網路程式,透過I/O執行緒來通知主執行緒的。
二、什麼是事件迴圈?
只有一個主執行緒,同步任務沒問題,一行行往下執行就是了。那非同步任務呢?網路請求、定時器都那麼耗時,如果都放在主執行緒執行,後果不堪設想。瀏覽器是透過什麼方式,在只有一個主執行緒的情況下,讓頁面可以流暢執行的呢?
答案就是:主執行緒執行同步任務,非同步任務則交給其他執行緒來執行。比如:網路請求由IO執行緒負責,setTimeout的計時由定時器執行緒負責等。
同步任務、非同步任務都安排好了,但是,非同步任務一般都會有回撥函式,也就是非同步任務執行結束後的回撥。它們呢,瀏覽器如何對待?
非同步任務的回撥,還有事件監聽函式、Promise的then等,它們則是放入到一個叫“訊息佇列”的東東里。瀏覽器執行完同步任務後,就開始從訊息佇列裡取任務,執行完一個再取下一個。比如setTimeout在計時結束後,回撥函式就進入訊息佇列排隊,等待被取出執行。Ajax請求也是一樣,請求返回後,回撥函式就進入訊息佇列排隊,等待被取出執行。訊息佇列是一個佇列結構,先進先出。如果訊息佇列是空的,事件迴圈就進入等待狀態,直到新的任務被放入訊息佇列裡。
總結就是:主執行緒執行同步任務,其他執行緒執行非同步任務,非同步任務的回撥則進入訊息佇列排隊待命。
這個過程是迴圈進行的,你可以簡單理解為是一個無限的for迴圈,這就是瀏覽器的事件迴圈。
三、宏任務佇列和微任務佇列
事件迴圈的關鍵,就是這個“訊息佇列”。
其實訊息佇列是我們的習慣叫法,它還被叫做任務佇列或者事件佇列。具體來說,一個渲染程式有兩個訊息佇列:一個宏任務佇列和一個微任務佇列。我們平時說的訊息佇列,其實是指宏任務佇列。
哪些任務屬於宏任務?
(1)整體的 script 程式碼(也就是一開始的全域性程式碼)
(2)`setTimeout` 和 `setInterval` 的回撥
(3)`setImmediate` 的回撥(Node.js 環境)
(4)I/O 操作(如網路請求、檔案讀寫等,主要在 Node.js 環境)
(5)使用者互動事件(如 click、keydown 等)
(6)UI 渲染更新
(7)postMessage、MessageChannel
(8)WebWorker 的 message 事件
哪些任務屬於微任務?
(1)`Promise` 的 `then` 和 `catch` 的回撥
(2)`process.nextTick` 的回撥(Node.js 環境)
(3)`MutationObserver` 的回撥
(4)`queueMicrotask` 方法的回撥
(5)`async/await`(實際上是透過 `Promise` 實現的)
為什麼要有微任務佇列呢?
你可以理解為,都是回撥,但是有一些的優先順序要比其他的更高,所以被單獨放入了一個佇列裡,並把這些任務定義為微任務。
它們的執行順序是這樣的:主執行緒的同步程式碼執行完後,就去檢查微任務佇列,先把微任佇列裡的任務都清空,之後,再從宏任務佇列裡取出一個宏任務,開始下一輪事件迴圈。
注意,我們要區分“同步任務”和“宏任務”的概念。雖然主執行緒只執行同步程式碼,並且宏任務被取出後回到主執行緒執行。但並不是說宏任務都是同步程式碼,這是倆不同的概念。不管宏任務還是微任務,本質都是一個回撥函式,裡面既可以寫同步程式碼,也可以寫非同步程式碼。當執行到它們裡面的非同步程式碼時,也是會交給其他執行緒執行,執行結束後把回撥放入宏任務佇列或微任務佇列的。
還有一點值得注意,那就是Promise物件或者async函式,裡面的程式碼是同步執行的,在開發中我們也有這個體驗。那為什麼總感覺Promise是非同步的呢?那是因為我們一般都會在Promise裡寫網路請求,網路請求是非同步的。由網路程式完成請求後,透過I/O執行緒,把回撥函式放入到宏任務佇列裡。如果Promise裡沒有非同步任務的話,它就完全是同步的。但是它們的回撥,也就是then或者catch函式,卻是被放入到微任務佇列裡,等待同步程式碼都執行完後再執行。
其實,宏任務佇列也有好幾種,比如:使用者互動佇列、定時器佇列、網路事件佇列。因為即便都是宏任務,也有不同的優先順序。比如使用者互動佇列的宏任務,優先順序就比定時器佇列要高,因為使用者體驗是要首先保證的。但我們一般無需深入到這個程度,簡單的理解為只有一個宏任務佇列,也沒什麼問題。
四、一個完整的事件迴圈是什麼樣的?
(1)主執行緒先執行同步程式碼,包括一開始的全域性程式碼,或者後面從宏任務佇列取出的宏任務。
(2)同步程式碼執行完後,檢查微任務佇列,把微任務佇列清空。
(3)嘗試重新渲染頁面。
瀏覽器會在每一輪事件迴圈結束的時候,嘗試重新渲染頁面。如果頁面沒有變化,什麼都不做。反之,也不一定立刻重新渲染,瀏覽器為了提高渲染效率,可能會把幾次渲染合併進行。另外,瀏覽器的渲染,考慮因素還有更多,比如顯示器的重新整理率等。
(4)從宏任務佇列取出下一個宏任務,進入下一輪事件迴圈。
當宏任務佇列和微任務佇列都為空時,瀏覽器可能會進入一個“空閒”狀態,等待新的任務被新增到佇列中。這個狀態通常被稱為“事件迴圈的空閒階段”。
五、再解釋這個案例
好了,現在是時候解釋為什麼 setTimeout(fn,0) 這麼神奇了!
瀏覽器的事件監聽函式,和setTimeout的回撥函式,都是被放入宏任務佇列裡的,瀏覽器把它們取出來放到主執行緒執行,就是開始一個事件迴圈。
1、為什麼能拿到最新的輸入結果?
前文說到,瀏覽器在每個事件迴圈結束的時候,會嘗試重新渲染頁面,這個過程就包括更新DOM。setTimeout把回撥函式放入宏任務佇列,也就會在最快下一個事件迴圈執行。此時JS訪問的,就是在上個事件迴圈結束後更新的DOM,因此就能拿到最新的輸入了。
2、為什麼輸入框直接顯示大寫,而不是像keyup那樣,先顯示小寫然後跳成大寫?
這兒我認為有兩種可能:
(1)keypress事件的回撥,和setTimeout的回撥,是相鄰的兩個事件迴圈,瀏覽器把它倆結束後的渲染合併了,先變成大寫,然後更新DOM,渲染到頁面中。
(2)keypress事件回撥這一輪事件迴圈結束後,其實是渲染了,但是接著進行setTimeout回撥的這一輪事件迴圈,馬上把小寫變成了大寫。肉眼根本反應不過來,看上去就是直接顯示的大寫。
至於哪一種是對的,我無法確定,有大佬能指點一下嗎?
本人水平非常有限,寫作主要是為了把自己學過的東西捋清楚。如有錯誤,還請指正,感激不盡。