大家好，我卡頌。

前端工程師多年來習(xí)慣了在瀏覽器環(huán)境進(jìn)行單線程開發(fā)。

隨著瀏覽器對(duì)web worker的廣泛支持、前端項(xiàng)目復(fù)雜度逐漸提高，「利用worker線程緩解主線程計(jì)算壓力」逐漸成為一種可行方案。

比如，React就曾嘗試將運(yùn)行時(shí)的diff算法放在worker線程執(zhí)行。

然而，社區(qū)眾多的第三方庫(kù)都或多或少操作DOM，worker線程無(wú)法操作DOM的限制(也可以說是特性)使得其應(yīng)用領(lǐng)域被大大限制。

partytown是一個(gè)大小僅6kb的庫(kù)，他的作用是讓worker線程擁有包括「操作DOM」在內(nèi)的多項(xiàng)能力。

一旦潘多拉的盒子被打開，這會(huì)成為前端多線程編程的起點(diǎn)么?

第三方庫(kù)的壞處

我們經(jīng)常在Github上搜索第三方庫(kù)，這些開源庫(kù)極大提高了我們的開發(fā)效率。然而第三方庫(kù)有很多潛在隱患：

• 第三方庫(kù)可能執(zhí)行不為人知的操作(比如向未知服務(wù)器發(fā)送請(qǐng)求)
• 可能占用主線程過多算力
• 可能使用一些有害的API(比如document.write)

究其原因，對(duì)于前端應(yīng)用，不管是通過 

對(duì)于主線程的API，例如：window、document、localStorage，partytown通過proxy劫持并轉(zhuǎn)發(fā)對(duì)他們的調(diào)用。

比如，如下代碼：

 
 
 
 

  
  
  
  
var w = document.body.clientWidth; 
 
 
 
 

涉及到3個(gè)getter：

1. get document
2. get body
3. get clientWidth

partytown會(huì)完成：

1. 劫持getter，將他們轉(zhuǎn)發(fā)到主線程
2. 獲取數(shù)據(jù)后返回
3. 步驟1和2之間數(shù)據(jù)的序列化、反序列化

由于代理了主線程API，可以實(shí)現(xiàn)沙箱功能，比如：

• 限制對(duì)document.cookie訪問
• 返回定制的navigator.userAgent
• 禁止第三方庫(kù)訪問localStorage
• 重置危險(xiǎn)方法(如document.write)
• 阻止腳步訪問其他腳本

對(duì)于網(wǎng)絡(luò)請(qǐng)求，web worker會(huì)發(fā)送同步的XHR請(qǐng)求，經(jīng)由Service Worker攔截后與主線程異步通信。

數(shù)據(jù)返回后，Service Worker會(huì)響應(yīng)web worker的請(qǐng)求。

所以，從worker線程角度看，一切調(diào)用都是同步的。這使得大部分原生API在worker線程與主線程中表現(xiàn)一致。

這意味著理論上任何第三方庫(kù)都可以經(jīng)由partytown遷移到worker線程執(zhí)行。

總結(jié)

當(dāng)然，凡事都有取舍，對(duì)于partytown來說：

• worker線程的DOM操作都是阻塞的，不如主線程高效
• 經(jīng)由Service Worker攔截的請(qǐng)求在Network面板相比普通請(qǐng)求略有差異
• 類似event.preventDefault()和passive event listeners在worker線程無(wú)效

但是，這終究是一次有意義的嘗試。相信在不遠(yuǎn)的將來，會(huì)有越來越多前端應(yīng)用從「多線程」中收益。

新聞名稱：前端以后也要多線程編程了么？
鏈接分享：http://uogjgqi.cn/article/djpspoe.html