共 1812 字，讀完需 3 分鐘。工欲善其事必先利其器，前端周刊本周起每周會(huì)加餐 1 篇工具技巧，里面輔以動(dòng)圖，讓大家看完就能學(xué)會(huì)，并上手使用。本文會(huì)介紹 Chrome Canary 新增的代碼覆蓋率功能、如何收集數(shù)據(jù)、如何基于它收集的數(shù)據(jù)來改進(jìn) WEB 應(yīng)用的性能。

Chrome Canary 開發(fā)者工具中本周新增了 Coverage 功能，該功能同時(shí)適用于 JS 和 CSS，并有望很快登陸 Chrome 正式版。

Coverage 顧名思義就是代碼覆蓋率的意思，本文會(huì)跟大家介紹 Coverage 功能是什么、如何收集數(shù)據(jù)、及如何基于它收集的數(shù)據(jù)來改進(jìn) WEB 應(yīng)用的性能。

Coverage 功能使用動(dòng)態(tài)分析（Dynamic Analysis）法來收集代碼運(yùn)行時(shí)的覆蓋率，讓開發(fā)者能夠窺探他的代碼到底有多大比例在發(fā)光發(fā)熱。動(dòng)態(tài)分析是指在應(yīng)用運(yùn)行狀態(tài)下收集代碼執(zhí)行數(shù)據(jù)的過程，換句話說，覆蓋率數(shù)據(jù)就是在代碼執(zhí)行過程中通過標(biāo)記收集到的。

Coverage 工具怎么用？

在探討 Coverage 工具帶來的好處之前，先快速看下如何使用它來收集覆蓋率數(shù)據(jù)：

1. 調(diào)起 Coverage 面板

2. 錄制 Coverage 數(shù)據(jù)

與 Performance 面板類似，Coverage 面板左上角有 3 個(gè)按鈕，點(diǎn)擊錄制的時(shí)候會(huì)開始錄制，同時(shí)錄制按鈕變紅，再次點(diǎn)擊錄制按鈕會(huì)停止錄制并把錄制到的覆蓋率數(shù)據(jù)展示出來。此外，可以點(diǎn)擊中間的快捷按鈕，“刷新并開始錄制”，待頁面加載完之后停止錄制。

Coverage 工具要求我們手動(dòng)錄制的原因是：動(dòng)態(tài)分析過程需要監(jiān)控每行代碼的執(zhí)行情況，也就意味著錄制過程中執(zhí)行的代碼要比原始的應(yīng)用的代碼要多，因?yàn)閯?dòng)態(tài)分析過程需要對(duì)你的代碼進(jìn)行某種變換才知道哪些行被執(zhí)行了。

3. 查看 Coverage 數(shù)據(jù)

如上圖所示，Coverage 錄制結(jié)果表格展示了錄制過程中加載的所有 JS 和 CSS 文件，以及每個(gè)文件的大小、運(yùn)行時(shí)覆蓋率，匯總數(shù)據(jù)展示在頁面底部的狀態(tài)欄中（上面的截圖沒有展示）。單擊單個(gè)靜態(tài)資源能將其在 Sources 面板中打開，代碼行號(hào)的左邊用紅綠色的條來標(biāo)識(shí)代碼是否在錄制過程中被執(zhí)行到。

Coverage 數(shù)據(jù)有啥用？

上面錄制的數(shù)據(jù)中，最大的文件是 vendor.js，其中 55% 的代碼都沒有執(zhí)行過，約 80 KB，這已經(jīng)相當(dāng)于一張典型圖片的文件大小了。

如果某個(gè)文件覆蓋率低（即未使用代碼比例很高），通常意味著用戶加載了太多不必要的代碼（要么真的是無用代碼，要么是當(dāng)前時(shí)點(diǎn)還沒執(zhí)行到的代碼），有性能常識(shí)的同學(xué)不難推斷出，這會(huì)導(dǎo)致頁面的完全加載時(shí)間、或單頁應(yīng)用的啟動(dòng)時(shí)間變慢，在慢速網(wǎng)絡(luò)下的性能損耗會(huì)尤其明顯；此外，更多代碼的解析、編譯也就意味著更多的硬件資源消耗，在低端設(shè)備上也會(huì)存在明顯的性能問題。

在筆者看來，Coverage 數(shù)據(jù)至少能從下面 2 個(gè)方面指導(dǎo)我們進(jìn)行 WEB 應(yīng)用的優(yōu)化：

除移死代碼

以 Coverage 數(shù)據(jù)為參考，我們能了解頁面重?zé)o用代碼的比例到底有多大。現(xiàn)實(shí)世界中，很多工程師可能是在遺留代碼庫上工作，并且遺留代碼庫存在的時(shí)間還很長，那么很可能這個(gè)代碼庫中存在大量的無用代碼，但是誰也不敢刪除他們，因?yàn)?JS 這門語言的動(dòng)態(tài)性，你不能粗暴的把哪些看起來“沒有被使用”的代碼直接刪掉，除非你很清楚所有的代碼執(zhí)行路徑，很顯然這對(duì)于大型應(yīng)用或者遺留代碼庫來說是不現(xiàn)實(shí)的。

怎么移除死代碼呢？我們可以依賴打包工具，比如 UglifyJS 在壓縮代碼時(shí)支持直接刪除死代碼的配置項(xiàng)。而 Webpack 2 中引入了 Tree Shaking 的特性，能夠自動(dòng)把項(xiàng)目中沒有用到的代碼從打包中去掉，但是這種優(yōu)化僅限于被 export 的代碼?？偠灾来a要盡可能想辦法去掉，Coverage 工具能提供一個(gè)判斷基準(zhǔn)。

懶加載代碼

如果能刪的死代碼都刪了，但是 Coverage 數(shù)據(jù)還是居高不下，那么你應(yīng)該換個(gè)角度思考。就像前文所說，JS 是動(dòng)態(tài)語言，可能部分代碼在頁面加載時(shí)并沒有用到，但是用戶后來的操作會(huì)觸發(fā)這些代碼的執(zhí)行，為什么不讓這些代碼在需要的時(shí)候再加載呢？聰明的你可能已經(jīng)想到了，這就是懶加載的技術(shù)。

使用 Webpack 打包且沒有對(duì)配置做特別調(diào)優(yōu)的話，它默認(rèn)會(huì)把所有依賴打包成一個(gè)巨大的文件，很容易出現(xiàn)首次加載覆蓋率很低的情況，在 Webpack 中實(shí)現(xiàn)懶加載可以參考 Code Splitting 和 bundle-loader，具體的配置細(xì)節(jié)這里不展開講。使用懶加載之后可以極大的減少頁面初次下載的代碼，從而提高性能。需要注意的是，懶加載優(yōu)化需要在模塊數(shù)量和模塊大小之間把握一個(gè)平衡，否則過多的模塊懶加載反而對(duì)性能不利，因?yàn)槊總€(gè) HTTP 請(qǐng)求也是有額外開銷的。

One More Thing

本文作者王仕軍，商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。如果你覺得本文對(duì)你有幫助，請(qǐng)點(diǎn)贊！如果對(duì)文中的內(nèi)容有任何疑問，歡迎留言討論。想知道我接下來會(huì)寫些什么？歡迎訂閱知乎專欄：《前端周刊：讓你在前端領(lǐng)域跟上時(shí)代的腳步》。