了不起的Chrome瀏覽器（6）：Chrome 94開(kāi)始WebGPU試用，Web的圖像渲染及機(jī)器學(xué)能力更強(qiáng)了

9月21日正式發(fā)布的Chrome 94，帶來(lái)了哪些有意思的新特性呢？

背景

十多年來(lái)，Web技術(shù)突飛猛進(jìn)，其中Chrome功不可沒(méi)，了解Chrome可以幫助我們理解前端行業(yè)的發(fā)展趨勢(shì)。

因此，我將以《了不起的Chrome瀏覽器》為題，對(duì)Chrome的每一個(gè)版本的重要特性進(jìn)行詳細(xì)解讀，同時(shí)分享一些自己的一些思考：

通過(guò)專(zhuān)注于Chrome的寫(xiě)作，既可以可以提高我的專(zhuān)業(yè)能力，也可以提高個(gè)人影響力。我的長(zhǎng)期目標(biāo)是在2025年出版一本關(guān)于Chrome的書(shū)，畢竟出版自己的書(shū)每一個(gè)寫(xiě)作者最高的追求。

我是寒雁，一個(gè)熱愛(ài)寫(xiě)代碼和寫(xiě)文章的程序員，歡迎關(guān)注我的微信公眾號(hào)寒雁Talk。

TL;TR

詳細(xì)解讀

WebGPU

Chrome 94新增了試用特性WebGPU，提供了使用GPU的Web API，可以用于圖像渲染（比如3D渲染）以及進(jìn)行數(shù)據(jù)并行計(jì)算（比如機(jī)器學(xué)習(xí)）。

WebGPU對(duì)于Web來(lái)說(shuō)無(wú)疑是一個(gè)革命性的特性，計(jì)算機(jī)行業(yè)本質(zhì)上是通過(guò)摩爾定律（摩爾為CPU廠商Intlel的創(chuàng)始人之一）以及黃氏定律（黃氏即黃仁勛，GPU廠商英偉達(dá)的創(chuàng)始人，別號(hào)核彈教父）所推動(dòng)的，芯片計(jì)算能力的提升為我們帶來(lái)歷次計(jì)算機(jī)行業(yè)革命：個(gè)人電腦、互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)、人工智能。當(dāng)GPU的計(jì)算能力越來(lái)越強(qiáng)，越來(lái)越重要時(shí)，Web卻不能很好得利用，這顯然是不合理的。

WebGPU這個(gè)特性所對(duì)應(yīng)的是WebGPU和WebGPU Shading Language這2個(gè)提案，由Google、Mozilla以及Apple的工程師負(fù)責(zé)。WebGPU和WebGPU Shading Language提案都是由W3C的GPU for the Web工作組起草的，該工作組成立于2017，經(jīng)過(guò)4年的努力，WebGPU終于開(kāi)始試用了，也是不容易??！WebGPU提案定義了Web中使用GPU的API，WebGPU Shading Language（WGSL）提案定義了GPU代碼的編程語(yǔ)言。WebGPU得到了4大瀏覽器巨頭（Safari，F(xiàn)irefox、Edge）的支持，因此WebGPU成為正式的W3C標(biāo)準(zhǔn)只是時(shí)間問(wèn)題。

WebGPU于Chrome 94開(kāi)始試用，預(yù)計(jì)將于Chrome 98正式發(fā)布，時(shí)間大概是明年2月份。如此重要的特性，可能大家還沒(méi)來(lái)得及學(xué)會(huì)怎么使用，只試用3個(gè)月時(shí)間就正式發(fā)布，似乎有點(diǎn)太倉(cāng)促了。

WebGPU是WebGL的繼承者，它們的目標(biāo)類(lèi)似，不過(guò)WebGPU提供了更加底層的GPU能力。因此，WebGPU的圖像渲染能力更強(qiáng)，性能更好，更易用，也更加適用于數(shù)據(jù)并行計(jì)算以及機(jī)器學(xué)習(xí)。

根據(jù)Safari的測(cè)試結(jié)果，WebGPU的性能在各種設(shè)備上都遠(yuǎn)高于WebGL：


圖片來(lái)源：WebGPU and WSL in Safari

前端機(jī)器學(xué)習(xí)庫(kù)TensorFlow.js也測(cè)試了一下WebGPU，結(jié)果發(fā)現(xiàn)WebGPU的性能更好，但是差距與WebGL并不是特別明顯，有待進(jìn)一步研究：


圖片來(lái)源：Fast client-side ML with TensorFlow.js

如下圖，WebGPU是基于各種GPU API（例如DirectX 12、Metal、Vulkan）實(shí)現(xiàn)的。


圖片來(lái)源：Access modern GPU features with WebGPU

WebGPU提供的是底層API，非常強(qiáng)大，同時(shí)也非常復(fù)雜。使用WebGPU實(shí)現(xiàn)向量乘法的代碼長(zhǎng)達(dá)200行，目測(cè)社區(qū)將會(huì)出現(xiàn)第三方庫(kù)封裝WebGPU，提供更簡(jiǎn)單的使用方式用于不同的應(yīng)用場(chǎng)景。

根據(jù)測(cè)試，使用WebGPU進(jìn)行向量乘法計(jì)算時(shí)，隨著向量長(zhǎng)度增加，其性能遠(yuǎn)優(yōu)于使用CPU：


圖片來(lái)源：Get started with GPU Compute on the web

WebCodecs

Chrome 94正式發(fā)布了WebCodecs，使得我們可以直接使用Chrome所提供的圖像、音頻以及視頻的編碼/解碼能力。

WebCodecs為W3C提案，由Google、Mozilla以及Microsoft的工程師負(fù)責(zé)，于Chrome 86開(kāi)始試用。來(lái)自Firefox和Edge的工程師共同起草了WebCodecs提案，因此預(yù)計(jì)該提案將最終成為W3C標(biāo)準(zhǔn)。

Codec為coder和decoder合成詞，即編解碼器，它可以是硬件，也可以是軟件，用于編碼以及解碼特定的數(shù)據(jù)格式，比如MP3/AAC/VP9/H264等。

瀏覽器器支持各種格式的圖片、音頻以及視頻，但是之前我們并不能直接調(diào)用相應(yīng)的編解碼器。WebCodecs就是為了解決這個(gè)問(wèn)題，讓W(xué)eb開(kāi)發(fā)者可以直接使用各種編解碼器。

為了優(yōu)化性能同時(shí)保持一致性，Google Docs在今年5月份宣布將遷移至基于Canvas的渲染方案。不過(guò)，之前Google Docs在處理GIF時(shí)，仍然使用了HTML的<img>標(biāo)簽。后來(lái)，Google Docs使用了WebCodecs的圖片編解碼器ImageDecoder將GIF解碼，然后再使用Canvas渲染，這樣做優(yōu)化了性能，同時(shí)簡(jiǎn)化了代碼架構(gòu)。

Zoom在其Web Meeting SDK和Web Video SDK中使用了WebCodecs，由于源代碼并未開(kāi)源，因此具體怎么使用的不得而知，應(yīng)該是用到了視頻相關(guān)的編解碼器。值得一提的是，由于Chrome 93的對(duì)WebCodes的更新有Breaking changes，導(dǎo)致Zoom的Web Meeting SDK和Web Video SDK出現(xiàn)了BUG，看來(lái)在第三方SDK中直接使用并未正式發(fā)布的特性，還是有挺大風(fēng)險(xiǎn)的。

Scheduling APIs: Prioritized scheduler.postTask

Chrome 94正式發(fā)布了Scheduling APIs: Prioritized scheduler.postTask特性：

  • 新增了scheduler.postTask方法，支持根據(jù)優(yōu)先級(jí)調(diào)度任務(wù)，并支持指定延時(shí)調(diào)度任務(wù);
  • 定義了3個(gè)任務(wù)優(yōu)先級(jí)，從高到低依次為：user-blocking、user-visible、background;
  • 新增了TaskController，支持動(dòng)態(tài)修改任務(wù)優(yōu)先級(jí)以及取消任務(wù);

Prioritized Task Scheduling為WICG提案，由Google工程師負(fù)責(zé)，于Chrome 86開(kāi)始試用。由于該提案暫未得到其他瀏覽器廠商的參與和支持，因此該特性最大的風(fēng)險(xiǎn)在于能否成為通用標(biāo)準(zhǔn)。

當(dāng)我們用Lighthouse檢測(cè)頁(yè)面時(shí)，其中一個(gè)檢測(cè)項(xiàng)為"Minimize main-thread work"，它將主線程的工作分為了下圖所示的7個(gè)分類(lèi)，可知主線程所承擔(dān)的任務(wù)異常繁重：

由于主線程需要負(fù)責(zé)執(zhí)行的任務(wù)過(guò)多，如果主線程被低優(yōu)先級(jí)任務(wù)或者耗時(shí)任務(wù)（Long Task，即執(zhí)行時(shí)間超過(guò)50ms的任務(wù)）過(guò)度占用，則會(huì)導(dǎo)致瀏覽器對(duì)用戶操作的響應(yīng)過(guò)慢，比如點(diǎn)擊按鈕長(zhǎng)時(shí)間沒(méi)有反應(yīng)，這樣會(huì)極大地?fù)p害用戶體驗(yàn)。

用一個(gè)最極端的例子來(lái)舉例，如果JavaScript代碼陷入死循環(huán)，則頁(yè)面將基本上完全卡頓，無(wú)法響應(yīng)用戶操作。感興趣的話，可以在控制臺(tái)執(zhí)行以下代碼：

while (true) {
  console.log("hello, Chrome!");
}

如果非關(guān)鍵JavaScript任務(wù)（比如日志）過(guò)多占用主線程或者關(guān)鍵的JavaScript任務(wù)（比如響應(yīng)用戶操作）等待太久，都會(huì)傷害用戶體驗(yàn)。為了優(yōu)化主線程的調(diào)度，requestIdleCallback和isInputPending等特性相繼誕生，requestIdleCallback可以利用主線程渲染頁(yè)面的空閑時(shí)間執(zhí)行低優(yōu)先級(jí)任務(wù)，isInputPending可以用于避免耗時(shí)任務(wù)阻塞響應(yīng)用戶操作。與requestIdleCallback和isInputPending相比，Prioritized Task Scheduling提案的調(diào)度功能更加完備和強(qiáng)大，支持根據(jù)優(yōu)先級(jí)調(diào)度任務(wù)，支持指定延時(shí)調(diào)度任務(wù)，支持動(dòng)態(tài)修改任務(wù)優(yōu)先級(jí)以及取消任務(wù)。

通過(guò)使用scheduler.postTask，Aribnb的工程師將耗時(shí)任務(wù)拆分為小任務(wù)、推遲非關(guān)鍵任務(wù)、預(yù)下載圖片。從優(yōu)化效果來(lái)看，搜索結(jié)果頁(yè)的Total Blocking Time（TBT）從16s降低到了6s，大幅優(yōu)化了用戶體驗(yàn)。不過(guò)，Total Blocking Time的最佳值是300ms以?xún)?nèi)，因此Airbnb所做的優(yōu)化看起來(lái)還不算太理想。當(dāng)然，這個(gè)值應(yīng)該與具體應(yīng)用相關(guān)。

Aribnb的工程師使用Scheduling APIs實(shí)現(xiàn)了圖片預(yù)下載：

  • 當(dāng)用戶滑動(dòng)到第2個(gè)搜索結(jié)果時(shí)，提前下載了第2張圖片；
  • 當(dāng)用戶滑動(dòng)到第2個(gè)搜索結(jié)果的第2張圖片時(shí)，依次提前下載了第3、4、5張照片；
  • 我們可以在Network控制臺(tái)中看到4個(gè)圖片下載請(qǐng)求，根據(jù)瀑布圖（Waterfall），4個(gè)請(qǐng)求是按照時(shí)間順序依次請(qǐng)求的；


圖片來(lái)源：Building a Faster Web Experience with the postTask
Scheduler

隨著Web應(yīng)用越來(lái)越復(fù)雜，主線程所承擔(dān)的任務(wù)越來(lái)越多，如何減輕主線程負(fù)擔(dān)將成為瀏覽器以及Web開(kāi)發(fā)者所面臨的重大課題，按照優(yōu)先級(jí)調(diào)度任務(wù)將可能成為Web應(yīng)用以及Web框架的最佳實(shí)踐之一。另外，類(lèi)似的減輕主線程負(fù)擔(dān)的提案將不斷涌現(xiàn)，這也會(huì)進(jìn)一步強(qiáng)化Web應(yīng)用的能力。

Idle Detection API

Chrome 94正式發(fā)布了Idle Detection API，用于檢查用戶是否活躍，其判斷依據(jù)是用戶是否使用鍵盤(pán)、鼠標(biāo)、觸摸屏等。

Idle Detection API為WICG提案，由Google工程師負(fù)責(zé)，于Chrome 84開(kāi)始試用，Chrome 94正式發(fā)布。目前看來(lái)這個(gè)特性也只有Chrome支持，F(xiàn)irefox和Safari出于保護(hù)用戶隱私，都明確表示反對(duì)該特性。

Apple對(duì)于用戶的隱私及安全的堅(jiān)持已經(jīng)成為其企業(yè)文化的一部分，影響了它很多產(chǎn)品和技術(shù)上的決策，這是它不依賴(lài)廣告賺錢(qián)的商業(yè)模式所決定的。根據(jù)statcounter的最新數(shù)據(jù)，Chrome和Safari的市場(chǎng)份額分別為64%和18%，因此Safari是Chrome最大的競(jìng)爭(zhēng)對(duì)手。有Safari這樣強(qiáng)大的對(duì)手制約Chrome，有利于保證Web的健康發(fā)展。

個(gè)人也反對(duì)這個(gè)特性Idle Detection API（雖然我的反對(duì)沒(méi)啥用啊哈哈），它涉嫌侵犯了用戶隱私，可以用于追蹤用戶的日常行為習(xí)慣，可能會(huì)用于比較變態(tài)的場(chǎng)景。

為了保護(hù)用戶的隱私和安全，調(diào)用Idle Detection API需要得到用戶的授權(quán)：

// 獲取Idle Detection API授權(quán)
const state = await IdleDetector.requestPermission();
if (state !== "granted") {
  // Need to request permission first.
  return console.log("Idle detection permission not granted.");
}

Idle Detection API可以用在以下場(chǎng)景：對(duì)于即時(shí)聊天、社交媒體、在線游戲，檢查用戶是否活躍，可以幫助用戶判斷他們的聯(lián)系人是否在線。事實(shí)上，聊天應(yīng)用Slack和Google Chat都表達(dá)了對(duì)該特性的興趣。

當(dāng)年P(guān)C版的QQ可以根據(jù)用戶的鼠標(biāo)鍵盤(pán)操作自動(dòng)將狀態(tài)切換至"離開(kāi)"，然而移動(dòng)互聯(lián)網(wǎng)時(shí)代的聊天應(yīng)用默認(rèn)用戶24小時(shí)在線。移動(dòng)互聯(lián)網(wǎng)給用戶帶來(lái)便利的同時(shí)，也綁架了大家的時(shí)間和精力，你能做到24小時(shí)不用手機(jī)嗎？

Google工程師提供了一個(gè)非常直觀的Demo應(yīng)用Ephemeral Canvas，我們可以用它畫(huà)圖，當(dāng)我們60秒內(nèi)不操作電腦時(shí)，所畫(huà)的圖形會(huì)自動(dòng)被擦除掉。

JS Self-Profiling API

Chrome 94正式發(fā)布了JS Self-Profiling API，用于獲取JavaScript執(zhí)行時(shí)的性能數(shù)據(jù)。

JS Self-Profiling API為WICG提案，由Facebook的工程師負(fù)責(zé)，于Chrome 78開(kāi)始試用，Chrome 94正式發(fā)布。

并不意外的是，Safari反對(duì)該特性，原因在于性能和安全問(wèn)題。性能問(wèn)題比較好理解，收集JavaScript執(zhí)行過(guò)程中的性能數(shù)據(jù)會(huì)損耗性能。至于安全問(wèn)題，Safari工程師擔(dān)心的是黑客獲取JavaScript的編譯時(shí)長(zhǎng)從而造成可能遭受時(shí)序攻擊（Timing attack）。

看來(lái)，對(duì)于如何發(fā)展Web技術(shù)，Chrome與Safari有著非常不一樣的觀點(diǎn)，前者要激進(jìn)很多，后者則相對(duì)保守。從我寫(xiě)的《了不起的Chrome瀏覽器》系列博客也可以看出來(lái)，Google工程師開(kāi)發(fā)了非常多瀏覽器新特性，作為一個(gè)跟蹤C(jī)hrome特性的寫(xiě)作者我都有點(diǎn)學(xué)不過(guò)來(lái)了，而對(duì)于大部分沉迷于寫(xiě)代碼的開(kāi)發(fā)者來(lái)說(shuō)，很多特性可能都沒(méi)聽(tīng)說(shuō)過(guò)（此處不妨廣告一下，如果你對(duì)Chrome的最新特性感興趣，不妨關(guān)注我的微信公眾號(hào)寒雁Talk）。這是Google和Apple不同的商業(yè)模式所決定的，Apple打造了封閉而完備iOS/macOS/iPadOS/watchOS生態(tài)系統(tǒng)，對(duì)Web技術(shù)的熱情沒(méi)有自家親兒子那么高；而Web技術(shù)對(duì)于Google，是其安身立命的根本，網(wǎng)頁(yè)都沒(méi)了，搜索引擎還搜個(gè)球??？所以，Chrome對(duì)于Google來(lái)說(shuō)，遠(yuǎn)遠(yuǎn)不只是一個(gè)流量入口那么簡(jiǎn)單和無(wú)聊，Chrome致力于推動(dòng)Web技術(shù)向前發(fā)展不是一句空話，Chrome當(dāng)年的產(chǎn)品負(fù)責(zé)人成為Google的CEO也并非巧合，關(guān)于這一點(diǎn)，詳見(jiàn)我2年前寫(xiě)的博客《Chrome是如何成功的？》。

雖然Safari對(duì)于JS Self-Profiling API不感興趣，不過(guò)，來(lái)自Facebook和Microsoft的工程師都表示通過(guò)JS Self-Profiling API定位到了一些非常嚴(yán)重的性能問(wèn)題，說(shuō)明這個(gè)API應(yīng)該還是有兩把刷子的。因?yàn)镴S Self-Profiling API并不影響產(chǎn)品功能，所以Safari不支持也沒(méi)什么太大問(wèn)題。反正蘋(píng)果自研的芯片足夠快，大概不會(huì)有性能問(wèn)題？

Canvas color management

Chrome 94支持在創(chuàng)建2D canvas時(shí)，使用Display P3色域，這將增強(qiáng)2D canvas的顏色還原能力。

canvas.getContext('2d', { colorSpace: "display-p3"} );

Canvas color management于Chrome 90開(kāi)始試用，Chrome 94正式發(fā)布。這個(gè)特性我在《了不起的Chrome瀏覽器（4）：Chrome 92新增at和randomUUID方法，Canvas支持Display P3色域》博客中介紹了，不過(guò)尷尬的是我搞錯(cuò)了，它并不是Chrome 92正式發(fā)布的特性。該特性得到了Firefox和Safari的支持，因此將成為通用標(biāo)準(zhǔn)。

之前，2D canvas僅支持陳舊的sRGB色域，但是現(xiàn)在的屏幕和相機(jī)早就支持更大的色域了。

色域是什么呢？它的英文名是Color Gamut或者Color Space，是設(shè)備（顯示器、投影儀、打印機(jī)）可以表達(dá)的顏色范圍。人眼可見(jiàn)的顏色范圍是有限的，而設(shè)備能表達(dá)的顏色范圍是人眼可見(jiàn)的顏色范圍的子集，而不同色域標(biāo)準(zhǔn)比如sRGB和Display P3能表達(dá)的顏色范圍也不一樣。

Display P3的色域比sRGB的色域大25%，當(dāng)我們對(duì)比兩者時(shí)，會(huì)發(fā)現(xiàn)Display P3要比sRGB明亮很多，區(qū)別非常明顯：


圖片來(lái)源：Get Started with Display P3

對(duì)于圖像、視頻、設(shè)計(jì)、游戲、地圖、美食等應(yīng)用，顏色準(zhǔn)確性的重要性不言而喻。

一些貌似與顏色無(wú)關(guān)的應(yīng)用，如果我們的應(yīng)用不能準(zhǔn)確還原物體的顏色，也是會(huì)影響業(yè)務(wù)的。大多數(shù)情況下，買(mǎi)家秀和賣(mài)家秀的明顯差異是由于賣(mài)家過(guò)度PS導(dǎo)致的，但是也有可能是顏色沒(méi)有得到準(zhǔn)確還原導(dǎo)致的。

103 Early Hints for Navigation

Chrome 94新增了試用特性103 Early Hints for Navigation。

103 Early Hints for Navigation所對(duì)應(yīng)的IETF提案為RFC 8297: 103 Early Hints，它本質(zhì)上是對(duì)HTTP協(xié)議的更新，該提案由云服務(wù)商Fastly的工程師Kazuho Oku所提出。103 Early Hints for Navigation于Chrome 94開(kāi)始試用，正式發(fā)布的Chrome版本還不確定。

值得一提的是，F(xiàn)astly的CDN服務(wù)在今年6月份的時(shí)候出了一次故障，導(dǎo)致Amazon、Hulu、Reddit、Shopify等知名服務(wù)宕機(jī)，可見(jiàn)其影響力之大。Fastly提出103 Early Hints也不是完全用愛(ài)發(fā)電，這個(gè)特性也幫助其CDN服務(wù)。其CDN節(jié)點(diǎn)收到源站點(diǎn)的103狀態(tài)碼之后，可以根據(jù)其Header中是否包含Cache-Control: private，來(lái)提前決定是否復(fù)用CDN節(jié)點(diǎn)緩存的資源，提高響應(yīng)速度。由這個(gè)簡(jiǎn)單例子也可以看出，有時(shí)候一些技術(shù)問(wèn)題是沒(méi)法在現(xiàn)有的技術(shù)標(biāo)準(zhǔn)體系內(nèi)得到很好的解決，需要改變標(biāo)準(zhǔn)本身。由此推斷，中國(guó)的程序員應(yīng)該更多地參與國(guó)際技術(shù)標(biāo)準(zhǔn)的制定，這是有現(xiàn)實(shí)意義的。當(dāng)然，這么做短期來(lái)看投入產(chǎn)出比可能沒(méi)有那么高，但是長(zhǎng)遠(yuǎn)來(lái)看，也是必由之路吧。

下圖非常直觀地展示了103 Early Hints for Navigation的作用，它可以在前一個(gè)HTTP請(qǐng)求Header以及response都還沒(méi)有返回的時(shí)候preload后續(xù)資源，從而將后續(xù)的HTTP請(qǐng)求大幅提前，從而減少整體的請(qǐng)求時(shí)間，提高網(wǎng)絡(luò)的利用率。

  • 第1種情況：body返回之后，解析HTML，再去發(fā)起請(qǐng)求獲取css以及js資源：


圖片來(lái)源：Towards ever faster websites with early hints and
priority hints

  • 第2種情況：header返回之后，body返回之前，根據(jù)Header中的preload信息，發(fā)起請(qǐng)求獲取css以及js資源：


圖片來(lái)源：Towards ever faster websites with early hints and
priority hints

  • 第3種情況：103狀態(tài)碼返回之后，根據(jù)Header中的preload信息，發(fā)起請(qǐng)求獲取css以及js資源：


圖片來(lái)源：Towards ever faster websites with early hints and
priority hints

顯然，第3種情況下，整體的響應(yīng)時(shí)間要快很多，對(duì)網(wǎng)絡(luò)的利用率也提高了。我們不妨看一下第3種情況下，具體的請(qǐng)求過(guò)程。

瀏覽器發(fā)起訪問(wèn)example.com的請(qǐng)求：

GET / HTTP/1.1
Host: example.com

服務(wù)端返回103，Header中包含preload信息，這時(shí)瀏覽器就可以發(fā)起style.css以及script.js請(qǐng)求了：

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

服務(wù)端返回200，Header中包含preload信息，并且html文本中也包含所需要的css以及js文件（這不是廢話嗎？）。

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

<!doctype html>
[... rest of the response body is omitted from the example ...]

總結(jié)

從Chrome 94開(kāi)始，Chrome將加快其更新頻率，由每6周更新一個(gè)版本改為每4周更新一個(gè)版本。對(duì)于一個(gè)全球擁有26億用戶的產(chǎn)品，加快發(fā)布頻率可以為用戶提供更好體驗(yàn)，同時(shí)也會(huì)為研發(fā)團(tuán)隊(duì)帶來(lái)巨大的挑戰(zhàn)。Chrome能夠一直保持穩(wěn)定的迭代頻率，同時(shí)提供保持透明，提供豐富的文檔，這為Chrome生態(tài)系統(tǒng)內(nèi)的開(kāi)發(fā)者提供了便利，這一點(diǎn)非常值得我們學(xué)習(xí)。

本篇是《了不起的Chrome瀏覽器》的第6篇，創(chuàng)造了個(gè)人寫(xiě)專(zhuān)題系列博客的記錄，之前的《JavaScript深入淺出》系列只寫(xiě)了5篇。Chrome加快更新頻率之后，我也必須調(diào)整自己的寫(xiě)作計(jì)劃，與Chrome的版本迭代保持同步。

細(xì)心的同學(xué)可能會(huì)發(fā)現(xiàn)，我這篇博客有一些細(xì)微的不同點(diǎn)，以后我也會(huì)堅(jiān)持這樣做：

  • 開(kāi)始介紹每一個(gè)Chrome特性所對(duì)應(yīng)的標(biāo)準(zhǔn)提案，最頂級(jí)的技術(shù)公司掌握技術(shù)標(biāo)準(zhǔn)，了解這些提案也非常有必要。這些提案來(lái)自不同的標(biāo)準(zhǔn)化組織，比如W3C、WICG、IETF，目前來(lái)看，Chrome掌握了各種Web技術(shù)標(biāo)準(zhǔn)的主導(dǎo)權(quán)，這事有利有弊；
  • 開(kāi)始介紹Safari、Firefox、Edge以及其他大公司對(duì)于各個(gè)提案的態(tài)度以及背后的商業(yè)原因，技術(shù)可以推動(dòng)商業(yè)進(jìn)步，商業(yè)可以影響技術(shù)發(fā)展，兩者是無(wú)法分開(kāi)的，如果只了解技術(shù)，而不理解背后的商業(yè)邏輯，也是不夠的；
  • 開(kāi)始對(duì)Chrome的某些做法表達(dá)負(fù)面看法，正如我這個(gè)系列博客的標(biāo)題，整體上我對(duì)Chrome是持正面態(tài)度，因?yàn)樗_實(shí)徹底改變了前端生態(tài)系統(tǒng)，改變了我所在的行業(yè)，影響了我個(gè)人的職業(yè)發(fā)展，但是，這并不意味著我對(duì)Chrome所做的所有事情都是支持的，我會(huì)要求自己更加客觀一點(diǎn)；
  • 開(kāi)始介紹試用（origin trial）特性，Chrome的每個(gè)版本都會(huì)發(fā)布一些試用特性，而這些試用特性往往比正式特性更重要，不容錯(cuò)過(guò)，這樣也可以讓大家第一時(shí)間了解Web技術(shù)的最新發(fā)展趨勢(shì)；

本文介紹7個(gè)特性，其中6個(gè)特性都涉及到新的Web技術(shù)標(biāo)準(zhǔn)，可見(jiàn)Chrome是真的致力于Make Web Gread Again（MWGA），Google程序員為了OKR也是挺拼的。相比之下，F(xiàn)irefox和Safari看起來(lái)要佛系很多，這與各個(gè)公司的商業(yè)模式以及投入程度有關(guān)。不過(guò)，Chrome在掌握Web技術(shù)的主導(dǎo)權(quán)之后，有點(diǎn)為所欲為了，有些特性不顧同行的反對(duì)，推進(jìn)速度也有點(diǎn)太快了，這就不太妙了。Web與其他平臺(tái)不一樣的地方在于，它是開(kāi)放的，是屬于所有人的，也有向后兼容的問(wèn)題，因此Web技術(shù)標(biāo)準(zhǔn)不能一家說(shuō)了算，也不能太隨意，否則對(duì)Web技術(shù)的長(zhǎng)遠(yuǎn)發(fā)展并不利?？上У氖?，現(xiàn)在Web技術(shù)標(biāo)準(zhǔn)和國(guó)內(nèi)的程序員沒(méi)有什么太大關(guān)系，我們無(wú)從置喙，只能當(dāng)吃瓜群眾。。。等哪天國(guó)產(chǎn)瀏覽器擁有更大的話語(yǔ)權(quán)再說(shuō)吧。

還有一點(diǎn)，對(duì)于每一個(gè)特性，我都花了大量時(shí)間閱讀各種資料來(lái)理解其原理，然后根據(jù)個(gè)人理解來(lái)寫(xiě)的，很多特性我也沒(méi)有時(shí)間去寫(xiě)代碼測(cè)試，因此我的說(shuō)法難免有錯(cuò)誤的地方，歡迎各位大佬批評(píng)指正。感興趣的同學(xué)可以添加我的個(gè)人微信交流：KiwenLau。

歡迎關(guān)注寒雁Talk公眾號(hào)，關(guān)注《了不起的Chrome瀏覽器》系列博客，與我一起見(jiàn)證大前端的星辰大海！

參考資料

關(guān)于Fundebug

Fundebug專(zhuān)注于JavaScript、微信小程序、微信小游戲、支付寶小程序、React Native、Node.js和Java線上應(yīng)用實(shí)時(shí)BUG監(jiān)控。 自從2016年雙十一正式上線，F(xiàn)undebug累計(jì)處理了40億+錯(cuò)誤事件，付費(fèi)客戶有陽(yáng)光保險(xiǎn)、達(dá)令家、核桃編程、荔枝FM、微脈等眾多品牌企業(yè)。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容