前陣子討論到 Chrome 88+ 加入的 Intensive Throttling 會造成 setInterval 大走鐘,同事提到可用 Worker 避開問題,發文後讀者 Scott 也留言提到。不過,在這個議題上,我覺得搬進 Worker 規避 Chrome 節能設計雖然省事但非最佳解,若有其他更有效率的替代方案,改用更省 CPU 省電的寫法是上策。

但這倒提醒我,自己從沒用過 Web Worker,不清楚其優勢及應用時機,趁此機會補上吧。

Web Worker 已經推出多年,不是什麼新技術,連 IE10 都支援即可見一斑,網路上教學與討論不少,我主要參考阮一峰老師的這篇 - Web Worker 使用教程,寫得很淺白完整,這篇文章會跳過 Web Worker 基本教學,直接來看 Web Worker 的優點及應用場合。

首先,要先確立一個觀念,網頁裡的 JavaScript 一直是用同一條執行緒執行,即便 setTimeout/setInterval 設定完就能跑其他程式,時間到會自動執行指定的函式,給人多執行緒並行的錯覺。事實上,setTimeout/setInterval 執行時會中斷原本執行中的 JavaScript 指令,等其結束後再繼續 setTimeout/setInterval 跟網頁事件與其他 setTimeout/setInterval JavaScript 會排隊執行,因此若 setTimeout/setInterval 跑很久,其他 JavaScript 指令必須等待其結束才能執行,因此便可能出現網頁久無回應被卡住的感覺。Web Worker 的好處即在於它在獨立的背景執行緒執行,不會跟網頁裡的 JavaScript 搶 CPU,這便是我想藉由實驗驗證的點。

要突顯 Web Worker 多執行緒的優勢,要找個網頁 JavaScript 很忙的範例,我找到很吃 CPU 的粒子移動模擬 JavaScript Canvas 效能測試

至於同時要跑的重量級運算,我很沒創意地選擇計算 0 ~ n 包含的質數,第一個版本用 setTimeout 來做:

<!DOCTYPE html>
<html>

<head>
	<title>Benchmark - setTimeout</title>
	<script src="excanvas.compiled.js"></script>
	<script src="animation.js"></script>
	<style>
		#info {
			position: absolute;
			z-index: 99;
			color:yellow;
			font-size: 14pt;
			top: 10px;
			left: 10px;
			padding: 6px;
			background-color: gray;
		}
	</style>
</head>

<body>
	<div id='benchmark' style='width: 800px; height: 400px'></div>
	<div id=info>
	</div>
	<script>
		let info = document.getElementById('info');
		function isPrime(num) {
			if (num <= 3) return num > 1;
			if ((num % 2 === 0) || (num % 3 === 0)) return false;
			let count = 5;
			while (Math.pow(count, 2) <= num) {
				if (num % count === 0 || num % (count + 2) === 0) return false;
				count += 6;
			}
			return true;
		}
		function listPrimes(maxNum) {
			let res = [];
			for (let i = 1; i <= maxNum; i++) {
				if (isPrime(i)) res.push(i);
			}
			return res;
		}
		var st = new Date().getTime();
		setTimeout(function () {
			let res = listPrimes(10000000);
			dura = (new Date().getTime() - st);
			document.getElementById('info').innerText += dura + 'ms ' + res.length + ' primes';
		}, 1000);
	</script>
</body>

</html>

計算質數部分我刻意延遲一秒開始,用意讓粒子動晝先播放一陣子,一秒後透過 setTimeout 執行尋找 1 ~ 1000 萬所含質數,如包含一秒延遲,共耗時 3.3s。

接著來改寫 Web Worker 版,寫一支 worker.js:

function isPrime(num) {
    if (num <= 3) return num > 1;
    if ((num % 2 === 0) || (num % 3 === 0)) return false;
    let count = 5;
    while (Math.pow(count, 2) <= num) {
        if (num % count === 0 || num % (count + 2) === 0) return false;
        count += 6;
    }
    return true;
}
function listPrimes(maxNum) {
    let res = [];
    for (let i = 1; i <= maxNum; i++) {
        if (isPrime(i)) res.push(i);
    }
    return res;
}
self.addEventListener('message', function (e) {
    var res = listPrimes(e.data);
    console.log('done');
    self.postMessage(res);   
    self.close(); 
}, false);

網頁程式部分一樣先跑動晝,setTimeout 延遲一秒啟動 Worker 尋找 1 ~ 1000 萬所含質數:

<!DOCTYPE html>
<html>

<head>
	<title>Benchmark - Worker</title>
	<script src="excanvas.compiled.js"></script>
	<script src="animation.js"></script>
	<style>
		#info {
			position: absolute;
			z-index: 99;
			color:yellow;
			font-size: 14pt;
			top: 10px;
			left: 10px;
			padding: 6px;
			background-color: gray;
		}
	</style>
</head>

<body>
	<div class="snowflakes">
	</div>
	<div id=info>
	</div>
	<script>
		var worker = new Worker('worker.js');
		worker.onmessage = function(e) {
			let dura = (new Date().getTime() - st);
			document.getElementById('info').innerText = dura + 'ms ' + e.data.length + ' primes';
			console.log(new Date());
		}
		var st = new Date().getTime();
		setTimeout(() => {
			worker.postMessage(10000000);			
		}, 1000);
	</script>
</body>

</html>

Web Wroker 版,包含 1 秒延遲啟動耗時約 3.5s,咦?怎麼比 setTimout 還慢?建立 Worker 物件及 postMessage 溝通會耗用一些額外資源,但用 Worker 不就為了效能,反而更慢像話嗎?

其實上面我賣了個關子,如果實際看過兩者的執行結果,大家就會知道為什麼該用 Web Worker 了。

左邊的 setTimeout 版本,質數計算期間動晝完全凍結,算完才繼續,且因執行間隔錯亂,粒子原本應隨機亂跑,一度出現整群同步移動。而 Web Wroker 版,全程動畫順暢未受干擾,證明質數計算是用另一個執行緒在跑,不中斷網頁的 JavaScript 執行,真正實踐了多執行緒。

最後再補充另一個實驗,瀏覽器本身是多執行緒環境,受單一執行緒限制的是網頁的 JavaScript 程式,其他如 Render、CSS 等運算等作業,瀏覽器會安排不同執行緒處理。因此,如果今天是用純 CSS 製作的動晝(我找到一個雪花飄效果當範例),用 setTimeout 或 Web Worker 的差異不大。(註:測量結果未包含一秒延遲,故比之前少一秒)

從以上實驗,我的結論是 - 對於等待外部回應或短短幾行的簡單作業,用 Web Worker 有點殺雞用牛刀,寫成 setTimeout/setInterval 就夠了,程式還比較簡潔;但如果是會持續數秒以上的重度運算,若不想在計算過程畫面卡死凍結,便可借重 Web Worker 發揮多執行緒威力,提供更好的使用者體驗。

想動手玩看看的同學,線上版本在這裡:

A example of when to use web worker to improve user experience.


Comments

# by 布丁布丁吃布丁

不錯的實驗

# by 阿尼

讚讚

# by Dennis

>> setTimeout/setInterval 執行時會中斷原本執行中的 JavaScript 指令,等其結束後再繼續。 Wrong

# by Karcher

web worker讓js不在受限於單執行緒 學習到了,謝謝

# by CY

>># 2021-10-05 06:39 PM by Dennis >>>> setTimeout/setInterval 執行時會中斷原本執行中的 JavaScript 指令,等其結束後再繼續。 >>Wrong 如同 Dennis 所抓出的這句,其實這樣講不太對,甚至應該是相反。 setTimeout/setInterval 只能保證 callback 不「早於」所預定的時間執行,但會晚於預期的時間, 所以如果有原本執行中的 「同步」型 JavaScript 指令,會等到全部執行完, 才會輪到 event loop 裡的其他 callback 執行,如已到期的 Timer 、async 操作有結果要被傳入執行的 callback、事件發生要被 trigger 的 listener 等等。

# by Jeffrey

to Dennis, CY,謝謝指正。 我原先把網頁的事件、其他 setInterval/setTimeout 想像成一整包不再細分的程式,進而衍生原本該跑的程式被它卡住延後執行,原想藉此忽略細節較易理解,但同意兩位的觀點,此一說法讓讀者對 JavaScript Event Loop 機制產生誤解,已修改原文。

Post a comment


42 + 0 =