chrome調試

chrome 瀏覽器輸入: chrome://net-internals/#events

  隨着Web應用的成熟以及HTML5技術的普遍應用，Web開發已經不只僅是DOM框架，或者DOM只佔了很小的比例，隨着邏輯框架的日益複雜和渲染技術的多樣化，從早期的腳本模擬動畫，再到後來的SVG，VML再到現在的canvas和webgl技術，JavaScript已經成爲Web開發的利器，無處不在如影隨形。JS能夠處理CSS和DOM元素，也能夠實現網絡傳輸，也負責邏輯框架和功能實現，在HTML5中能夠實現Canvas或WebGL的圖形圖像渲染。

       但這也帶來了一個問題，JS須要處理各類細節，而目前帶寬和硬件性能的提高，用戶體驗的要求也不斷提升，如何更好的調試程序，找到性能的瓶頸和性能分析，以及對JS混淆代碼的閱讀，都是JS程序員須要掌握的地方，所謂工欲善其事必先利其器，如何高效調試已是JS程序員的基本功。

       本人主要從事地圖GIS行業，下面以此爲背景，分享關於Chrome調試的一些經驗，介紹一下Chrome瀏覽器調試的一些有效工具。

圖1

       如圖，以Nokia Here地圖爲例，F12快捷鍵打開調試界面，對於常常調試的開發人員來講，調試界面過小很是便使用，這裏能夠左鍵長摁 ，選擇下面的UI方式，特別是雙屏的開發人員很是的方便，這也算一個小技巧和你們推廣一下。

圖2

       如上是調試菜單的截圖，Elements主要是HTML的DOM信息，Network主要監聽網絡請求，Sources主要用於源碼調試，Timeline和Profiles主要是對性能，內存等的分析，也是很是好用的工具，而Console則是輸出日誌窗口，在此很少說。Resource主要是本地存儲以及一些session，cookie信息等，我用的並非太多，而Audits我歷來沒用過，搜索了一下主要是優化前端網頁加載速度的，好比冗餘的css等。

Elements

圖3

       如圖是DOM調試界面，主體是HTML要素，能夠經過放大鏡圖片來實現UI界面的定位，同時右側是對應的CSS風格信息，這裏咱們能夠動態的進行修改和添刪，並實時更新，方便咱們對DOM元素的調試,我主要從事地圖研發，因此比較關係地圖Tile是image方式仍是canvas或webgl渲染，經過放大鏡點擊，不停的刪除上層的節點，直到找到我關注的要素，要麼是image標籤，要麼是canvas，WebGL則有特有的工具來查看便可。

Network

       Network窗口是比較重要的一個，當咱們調試源碼等操做時，我主要是從事地圖相關的，因此很關心url的格式以及傳輸的一些細節，因此這個是使用很頻繁的一項。以下圖：

圖4      

        這個是我訪問諾基亞HereMap 3D的一個Network界面，基礎的你們應該試一下都沒問題，我這裏說一下我最經常使用也以爲頗有用的幾個功能。

       首先就是Filter，好比我比較關心諾基亞三維模型數據的傳輸，就寫入n3m（Nokia 3D Model）,則只會篩選出N3M格式的內容。另外這個overview是新版本的功能，我以爲很是用價值，能夠看到你的請求隊列的整體狀況，能夠對比你的請求隊列在某一時刻的具體下載，用來分析你的下載調度是否合理，好比這裏同一時間下載數超過了6，Chrome中TCP最大爲6，這裏諾基亞用了多個數據服務器，因此增大了併發量，提升下載速度，天然用戶體驗也就牛逼。

       另外就是裏面藍綠色的條框，能夠統計單個請求的詳細狀況，以下圖，很簡單就能夠知道你的請求，等待，阻塞和下載時間的一個狀況。

圖5

       另外點擊每個隊列，會有具體的請求和response信息，以下：

圖6

       裏面的信息量也很大，好比這裏用到了gzip壓縮，有無chunk等。這些對於優化服務端，分析優秀的網站都頗有價值，相信你能學到不少別人優化性能的東西。

圖7

       這裏，若是鼠標放到腳本中，會顯示調用該請求的隊列，雖然多數都爲混淆，但大體你也能瞭解腳本的一個邏輯，算是爲調試遠嗎開了一個頭。

       另外，在網絡請求中，有時候會發生請求失敗或者阻塞，緣由不太容易查找，能夠在chrome://net-internals/#events中搜索有問題的url，也能夠分析請求的詳細過程，如圖，能夠追蹤整個請求過程的細節，進行分析。

圖8

Source

       下面終於到了源碼調試了，這個我就很少說了，調試快捷鍵，變量查看這些都是程序員的基本功。只說一點：

圖9

       如上圖，通常代碼都是混淆的，沒法調試，點擊紅色框框，看看，有沒有奇蹟，源碼format了，能夠調試了噻~，另外對於斷點的設置，好比XHR方式，能夠針對你的請求信息進行設置，也很是的使用。

Timeline&Profiles&Audits

       我的經驗，這個用到的狀況並很少,但若是你html5的部分比較多，對渲染性能，內存優化有較高要求，這也是一個利器。好比諾基亞是WebGL來渲染三維地球和城市模型，瀏覽一段後，記錄的效果以下：

圖10     

       能夠看到渲染效率很是不錯，基本都在60幀的範圍內，對於JS內存的管理也不錯，基本比較穩定，不會出現突變的釋放和增長

圖11

       這個是我本身的一個WebGL程序，能夠看到內存上面問題也不大，使用的也很少，但渲染效率不高，都在30幀這個範圍內，時間主要在js腳本上，說明我代碼邏輯過於複雜。

       下面是Profiles

圖12

       能夠看到具體腳本里面的時間花費，瞭解你的性能瓶頸，由於公司的緣由，我不太好貼個人程序的統計，經過這個能夠調試你不太容易發現的性能瓶頸，好比一個簡單的if判斷或xml的parser，或者一塊內存的申請，由於比較頻繁，雖然簡單也會致使性能的急劇降低，並且就只有簡單幾句話很難發現，因此經過這個很是便利的瞭解你的瓶頸。

圖13

       如圖，是Audits裏面給出的優化建議，好比文件緩存，壓縮等的建議，也是在傳輸，資源佔用裏面的一些統計，方便咱們更好的認識本身代碼的瓶頸和改進意見。固然再好的工具也是要有人來分析，才能發揮其價值。

總結

       Chrome的瀏覽器調試功能很強大，體現了Google的工程師文化，我面試常常會問兩個問題：你用什麼瀏覽器和搜索引擎，雖然不會影響面試結果，但對我來講，是我很喜歡的一個問題。另外，隨着HTML5的到來，Web端渲染要求的提升，以往在C/S下的效果均可以在Web端實現，並且無插件跨平臺，是之後一個巨大的發展點，對JS的要求也變高，致使JS的代碼愈來愈複雜，愈來愈面向對象，而JS自己語言的限制和性能瓶頸，垃圾回收反而成了一個陷阱（畢竟各個瀏覽器處理方式不同），種種相似問題以及服務端的優化，而JS已經不僅僅是效果的追求，對性能的優化反而要求更好也更爲重要，對前端的調試技能也變高，這也是Chrome用起來駕輕就熟的地方，但願分享後，你們有什麼好的工具和建議，也都多多分享，to share is to gain~