Chrome Devtools 的 Performance 工具是性能分析和優(yōu)化的利器，因?yàn)樗梢杂涗浢恳欢未a的耗時(shí)，進(jìn)而分析出性能瓶頸，然后做針對(duì)性的優(yōu)化。
這么強(qiáng)大的工具肯定是要好好掌握的，今天我們就來(lái)做一個(gè)性能優(yōu)化的案例來(lái)快速上手 Performance 吧。
性能分析
首先，我們準(zhǔn)備這樣一段代碼：
- "en">
- "UTF-8">
很明顯，兩個(gè) script 標(biāo)簽是兩個(gè)宏任務(wù)，第一個(gè)宏任務(wù)的調(diào)用棧是 a、b，第二個(gè)宏任務(wù)的調(diào)用棧是 c、d。
我們用 Performance 來(lái)看一下是不是這樣：
首先用無(wú)痕模式打開(kāi) chrome，無(wú)痕模式下沒(méi)有插件，分析性能不會(huì)受插件影響。
打開(kāi) chrome devtools 的 Performance 面板，點(diǎn)擊 reload 按鈕，會(huì)重新加載頁(yè)面并開(kāi)始記錄耗時(shí)：
過(guò)幾秒點(diǎn)擊結(jié)束。
這時(shí)候界面就會(huì)展示出記錄的信息：
圖中標(biāo)出的 Main 就是主線程。
主線程是不斷執(zhí)行 Event Loop 的，可以看到有兩個(gè) Task(宏任務(wù))，調(diào)用棧分別是 a、b 和 c、d，和我們分析的對(duì)上了。(當(dāng)然，還有一些瀏覽器內(nèi)部的函數(shù)，比如 parseHtml、evaluateScript 等，這些可以忽略)
Performance 工具最重要的是分析主線程的 Event Loop，分析每個(gè) Task 的耗時(shí)、調(diào)用棧等信息。
當(dāng)你點(diǎn)擊某個(gè)宏任務(wù)的時(shí)候，在下面的面板會(huì)顯示調(diào)用棧的詳情(選擇 bottom-up 是列表展示， call tree 是樹(shù)形展示)
每個(gè)函數(shù)的耗時(shí)也都顯示在左側(cè)，右側(cè)有源碼地址，點(diǎn)擊就可以跳到 Sources 對(duì)應(yīng)的代碼。
直接展示了每行代碼的耗時(shí)，太方便了!
工具介紹完了，我們來(lái)分析下代碼哪里有性能問(wèn)題。
很明顯， b 和 d 兩個(gè)函數(shù)的循環(huán)累加耗時(shí)太高了。
在 Performance 中也可以看到 Task 被標(biāo)紅了，下面的 summary 面板也顯示了 long task 的警告。
有同學(xué)可能會(huì)問(wèn)：為什么要優(yōu)化 long task 呢?
因?yàn)殇秩竞?JS 執(zhí)行都在主線程，在一個(gè) Event Loop 中，會(huì)相互阻塞，如果 JS 有長(zhǎng)時(shí)間執(zhí)行的 Task，就會(huì)阻塞渲染，導(dǎo)致頁(yè)面卡頓。所以，性能分析主要的目的是找到 long task，之后消除它。
可能很多同學(xué)都不知道，其實(shí)網(wǎng)頁(yè)的渲染也是一個(gè)宏任務(wù)，所以才會(huì)和 JS 執(zhí)行互相阻塞。關(guān)于這一點(diǎn)的證明可以看我前面一篇文章：
通過(guò) Performance 證明，網(wǎng)頁(yè)的渲染是一個(gè)宏任務(wù)
找到了要優(yōu)化的代碼，也知道了優(yōu)化的目標(biāo)(消除 long task)，那么就開(kāi)始優(yōu)化吧。
性能優(yōu)化
我們優(yōu)化的目標(biāo)是把兩個(gè) long task 中的耗時(shí)邏輯(循環(huán)累加)給去掉或者拆分成多個(gè) task。
關(guān)于拆分 task 這點(diǎn)，可以參考 React 從遞歸渲染 vdom 轉(zhuǎn)為鏈表的可打斷的渲染 vdom 的優(yōu)化，也就是 fiber 的架構(gòu)，它的目的也是為了拆分 long task。
但明顯我們這里的邏輯沒(méi)啥好拆分的，它就是一個(gè)大循環(huán)。
那么能不能不放在主線程跑，放到其他線程跑呢?瀏覽器的 web worker 好像就是做耗時(shí)計(jì)算的性能優(yōu)化的。
我們來(lái)試一下：
封裝這樣一個(gè)函數(shù)，傳入 url 和數(shù)字，函數(shù)會(huì)創(chuàng)建一個(gè) worker 線程，通過(guò) postMessage 傳遞 num 過(guò)去，并且監(jiān)聽(tīng) message 事件來(lái)接收返回的數(shù)據(jù)。
- function runWorker(url, num) {
- return new Promise((resolve, reject) => {
- const worker = new Worker(url);
- worker.postMessage(num);
- worker.addEventListener('message', function (evt) {
- resolve(evt.data);
- });
- worker.onerror = reject;
- });
- };
然后 b 和 c 函數(shù)就可以改成這樣了：
- function b() {
- runWorker('./worker.js', 10*10000*10000).then(res => {
- console.log('b:', res);
- });
- }
耗時(shí)邏輯移到了 worker 線程：
- addEventListener('message', function(evt) {
- let total = 0;
- let num = evt.data;
- for(let i = 0; i< num; i++) {
- total += i;
- }
- postMessage(total);
- });
完美。我們?cè)倥芤幌略囋嚕?
哇，long task 一個(gè)都沒(méi)有了!
然后你還會(huì)發(fā)現(xiàn) Main 線程下面多了兩個(gè) Worker 線程：
雖然 Worker 還有 long task，但是不重要，畢竟計(jì)算量在那，只要主線程沒(méi)有 long task 就行。
這樣，我們通過(guò)把計(jì)算量拆分到 worker 線程，充分利用了多核 cpu 的能力，解決了主線程的 long task 問(wèn)題，界面交互會(huì)很流暢。
我們?cè)倏聪?Sources 面板：
對(duì)比下之前的：
這優(yōu)化力度，肉眼可見(jiàn)!
就這樣，我們一起完成了一次網(wǎng)頁(yè)的性能優(yōu)化，通過(guò) Peformance 分析出 long task，定位到耗時(shí)代碼，然后通過(guò) worker 拆分計(jì)算量進(jìn)行優(yōu)化，成功消除了主線程的 long task。
代碼傳到了 github，感興趣的可以拉下來(lái)用 Performance 工具分析下：
https://github.com/QuarkGluonPlasma/chrome-devtools-exercise
總結(jié)
Chrome Devtools 的 Performance 工具是網(wǎng)頁(yè)性能分析的利器，它可以記錄一段時(shí)間內(nèi)的代碼執(zhí)行情況，比如 Main 線程的 Event Loop、每個(gè) Event loop 的 Task，每個(gè) Task 的調(diào)用棧，每個(gè)函數(shù)的耗時(shí)等，還可以定位到 Sources 中的源碼位置。
性能優(yōu)化的目標(biāo)就是找到 Task 中的 long task，然后消除它。因?yàn)榫W(wǎng)頁(yè)的渲染是一個(gè)宏任務(wù)，和 JS 的宏任務(wù)在同一個(gè) Event Loop 中，是相互阻塞的。
我們做了一個(gè)真實(shí)的優(yōu)化案例，通過(guò) Performance 分析出了代碼中的耗時(shí)部分，發(fā)現(xiàn)是計(jì)算量大導(dǎo)致的，所以我們把計(jì)算邏輯拆分到了 worker 線程以充分利用多核 cpu 的并行處理能力，消除了主線程的 long task。
做完這個(gè)性能優(yōu)化的案例之后，是不是覺(jué)得 Peformance 工具用起來(lái)也不難呢?
其實(shí)會(huì)分析主線程的 Event Loop，會(huì)分析 Task 和 Task 的調(diào)用棧，找出 long task，并能定位到耗時(shí)的代碼，Performance 工具就算是掌握了大部分了，常用的功能也就是這些。
原文鏈接：https://mp.weixin.qq.com/s/T_Z_xKByZwbrvERoG-1OFw
