前言
工欲善其事，必先利其器，
在前端作業中，我們常常使用到Chrome開發者工具去做各種各樣的事情，
但是您真的了解這些開發者工具嗎？
官方檔案還是挺詳細的：chrome-devtools檔案，
但是檔案中仍然會有一些功能沒有描述到或者被一筆帶過，
而我的這篇指南，會略過那些一目了然的功能以及一些容易替代的方案，寫一寫那些您可能不太了解的功能和檔案描述不清的功能，
閱讀本篇文章需要有一定的前端基礎，
媒體查詢功能
Chrome開發者工具不僅可以除錯web應用，還可以模擬各種終端設備，
通過激活下圖中紅框部位開啟設備工具列，
工具列可以切換模擬各種型號的設備，也可以通過自適應模式（Responsive）來調整視口，
這里通過更多工具中的Show media queries查看媒體查詢：
圖中藍色區塊為最大寬度斷點，黃色區塊為最小寬度斷點，
右鍵相應區塊還可以跳轉到具體的css檔案中的媒體查詢代碼，
模擬傳感器（地理位置，手機朝向）
點擊更多工具中的Sensors（傳感器）
在這里可以模擬地理位置，手機朝向
生成頁面全尺寸快照圖片
通過下圖操作，可以生成一張頁面全尺寸的快照，
而它上面那個選項是生成當前視口大小的圖片，
控制臺快速獲取元素面板的元素
在元素面板上選中一個元素后：
細心的朋友會發現后面總是會出現一個== $0的提示，
此時在控制臺輸入$0,實際上就可以獲取到該元素，
通過這種方式，即使對于那些沒有class和id的元素，我們也可以在控制臺快速獲取并使用，
您可能會問：那我要是想在控制臺呼叫多個這樣的元素呢？
選中元素，右鍵，選擇選項：Store as global variable，
此時會將選中的元素存盤在一個臨時變數中，并自動在控制臺輸出這個變數的名字，
頁面跳轉到元素面板指定的元素
某些時候頁面元素出現BUG，不知道跑到哪去了，我們需要頁面跳轉到這個元素所在的位置，
如果我們知道它的id或者class，我們可以通過在控制臺輸入js命令去跳轉：
document.querySelector('.icon-cool').scrollIntoView()
當然也可以通過我們上面說到的$0做到：
$0.scrollIntoView()
但是有個更簡單的辦法，那就是右鍵元素面板上的指定元素，然后點擊Scroll into view的選項，
DOM斷點
同樣右鍵元素面板上的元素，發現有個Break on的選項，這里可以打DOM斷點，
從上往下依次是子節點改變時斷下，元素屬性改變時斷下，節點移除時斷下，
打下斷點后，在左側會有斷點標識，右側的DOM Breakpoints也會有相應的顯示，
點擊DOM Breakpoints的相應DOM斷點，元素面板也會定位到相應元素，
當js去修改指定元素的DOM結構時，就會在修改的位置斷下，
這種斷點很方便查找到究竟是哪里對頁面元素進行了修改，
元素事件偵聽器
在元素面板選中元素，右側的Event Listeners會顯示該元素上的事件，
如果勾選了Ancestors（祖先），那么會展示祖先節點的事件，通常不需要勾選這個，
點擊事件右側的鏈接可以跳轉到附加事件的代碼，
通常一些js框架或庫（比如jQeury）會將原生DOM事件進行封裝，而這會導致我們通過元素事件偵聽器跳轉到的代碼是這些庫檔案的封裝代碼，
不過如果我們勾選了Framework listeners（框架偵聽器），那么就會跳轉到我們使用庫檔案事件API的地方，而不是庫檔案里，
Framework listeners對于jQuery這樣對事件進行簡單封裝的特別好用，但是對于React這種的話作用有限，
查看當前頁面對css和js使用覆寫率
通過以下方式打開Coverage選項卡，這個可以查看當前頁面對css和js的使用覆寫率，
點擊左上角按鈕開始記錄：
如上圖可以單純查看css還是js，或者都查看，
選中單個檔案，還可以查看具體是哪些代碼或者css沒有使用到，
記錄期間，我們做各種操作，都會影響到這個使用覆寫率的變動，
對于現在常用的單頁面應用而言，尤為有效，因為切換頁面實際并沒有改變html，所以這個記錄一直有效，
對于以往采用jQuery的多頁面應用而言，當切換了頁面之后，記錄就重新開始了，
不過不管是單頁面還是多頁面，通過這種方式都是可以查看相應的js和css的使用覆寫率的，對于優化css和js，洗掉無用的廢代碼，以及代碼檔案拆分都很有幫助，
使用本地檔案除錯生產環境網站代碼
我們除錯生產環境的BUG，經常需要修改樣式或者js，但是頁面一重繪這些東西就又還原了，
所以這里有個神技，可以將生產環境的參考檔案進行本地化，然后修改本地化后的檔案進行除錯，
首先我們需要打開在Source面板下左側的Overrides選項卡，選擇一個本地檔案夾作為覆寫檔案夾，
這里我選擇了一個名為test的檔案夾，
然后我們切換到Source面板的Page選項卡，選中某個檔案，然后右鍵，選中選項Save for overrides，
此時切回Overrides選項卡，發現test檔案夾中已存在相關的js檔案，
修改該檔案的js內容，再保存，即使重繪之后修改后的內容依然會生效，并且頁面會加載我們修改之后的js檔案，
Animation影片檢查器
通過下圖方式可以打開Animation檢查器：
這個檢查器自動開始監聽頁面上的影片，但是這個時候影片已經加載完了，監聽不到，需要我們重新重繪頁面才行，
選中其中的一個影片，會顯示如下圖的效果：
通過它我們可以查看和調整CSS影片和過渡的各種效果，
Rendering選項卡（高亮重排重繪合成層，fps和gpu占用，滾動優化，媒體查詢模擬如列印）
Rendering選項卡，顧名思義是做一些渲染相關的事，
通過下圖方式打開Rendering選項卡：
下面是選項卡的界面：
-
Paint flashing 高亮頁面重繪區域，
-
Layout Shift Regions 高亮布局變動區域（重排），
-
Layer borders 高亮合成層邊框，對于減少合成層還是挺好用的，
以上三點，如果不太清楚，可以看看這篇好文：瀏覽器渲染詳細程序：重繪、重排和 composite 只是冰山一角，
簡略一點來說，渲染程序就是DOM樹+樣式樹，合成渲染樹，渲染樹加上層疊遮罩之類的再演變為Layer樹，Layer樹再合成為為Graphics Layers即Composite Layer，再丟給GPU進行處理，
-
Scrolling Performance Issues 用于優化滾動性能問題，
這個是用來高亮可能會影響滾動性能的元素，這些元素主要指系結了scroll事件和touch事件的元素，
scroll大家可能會比較理解，touch的話其實也可以影響滾動性能，最直觀的就是只要我們禁止了某元素上touch的事件中禁止瀏覽器默認行為，那么就不會再觸發scroll事件，
而touch的影響還不止如此，比如將touch-action改為manipulation可以減少移動端瀏覽器在用戶點擊事件的延遲，但是這個東西會影響到滾動時的性能，
當您開Scrolling Performance Issues發現頁面上一堆高亮的touch事件時，可以考慮touch-action:auto來去除，
具體的優化可能得根據實際情況去處理，哪里有問題優化哪里，取得一個平衡即可，
-
Highlight ad frames 高亮用于廣告的iframe（試了下，谷歌的推廣廣告識別沒問題，百度的沒測），
-
Hit-test borders 展示點擊測驗的區域，（雞肋，請忘記），
-
Emulate CSS media type 模擬媒體查詢是列印還是終端螢屏，
-
Emulate CSS media feature prefers-color-scheme 模擬媒體查詢的系統主題，具體參考prefers-color-scheme，
-
Emulate CSS media feature prefers-reduced-momition 模擬媒體查詢的開啟影片減弱功能，具體參考prefers-reduced-motion，
保留頁面控制臺記錄和網路請求記錄
Chrome的Console面板和Network面板都有Preserve Log這個選項，當勾選了這個選項后，會保留當前選項卡的控制臺和請求記錄，
對于涉及到多個頁面間跳轉的問題，這個功能很有幫助，
切換控制臺的執行環境（iframe中運行腳本）
Console面板上面有個名為Javascript contexts的選擇器，一般值默認為top，
top表示當前執行環境為當前頁面，而如果想切換到當前頁面各個iframe，就需要進行相應切換，
比如，在博客園首頁，我們可以切換到各個廣告iframe的運行環境，
與此相關的一個功能是，只輸出所選運行環境的列印日志：
點擊右上角齒輪打開控制臺設定，勾選Selected context only即可，
控制臺的實時運算式
在控制臺面板有個眼睛一樣的圖示，名為：Create live express（創建實時運算式），
點擊它創建一個入上圖紅框所示的小面板，
輸入運算式可以自動監控這個運算式，
比如如果實時運算式為a，如果a的值變動了，那么這個實時運算式的值也會變動，
控制臺的API
我這里直接給開發者檔案的地址了，畢竟有點多，建議了解一下，知道有哪些功能即可，
比如monitor（監聽函式執行）和monitorEvent（監聽事件）還是有些用處的，
檔案地址為：API串列和工具API串列，
可重復執行的控制臺腳本片段
如果您在除錯BUG時總是在控制臺多次重復執行大段的相同的JS代碼，
那么您可以考慮用Snippet（片段），
這個東西雖然作用于控制臺，但是卻不是在Console面板，而是在Source面板，
如圖所示，我們通過點擊New snippet新建了一個叫TestSnippet的代碼片段，
然后我們可以點擊右下角的運行或者用Ctrl+Enter在控制臺運行這段代碼片段，
XHR/Fetch 斷點
在Sources面板，右側會顯示XHR/fetch Breakpoints，
點擊加號，可以輸入字符，如果輸入mynameis，那么就會在ajax請求或者fetch請求的URI包含mynameis時斷下，
如果不填，那么也會新增一行，表示斷下所有的ajax請求和fetch請求，
事件偵聽器斷點
在Sources面板，右側會顯示Event Listener Breakpoints，
顧名思義，用來給相應事件打斷點的，
這里基本上收錄了所有的事件，連WebAudio，Worker，Timer的都有，
例外斷點
同樣在Sources面板右側會顯示例外斷點的圖示：
激活后可以在各個未捕獲的例外處斷下，激活后還可以通過進一步勾選 Pause on caught exceptions在已捕獲的例外處也斷下，
腳本黑盒化（Blackbox script）
在Source面板，選中某js腳本檔案后右鍵，或者在除錯的堆疊中右鍵，都會出現一個Blackbox script選項，
點擊這個選項，可以讓我們在除錯時認為此腳本總是對的，忽略此腳本，不論是除錯程序或者堆疊都不會進入這個腳本，
一般用來黑盒化一些js庫，比如jQuery或者lodash之類的，
網路面板的截圖功能
Network面板中有個截屏功能，開啟之后再重新加載頁面，就會如下圖顯示各個時間段下的截圖，
雙擊這些縮略圖，可以放大查看當時頁面的具體樣子，
單擊縮略圖，可以顯示當前縮略圖時間點前發送的所有請求，
網路面板關于網路請求的一些優化
同域名請求數量限制（HTTP/1.0或HTTP/1.1）
如果網路請求出現排隊的情況，那么說明是在單個域上提出了太多請求，
在HTTP/1.0或HTTP/1.1連接上，Chrome每個主機最多允許六個同步TCP連接，
想要優化這一點，可以將關鍵請求提前，不關鍵請求延后，
如果都是關鍵請求，那么可以嘗試使用HTTP 2，（在Network面板可以展示Protocol顯示）
如果條件有限，可以將這些請求放在不同的域名上，然后用nginx指向同一個源頭，這樣同樣可以解決這個問題
請求第一個位元組的時間過長 Time To First Byte (TTFB)
我們查看一下博客園首頁的請求，
可以看見每個請求后面都有一個綠色的區域，這個綠色區域表示每個請求的Time To First Byte (TTFB)，即請求第一個位元組的時間，
點開一個具體的請求，看一下：
通常原因是瀏覽器與服務端的請求連接速度很慢，或者服務端的請求回應過慢，
簡單來說，就是網路連接慢，或者是服務端代碼寫得太辣雞，
如果是網路連接慢，可以用CDN，或者換個近一些的服務器，
如果是服務端回應慢，那么可以考慮快取，或者優化介面，那就是服務端的事情了，
內容下載慢
這里直接用Chrome官網的圖片吧：
一般表現于請求的下載時間過長，也就是請求后面跟著的藍條，
原因基本上就是js或者其它的一些資源檔案太大了，導致下載過慢，
因為用的是100M的網，所以我比較難找這樣的例子，不過用瀏覽器的模擬3G網的話，其實博客園很多那種二次元風格，自帶一張二次元大背景的博客都會出現這種現象，
這種建議將圖片尺寸壓縮一下，
網路面板時間分解階段說明
這里列出Timing選項卡可以看到的各個時間階段：
- Queueing（排隊）：瀏覽器在以下情況下將請求排隊:
- 有更高優先級的請求，
- 已為該來源打開了六個TCP連接，僅適用于HTTP/1.0和HTTP/1.1，
- 瀏覽器正在磁盤快取中短暫分配空間
- Stalled：出于Queueing中描述的任何原因，該請求都可能被暫停
- DNS Lookup：瀏覽器正在決議請求的IP地址
- Proxy negotiation：瀏覽器正在與代理服務器協商請求
- Request sent：請求發送時間
- ServiceWorker Preparation：瀏覽器正在啟動service worker
- Request to ServiceWorker：請求發送到service worker的時間
- Waiting (TTFB): 瀏覽器等待第一個位元組回應的時間
- Content Download：回應內容下載時間
- Receiving Push：瀏覽器正在通過HTTP/2服務器推送接收此回應的資料
- Reading Push： 瀏覽器正在讀取先前接收的本地資料，
查看請求的依賴關系
各個請求都有著它們各自的依賴關系，最常見的是圖片、js和css依賴html請求，
只有在html請求完畢才會在上面慢慢加載這些資源檔案，
同樣以博客園為例：
我們按住Shift，滑鼠浮動到analytics.js這個請求上，可以看到www.cnblogs.com那個請求變綠了，collect那個請求變紅了，
這個表示analytics.js這個請求，依賴于www.cnblogs.com，而collect這個請求依賴于analytics.js，
WebSocket訊息的監控
如下圖：
我們通過Network面板上的型別篩選到WebSocket請求，點開這個請求，我們可以看到相應的訊息，
Audit面板
關于Audit面板這里不講使用方法，主要是太多了，
但是這個東西確實很方便，這里是：參考檔案，
這里要說的是這個東西需要翻墻，如果翻不了，可以裝個LightHouse的擴展插件，如果下不了或者不想更新麻煩，有個更好的辦法，
使用微軟的Edge，基于Chromium的那個，然后在它的商店裝個SiteTool的擴展插件即可，
Performance面板性能分析
Performance面板主要是用來分析運行時的性能，加載的用Audit即可，
關于怎么使用這里就太多了，咱們先挑最簡單的一個流程來講，
我們首先看一下一個性能良好的結果圖：
然后我們再將CPU變慢6倍，再看一下性能不好的結果圖：
FPS概覽
對比第一張圖，我們發現第二張圖關于FPS那一行出現了很多紅色，并且綠色的高度明顯降低，
這表示它的FPS值很低，一般給用戶的感受就是很卡，出現了紅色表示會影響到用戶體驗，
CPU概覽
同時我們再對比上面兩張圖，發現第一張圖的CPU那行顏色區域都很低，而第二張圖CPU那塊都占滿了，這表示CPU占用率高，
FPS詳情
我們之前只是對哪個時間段的FPS低有了一個大致的了解，如果我們想要了解具體的情況，我們可以將滑鼠浮動到Frames那一行，這樣可以了解到具體的幀的FPS，
同樣點擊選中那一幀，還可以在下方的摘要（Summary）中查看具體的情況，
CPU作業詳情
選中Main那一行，下方的摘要就會顯示主執行緒CPU各個活動的耗時，
但是即使如此，可能您也只能知道大致是哪個階段出了問題，比如渲染還是腳本執行時間過長，
如果想要快速定位，您可以展開Main查看具體的作業詳情，
在Main那一行的展開詳情中，可能會出現一些紅色的三角符號或者紅色區塊，點擊選中之后會有相應的優化提示，下方摘要也會展示出來，
比如上圖中就是因為強制回流導致的性能瓶頸，
可以看一下摘要中紅框中的鏈接，很方便地告訴了我們到底是哪段代碼出了問題，點擊進去：
我們可以發現是呼叫了offsetTop導致的回流，然后優化這部分代碼即可，
至于具體的優化我們這里就不講了，關于性能優化可以參考一下:Web Fundamentals的Performance，
關于更多性能面板的介紹可以看下：如何使用Timeline 和 Timeline事件參考，
這里說個小技巧，在Timeline上可以按Ctrl+F，然后搜索事件，這樣可以在大量的事件中快速定位想找的事件，
JavaScript分析器
還是More tools中打開JavaScript Profiler面板，怎么打開這里不講了，操作好多遍了，
然后記錄下頁面一段時間的js執行情況，
我們看到的上圖就是記錄結果，默認是分析模式是Heavy (Bottom Up)，
這個模式下可以看到哪些函式對性能影響最大并能夠檢查這些函式的呼叫路徑，
分析模式有下面三種：
- Chart，顯示按時間順序排列的火焰圖
- Heavy (Bottom Up)，按照函式對性能的影響列出函式，讓您可以檢查函式的呼叫路徑
- Tree (Top Down)，顯示呼叫結構的總體狀況，從呼叫堆疊的頂端開始，
Heavy (Bottom Up)和Tree (Top Down)比較簡單，這里直接略過，
Chart的火焰圖如下：
火焰圖越高的部分表示函式呼叫的堆疊越高，但是高度并不代表什么，
這樣看圖肯定是看不出來什么，所以我們需要選中一塊區域放大，如下圖：
色塊越寬表示該函式的執行時間越長，而這個才表示該函式可能需要優化，
滑鼠浮動到色塊上可以看到函式執行的具體資訊，這里只說幾個重要的點：
- Name，函式的名稱，
- Self time，完成函式當前的呼叫所需的時間，僅包含函式本身的宣告，不包含函式呼叫的任何函式，
- Total time，完成此函式和其呼叫的任何函式當前的呼叫所需的時間，
- URL，函式在哪個腳本中，并且它的行號，
- Aggregated self time，記錄中函式所有呼叫的總時間，不包含此函式呼叫的函式，
- Aggregated total time，函式所有呼叫的總時間，包含此函式呼叫的函式，
- Not optimized，如果分析器已檢測出函式存在優化可能，會在此處列出，
點擊相應色塊可以進到具體的函式中查看，
Memory面板
Memory面板主要用來監控頁面的記憶體使用情況，并解決一些記憶體泄漏或者頻繁的垃圾回收等問題，
Heap snapshot（堆快照）
使用堆快照一般用來解決記憶體泄漏的問題，
我們在記憶體面板Take snapshot之后，可以看到這樣一個畫面：
然后我們在上方輸入Detached，會篩選出下面的結果：
這里可以看看到底是哪些DOM節點沒有釋放，
官網檔案上顯示如果DOM節點沒有被參考，那么應該是紅色的，但是實際上不是如此，
不過這個功能還是有些用處的，選中相應的節點可以看看到底是哪些變數參考了，然后看是否能消除這些變數，
這里得注意圖中的Shallow Size表示物件自身占用記憶體的大小，Retained Size表示通過保持對其他物件的參考隱式占用的總記憶體大小，而Distance是物件到GC roots（如window或者DOM樹）的距離，
Allocation instrumentation on timeline（時間線上的記憶體分配工具）
翻譯起來有點繞口，實際上就是一個用來按時間查看記憶體分配情況的工具，
我們直接看一下檢測結果：
我們可以看到時間軸上有不少柱子，這些柱子高度會變，表示所在的那個點分配的物件大小，
我們可以看到圖中我們選中的那個時間點分配的記憶體大概為384byte，旁邊那個100B是一個參照線，
柱子的顏色代表這些物件是否被回收了，藍色代表還存在，灰色代表被回收了，
Application面板
這個面板內容多，但是簡單易懂，本來想著寫點的，太簡單就算了，
主要就是關于存盤和快取的，
除此之外，就是有個關于PWA的除錯，這里可以參考：除錯 Progressive Web App，
我對這個涉獵較少，就不班門弄斧了，
Security面板
這個面板主要是看是否https的，有用的時候是有用，沒用的時候是真沒用，
總結
學習Chrome開發者工具不僅能提高我們工具的使用效率，這其中涉及到的很多前端知識點也能令人眼界大開，
在閱讀Chrome的開發者工具檔案時有很多缺失和不同步，這是因為它在不斷地演進，包括我現在提到的一些功能也許在將來有一天就消失或者增強了，
所以我覺得對于這份指南您可以當做一份索引，有所了解，但不必記住，只要在遇到問題的時候能記起來我可以用什么工具來處理就夠了，
希望這篇博客能幫助到您,也希望您能對疏漏之處指正一二，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/146949.html
標籤：JavaScript