相信絕大部分的前端是使用Chrome進行開發的，一方面Chrome瀏覽器確實做得好，更重要的一方面是因為Chrome有一個無法匹敵的調試工具。用好這個調試工具可以提高編程效率，幫助快速地定位問題。

　　01打印

　　（1）console.table

　　最常用的打印是console.log，console.log有時候打印一些復雜的數據結構顯得有點吃力，如打印一個元素是object的數組：

　　為了查看每個數組的元素，必須得一個個展開，就顯得有點麻煩了，其實可以用console.table：

　　瞬間就變得非常清爽，同時console.table還支持打印對象屬性，如下的Student對象，有name和score兩個屬性：

　　（2）console.dir

　　console.log是側重于字符串化的打印，而console.dir能遞歸打印對象的所有屬性，如下打印一個dom結點：

　　console.log把它的html打印出來了，而console.dir把它的所有屬性打印出來，方便進行檢查。

　　（3）打印帶樣式

　　經常會看到有些網站會在控制臺打印一些提示語，并且這些提示語還帶樣式，這個是用%c加上的樣式：

　　02檢查沒有用的CSS/JS

　　Chrome 49新增了一個功能，能夠檢查頁面上的CSS/JS沒有用到的比例，如下打開devtools的Coverage標簽欄，然后點記錄按鈕，刷新頁面，頁面加載完之后，點擊停止。就會顯示頁面用到和沒用的CSS/JS占比。沒有用到的用紅色表示，用到的用綠色表示：

　　可以看到第二個CSS文件有大部份是沒用到的，JS也有很大的比例沒有用到。在上面中間的窗口會把具體沒使用到的代碼標紅，就能知道具體哪些代碼沒有被用到。可以看到，CSS有一半沒有用到，因為有一些是小屏的響應式CSS，大屏沒用到。另一些是common-chunk提出來的，所以可以考慮把大小屏的CSS分開（但是不適合于內聯Style），如下用媒體查詢去加載不同的CSS：

　　<link rel="stylesheet"href="large.css"media="screen and (min-width:500px)">

　　JS也是因為require了比較大的公有模塊導致的，這些模塊比較大，但是只使用了其中小一部分功能，可考慮把大模塊拆細，但是粒化太細可能會增加復雜度，所以要權衡一下。

　　這些功能可以用Chrome Canary嘗鮮版的使用。

　　03截全屏的功能

　　除了Corverage之外，Chrome 49還新增了截全屏的功能：

　　就不用去裝一個第三方的插件。

　　04debugger

　　可以在代碼里面寫一句debugger，一旦運行到dubugger就會自動卡在那里進入調試模式，使用這個有兩個好處，一個是不用手動去展開文件找到對應的位置，因為現在很多人都用第三方的打包，導致跑的代碼和本地的代碼行數不能保持一致，所以需要去搜索相應地代碼，比較麻煩。另外一個好處是：當代碼是一個很大的循環的時候，并且在特定的情況下代碼會掛，由于要循環好多次，所以有時候不可能在循環里面打個斷點，然后不斷地跳到下一個斷點直到出現問題。所以這時候怎么辦呢？可以用條件結合debugger。如下代碼：

　　var scores = [90,70,58,60, ...];var newScores = [88, 55, 60, ...];for(var i = 0; i < scores.length; i++){ for(var j = 0; j < newScores.length; j++){ if(scores[i] !== newScores[j]){ scores.push(newScores[j]); } }}

　　發生了死循環，怎么定位在哪里出了問題呢？方法一在循環里面打個斷點，一次次執行分析，直到發現問題，方法一有時候挺好用的，可能很快就可以發現問題了。方法二，發生死循環了肯定是i不斷得在變大，但是為什么i不會停止變大，可以加個條件，當達到那個條件的時候進入斷點：

　　if(i > 1000000){debugger}

　　如上面第7行，當i大于1000000時進入斷點，這個時候檢查一下，發現scores已經變成了一個很大的array了：

　　所以可以進一步發現問題。這樣就解決了大循環里面打斷點調試的問題。

　　使用debugger還有一個小技巧——可以解決一個檢查頁面元素的問題。如下圖所示，當hover到那個綠色的標簽時，會出來個詳情框：

　　現在我要檢查這個詳情框，但是我一檢查，鼠標離開了，那個框也消失了，導致檢查不了了，因為觸發了mouseout事件，那怎么辦呢？假設這個框是css的hover控制的，那么可以用控制臺的偽類窗口，在:hover那里打個勾，就有hover的效果：

　　但是這個不是用css的hover實現的，所以沒辦法用這個。這里有一個小技巧，就是用debugger讓頁面卡住了，mouseout事件的響應函數就不會執行了。如下，先在左邊的控制臺點一下進入編輯模式，然后把鼠標挪到左邊的頁面的標簽，讓那個框出來，然后再在控制臺輸入debugger回車，這個時候頁面就卡住了，接著就可以愉快地進行檢查了，如下圖所示：

　　05IOS真機模擬

　　這個雖然和Chrome沒關系，但是也可以提一下，Mac的XCode可以開一個ios系統，操作如下圖所示，然后可以用Mac的Safari接連這個ios里面的Safari進行檢查：

　　如下例子調試iPhone的Safari：

　　上面右圖彈了一個原生的下拉，因為它是真的ios系統，這個的好處就在于不用老是連真機調試，適合于有Mac但是沒有iPhone的同學，缺點是沒辦法和真機100%一樣，例如它不彈鍵盤，它的輸入是用電腦鍵盤的輸入。不過它是100%的ios系統，另外需要裝一個很大的XCode。

　　06用console.trace追蹤函數調用

　　現在遇到了一個問題，就是點擊X按鈕的時候重復發了兩個請求，如下下圖的紅框：

　　當上一次請求還沒完成又要發一個新的請求的時候，代碼里面會把上一次請求abort掉，所以會看到上一個變紅了：

　　但是這樣還是會有問題，所以要看一下究竟是在哪里觸發了兩次請求。由于請求會走一個通用的發請求的接口，所以可以在那里追蹤一下：

　　ajax: function(curPage){ console.trace("search.js ajax"); //other code}

　　然后控制臺就打印了兩次trace：

　　分別點開這兩次的代碼，就會發現，兩次觸發分別是：一次是X的click事件調的搜索，另外一次是map的zoom_changed觸發的搜索，知道了調用的地方就好辦了，就可以做進一步分析，然后去掉其中一個。

　　另外一個看函數調用棧的地方是在右邊的窗口：

　　調用棧最多只打印5個，有時候可能會不太夠。

　　07查看某個函數綁的事件

　　控制臺Elements的下面有個Event Listeners，點最后面那個可以看到和它最相關的事件

　　其次，用好快捷鍵可以事半功倍，常用的快捷鍵：

　　F10 下一步

　　F8 跳到下一個斷點

　　command/ctrl + ; step into進入函數執行

　　shift + command/ctrl + ; step out跳出當前函數

　　一個實例——研究一下鼠標hover的時候它的邊界是怎么畫出來的：

　　首先定位到mouseover事件，因為它必定是mouseover觸發的：

　　一打開發現代碼是壓縮的：

　　壓縮的代碼可以點左下角的大括號，進行美化：

　　然后再用快捷鍵一步步的step over/step into，如果你不用快捷鍵老是一個個去點那個調試的按鈕還是挺麻煩的。如果不小心過了，就重新來一遍。最后會找到在這個函數里面畫的邊界：

　　08Open in Sources Pannel

　　在sources pannel面板如果要查看某個源文件的時候，需要一步步展開文件夾，這樣比較麻煩，而在network面板里面可以用各種篩選，但是在network里面是不能打斷點的，這個時候可以用右鍵，然后點擊Open in Sources Pannel的功能：

　　就會在sources面板打印相應的文件，然后可以在sources里面進行調試了。

　　09模擬斷網做一些出錯處理

　　devtools還支持模擬網絡情況，例如可以模擬斷網的情況，突然掛掉了會怎么樣，然后相應的做一些出錯處理：

　　如上圖出錯的時候給一個提示文案，同時恢復upload按鈕，就可以讓用戶再重新上傳。

　　10研究重繪

　　devtools有一個Renders可以用來研究重繪，如下圖右下角，把面板里面的勾都打上：

　　然后點擊左邊的頁面的菜單按鈕研究重排的情況。右上角黑色的框會顯示當前的幀率。左邊變藍的區域表示需要進行重繪，由于要彈一個蒙層，所以頁面可視區域進行重繪了。同時可以看到當前幀率是59，而且整一個過程幀率基本保持在55以上，因為這個是用transform做的動畫，所以幀率比較高。再來看一個用postion做的動畫：

　　可以看到幀率跌到了45，并且有相當一小段時間幀率是在50以下，所以用postion做的動畫流暢度沒有transform的好。

　　11用timeline看執行時間

　　如下圖所示，可以查看很多有用的信息：

　　這個我在《Effective前端6：避免頁面卡頓》有詳細的介紹。

　　12檢查內存泄漏

　　基本上只要存在一個引用就不會進行GC回收，有些DOM節點沒有append到DOM，但是存在引用指向它，它就是一個分離的DOM結點，這個時候發生了DOM內存泄漏，如下面的代碼：

　　var detached = null;button.on(“click”, function(){ detached = document.(“div”);})

　　由于閉包里面有一個變量指向一個分離的DOM結點，所以創建的那個變量指向的內存空間不會被釋放掉。這個時候可以拍一張內存堆的快照，Chrome會幫你把這些分離DOM結點用黃色標出來。

　　先切到Profile標簽，選中Take Heap Snapshot選項，然后點擊Take Snapshot按鈕：

　　然后就會把當前內存的使用情況顯示出來：

　　在搜索框里搜一下detached，出來的結果里面紅色的表示已經分離且沒有引用，而黃色表示已經分離且有引用，所以重點是看這些黃色的。展開其中一個分析一下，可以看到這個HTMLDivElement有一個ImageShower里的$imgContainers指向它，所以導致它的內存空間不能被釋放。具體看下代碼可以看到這是DOM已經刪了，但是圖片懶惰加載里面沒有清掉引用。所以解決辦法是當刪掉DOM節點時，把那個ImageShower里面的變量置為null，或者把整個實例對象置為null。

　　13查看內存消耗

　　為了查看某個操作的內存消耗情況，可以用Record Allocation的功能記錄某個操作內存的分配情況。

　　點了start按鈕之后，進行一個操作，例如彈一個框，然后點擊停止記錄的圖標，就會出來使用情況的分析，如下圖所示：

　　點開最上面的Object，可以看到這個Object數組開銷了553K的內存（下圖倒數第二列第一行）：

　　展開其中一個Object，可以看到它是一個jQuery對象，每一個消耗了88Kb：

　　而總的內存可以用Chrome的任務管理器查看：

　　可以看到當前頁面消耗了193Mb的內存。所以如果當你覺得頁面的內存比較大的時候，或者重復某個操作之后頁面的內存不斷增大，就可以用這種方法分析一下。

　　14垃圾回收

　　垃圾回收可以在timeline里面查看，如下圖所示：

　　藍線那里JS Heap驟降，說明進行了一次垃圾回收，如果發生得比較頻繁的話，可能會有問題。

　　15查看連接時間

　　如下圖所示：DNS解析花了254ms，建立tcp連接花了1.98s，建立https連接花了1.69s，從建立完連接到接收到第一個字節的數據(TTFB，Time To First Byte)等了4.3s，下載時間花了306ms（基于某次實驗）。

　　另外圖片的優先級會低于CSS/JS資源，并且同一個域最多只能同時加載6個資源，所以會有排隊和等待時間，如下圖所示：

　　本文分析了一些devtools的一些比較好用的功能，結合自己的項目經驗做了些實際的例子說明，希望對大家有幫助。

　　原文：www.renfed.com/2017/05/02/effectiv-chrome-devtools/

　　精選文章

↓↓↓