轉載於http://www.cnblogs.com/jingwhale/p/4509160.htmljavascript
網易雲課堂筆記css
經常使用的調試工具備Chrome瀏覽器的調試工具,火狐瀏覽器的Firebug插件調試工具,IE的開發人員工具等。它們的功能與使用方法大體類似。Chrome瀏覽器簡潔快速,功能強大這裏主要介紹Chrome瀏覽器的調試工具。html
打開 Google Chrome 瀏覽器,經過下面任何一種方式進入開發人員工具:
-點擊位於瀏覽器用戶界面右上角的「頁面」下拉菜單,「更多工具」→「開發人員工具」。
-右鍵點擊網頁上的任一元素,在彈出菜單中選擇「審查元素」。
-在 Windows操做系統上,使用 Ctrl+Shift+I 快捷鍵打開開發人員工具(或使用 Ctrl+Shift+J 直接進入 JavaScript 控制檯)。 前端
Chrome一共有8個功能子集。以下圖:java
每個圖標點擊後都會打開相應的調試面板,幫助您獲取各類不一樣的信息,如 DOM 樹、資源佔用狀況、頁面相關的腳本等。經過 Ctrl+[ 和 Ctrl+] 鍵,能夠在這些項之間進行切換。每一個模塊及其主要功能爲:git
Element 標籤頁: 用於查看和編輯當前頁面中的 HTML 和 CSS 元素。
Network 標籤頁:用於查看 HTTP 請求的詳細信息,如請求頭、響應頭及返回內容等。
Source 標籤頁:用於查看和調試當前頁面所加載的腳本的源文件。
TimeLine 標籤頁: 用於查看腳本的執行時間、頁面元素渲染時間等信息。
Profiles 標籤頁:用於查看 CPU 執行時間與內存佔用等信息。
Resource 標籤頁:用於查看當前頁面所請求的資源文件,如 HTML,CSS 樣式文件等。
Audits 標籤頁:分析頁面加載的過程,進而提供減小頁面加載時間、提高響應速度的方案,用於優化前端頁面,加速網頁加載速度等。
Console 標籤頁:用於顯示腳本中所輸出的調試信息,或運行測試腳本等。程序員
學習這個章節,最主要的是多動手點點,左擊/右擊,先點看看,進而深刻學習。github
在元素(Elements)面板中,能夠看到整個頁面的 DOM 樹結構和每一個元素的全部屬性(即html和css),同時也能夠實時地修改這些元素及其屬性,並能夠實時看到修改後的效果。web
-點擊,點擊頁面上的元素,顯示選中元素的HTML代碼和樣式;ajax
-編輯HTML:在工具窗口左側是html代碼,可經過雙擊修改現有標籤的屬性值,也可選中html代碼片斷右擊選擇「Edit as HTML」進行html代碼的修改;
-編輯屬性:在工具窗口右側顯示的是被選元素的樣式信息,能夠經過雙擊現有屬性來修改該元素的 style 屬性或應用的某個選擇器中的屬性值,也能夠經過取消勾選的方式去掉一些屬性,同時頁面實時變化。
-添加屬性:鼠標雙擊您所想修改的元素的選擇器的空白部分,便可添加屬性。添加任何屬性都必須以分號結束。你也能夠直接點擊+號,添加新選擇器並進行屬性操做。
-能夠直接在盒模型上更改margin和padding。
-搜索功能:當工具面板得到焦點後,快捷鍵ctrl+f會打開搜索框,鍵入元素關鍵字進行搜索。
-你還能夠對某個元素進行監聽,在JS對元素的屬性或者HTML進行修改的時候,直接觸發斷點,跳轉到對改元素進行修改的JS代碼處:
-拖拽節點, 調整順序。拖拽節點到編輯器:
注:像素大小,能夠經過鼠標的滾輪調整,調整單位1px(百分比調整單位1%);按住ALt,調整單位0.1px;同時按住Shift+ALt,調整單位10px。
總之,把能夠點的都點一遍。
顯示的是所選元素的最終樣式(對應JS中的getComputedStyle()方法),Computed Style中的屬性是隻讀的,不能實時修改,因此主要用來查看元素的最終屬性值。
顯示了綁定到當前元素的事件監聽函數,並且會顯示事件冒泡或捕獲(即可以響應此事件的全部元素)。
右擊標籤,審查元素;出現工具欄-》菜單 Elements,查看右側菜單-》EventListeners,查看元素上綁定了哪些事件:
默認會列出 All Nodes, 這些包括代理綁定在該節點的父/祖父節點上的事件, 由於在在冒泡或捕獲階段會通過該節點
Selected Node Only 只會列出當前節點上綁定的事件
每一個事件會有對應的幾個屬性 handler, isAtribute, lineNumber, listenerBody, sourceName, type, useCapture
-handler是處理函數, 右鍵能夠看到這個函數定義的位置, 通常 js 庫綁定事件會包一層, 因此這裏很難找到對應handler
-isAtribute 代表事件是否經過 html 屬性(相似onClick)形式綁定的
-useCapture 是 addEventListener 的第三個參數, 說明事件是以冒泡仍是捕 順序執行
-右擊handler選擇「Show function definition」能夠進入Sources裏js文件中。
這個後面再細講。
Properties:顯示當前元素的DOM屬性,按照類的繼承層級排列,越靠下層級越高。最上面是一個HTMLDivElement的實例,第二個是HTMLDivElement的類。第三個,是HTMLElement類,HTMLDivElement類繼承自HTMLDivElement類。接着分別是Element類,Node類,和Object類。若是選擇不一樣的節點類型,就會出現不一樣的繼承關係。
這個頗有用,可讓你看到元素具備的方法與屬性,比查API手冊要方便,但要注意某些方法和屬性在IE、FireFox等其餘瀏覽器下面的支持狀況。
請求的每一個資源在Network表格中顯示爲一行,每一個資源都有許多列的內容(如紅色區塊1),不過默認狀況下不是全部列都顯示出來。
Name/Path: 資源名稱以及URL路徑;
Method: HTTP請求方法;
Status/Text: HTTP狀態碼/文字解釋;
Type: 請求資源的MIME類型;
Initiator解釋請求是怎麼發起的,有四種可能的值:
Parser:請求是由頁面的HTML解析時發送的;
Redirect:請求是由頁面重定向發送的;
Script:請求是由script腳本處理髮送的;
Other:請求是由其餘過程發送的,好比頁面裏的link連接點擊,在地址欄輸入URL地址。
Size/Content: Size是響應頭部和響應體結合起來的大小,Content是請求內容解碼後的大小。進一步瞭解能夠看這裏Chrome Dev Tools - 「Size」 vs 「Content」;
Time/Latency: Time是從請求開始到接收到最後一個字節的總時長,Latency是從請求開始到接收到第一個字節的時間;
Timeline: 顯示網絡請求的可視化瀑布流,鼠標懸停在某一個時間線上,能夠顯示整個請求各部分花費的時間。
以上是默認顯示的列,不過咱們能夠在瀑布流的頂部右鍵,這樣就能夠選擇顯示或者隱藏更多的列,好比Cache-Control, Connection, Cookies, Domain等。
咱們能夠按照上面任意一項來給資源請求排序,只須要單擊相應的名字便可。Timeline排序比較複雜,單擊Timeline後,須要選擇根據Start Time、Response Time、End Time、Duration、Latency中的一項來排序。
紅色區塊2中,一共有6個小功能:
Record Network Log: 紅色表示此時正在記錄資源請求信息;
Clear: 清空全部的資源請求信息;
Filter: 過濾資源請求信息;
Use small resource raws: 每一行顯示更少的內容;
Perserve Log: 再次記錄請求的信息時不擦出以前的資源信息;
Disable cache: 不容許緩存的話,全部資源均從新加載。
選擇Filter後,就會出現如紅色區塊3所顯示的過濾條件,當咱們點擊某一內容類型(能夠是Documents, Stylesheets, Images, Scripts, XHR, Fonts, WebSockets, Other)後,只顯示該特定類型的資源。在XHR請求中,能夠在一個請求上右鍵選擇「Replay XHR」來從新運行一個XHR請求。
有時候咱們須要把Network裏面內容傳給別人,這時候能夠在資源請求行的空白處右鍵而後選擇Save as HAR with Content保存爲一個HAR文件。而後能夠在一些第三方工具網站,好比這裏重現網絡請求信息。
選定某一資源後,咱們還能夠Copy as cURL,也就是複製網絡請求做爲curl命令的參數,詳細內容看 Copying requests as cURL commands
此外,咱們還能夠查看網絡請求的請求頭,響應頭,已經返回的內容等信息,以下圖:
資源的詳細內容有如下幾個:
HTTP request and response headers
Resource preview: 可行時進行資源預覽;
HTTP response: 未處理過的資源內容;
Cookie names and values: HTTP請求以及返回中傳輸的全部Cookies;
WebSocket messages: 經過WebSocket發送和接收到的信息;
Resource network timing: 圖形化顯示資源加載過程當中各階段花費的時間。
注:
XPath 是一門在 XML 文檔中查找信息的語言。XPath 用於在 XML 文檔中經過元素和屬性進行導航。好比,
<a href="https://github.com/NUKnightLab/TimelineJS">這裏</a>
這裏a標籤的Xpath爲:/html/body/div[2]/p[1]/a,解讀爲:html裏面body標籤的第二個div標籤的第一個p標籤下的a標籤。
用於查看和調試當前頁面所加載的腳本的源文件。
-經過左邊的內容源,打開對應的 JavaScript 文件,鼠標點擊文件的行號就能夠設置和刪除斷點。添加的每一個斷點都會出如今右側調試區的 Breakpoints 列表中,點擊列表中斷點就會定位到內容區的斷點上。若是你有多個文件、多個斷點的話,利用 Breakpoints 列表中的斷點快速定位很是方便。
-對於每一個已添加的斷點都有兩種狀態:激活和禁用。剛添加的斷點都是激活狀態,禁用狀態就是保留斷點但臨時取消該斷點功能。在 Breakpoints 列表中每一個斷點前面都有一個複選框,取消選中就將禁用該斷點。斷點位置的右鍵菜單中也能夠禁用斷點。也能夠在右側功能區上面按鈕臨時禁用全部已添加的斷點,再點一下恢復原狀態。
-條件斷點:在斷點位置的右鍵菜單中選擇「Edit Breakpoint...」能夠設置觸發斷點的條件,就是寫一個表達式,表達式爲 true 時才觸發斷點。
-不少代碼是壓縮/混淆過的,點擊「{}」能夠格式化代碼,再點一下就取消格式化。。
-在斷點調試時,能夠用鼠標選擇想要查看的變量或表達式,而後右鍵菜單執行「Evaluate in Console」,就能夠看到該表達式的當前的值了。
設置斷點:在 Sources 面板 js 文件行號處設置斷點, 這裏除了常規斷點外, 還有個條件斷點(右鍵 conditional breakpoint), 在設置的條件爲 true 時纔會斷電, 在循環中須要斷點時比較有用.
斷點後能夠查看 堆棧, 變量 信息:
在調用堆棧這裏能夠切換到堆棧中的任何地方從新執行(右鍵restart frame), 若是想查看斷點前的信息時比較有用.
斷點後的變量保存到全局
選中變量, 右鍵 Evalute in console
在 console 中選中輸出的內容, 右鍵 store as global variable
元素上事件斷點:某一事件/某類事件
devtools 能夠查看某一個元素上綁定了哪些事件: Elements > Event Listeners
通常是 dom 結構改變時觸發。 有時候咱們須要監聽某個 DOM 被修改狀況,而不關心是哪行代碼作的修改(也可能有多處都會對其作修改)。那麼咱們能夠直接在 DOM 上設置斷點。
如圖所見,在元素審查的 Elements Panel 中在某個元素上右鍵菜單裏能夠設置三種不一樣狀況的斷點:
子節點修改
自身屬性修改
自身節點被刪除
選中以後,Sources Panel 中右側的 DOM Breakpoints 列表中就會出現該 DOM 斷點。一旦執行到要對該 DOM 作相應修改時,代碼就會在那裏停下來。
對上面元素上事件斷點(mouseover) 後不容易找到業務代碼, 使用 mutation 斷點, 斷點後配合 call stack 就能夠找到業務代碼了, 以下圖
這種狀況使用全局搜索(ctrl + shift + f) 代碼中 css classname 也能找到業務代碼, 而後直接斷點也能夠。
右側調試區有一個 XHR Breakpoints,點擊+ 並輸入 URL 包含的字符串便可監聽該 URL 的 Ajax 請求,輸入內容就至關於 URL 的過濾器。若是什麼都不填,那麼就監聽全部 XHR 請求。一旦 XHR 調用觸發時就會在 request.send() 的地方中斷。
devtools 還能夠對事件發生時斷點, 好比 click 發生時斷點, 這個跟 元素上事件斷點 不一樣, 不會限定在元素上, 只要是事件發生, 而且有 handler 就斷點; 還能夠對 resize, ajax, setTimeout/setInterval 斷點.
下面這個圖是 resize 時中斷, 由於庫都代理了, 還須要在斷點處一步一步跟下去才能走到業務代碼中.
有時候一些很是動態的代碼是以字符串的形式經過 eval() 函數在當前 Javascript context 中建立出來,而不是做爲一個獨立的 js 文件加載的。這樣你在左邊的內容區就找不到這個文件,所以很難調試。其實咱們只要在 eval 建立的代碼末尾添加一行 「//@ sourceURL=name「 就能夠給這段代碼命名(瀏覽器會特殊對待這種特殊形式的註釋),這樣它就會出如今左側的內容區了,就好像你加載了一個指定名字的 js 文件同樣,能夠設置斷點和調試了。下圖中,咱們經過 eval 執行了一段代碼,並利用 sourceURL 將它命名爲 dynamicScript.js ,執行後左側內容區就出現了這個「文件」,而它的內容就是 eval 的中的內容。
還能夠看看這個給動態編譯出來的 CoffeeScript 代碼命名的示例:
var coffee = CoffeeScript.compile(code.value)+ "//@ sourceURL=" + (evalName.value || "Coffeeeeeeee!"); eval(coffee);
實際上,//@ sourceURL 不只僅能夠用在 eval 的代碼中,任何 js 文件、甚至是 Javascript Console 輸入的代碼均可以用,效果同樣!
F8: 繼續執行
F10: step over, 單步執行, 不進入函數
F11: step into, 單步執行, 進入函數
shift + F11: step out, 跳出函數
ctrl + o: 打開文件
ctrl + shit + o: 跳到函數定義位置
ctrl + shift + f: 全部腳本中搜索
用於查看腳本的執行時間、頁面元素渲染時間等信息。
可結合Profiles進行JavaScript性能分析。
在開始作性能優化的時候要設置一個基線,來明確這個頁面的速度到底怎樣。在時間線(timeline)標籤下開始記錄,載入頁面而後中止記錄,這樣就設置了一個基線。(打開chrome開發者工具,點擊「時間線」標籤,而後點擊窗口底部圓形的黑色「記錄」圖標開始記錄)。chrome是智能的,只有頁面開始載入的時候纔會開始記錄。通常多記錄幾回(約三次)而後取了平均值。
這個主要是作性能優化的,包括查看CPU執行時間與內存佔用等。
例述以下:原文地址:http://www.smashingmagazine.com/2012/06/12/javascript-profiling-chrome-developer-tools/。
你的網站正常運轉。如今咱們來讓它運轉的更快。網站的性能由頁面載入速度和代碼執行效率決定。一些服務可讓你的網站載入更快,好比壓縮JS和CDN,可是讓代碼執行的更快你要作的事情。
代碼中很小的改動均可能對性能形成巨大的影響。快速靈活的網站和可怕的「無響應腳本」對話框可能只有幾行代碼的差異。這篇文章告訴你如何經過用Chrome開發者工具(Chrome Developer Tools)找到這幾行關鍵的代碼。
咱們來看一個簡單的「顏色排序器」應用,這個應用展現了一個由各類顏色構成的網格,你能夠拖拽這些顏色進行混合。每個點都是一個div標籤加上一些讓它看起來是圓的的CSS。
頁面載入的很快,但仍是花費了一些時間,在渲染以前還閃了一下。是時候對這個頁面進行性能分析讓它更快了。
在開始作性能優化的時候要設置一個基線,來明確這個頁面的速度到底怎樣。這個基線可讓你知道本身是否作了優化並幫助你權衡利弊。
性能分析器(profiler)是chrome開發者工具的一部分,點擊小扳手下面的工具菜單就能夠打開它。Firebug也有一些性能評測工具,可是webkit內核的瀏覽器(chrome和safari)在對代碼進行性能分析和展現時間線方面是最棒的。Chrome還提供一種很棒的事件跟蹤工具,叫作 speed tracer。
在時間線(timeline)標籤下開始記錄,載入頁面而後中止記錄,這樣就設置了一個基線。(打開chrome開發者工具,點擊「時間線」標籤,而後點擊窗口底部圓形的黑色「記錄」圖標開始記錄)。我記錄了三次而後取了平均值,以防個人電腦在第一次測試的時候運行的很慢。
個人平均基線,也就是從第一個請求到頁面所有渲染結束所花費的時間是1.25秒。這個時間不是太長,可是對於這樣一個小的頁面來講也不算好。我想讓代碼執行的更快,可是我並不知道是什麼讓它慢下來的。性能分析器(profiler)幫助我找到緣由。
時間線(timeline)告訴咱們代碼運行花費的時間,可是並無幫助咱們知道代碼運行的時候發生了什麼。profiler告訴咱們哪些函數的執行佔用了大部分時間。讓咱們切換到chrome開發者工具的「Profiles」標籤頁開始性能測試,這裏一共提供了三種類型的性能測試。
一、javascript cpu 性能測試
顯示javascript佔用了多少CPU二、css選擇器性能測試
顯示處理CSS選擇器佔用的CPU三、堆棧快照
顯示javascript對象的內存佔用狀況
咱們想要javascript代碼執行的更快,因此咱們進行CPU性能測試。咱們開始性能測試,刷新頁面而後中止。
經過性能分析首先知道不少函數在執行。我發現列表最頂端的是decimalToHex和makeColorSorter兩個函數。這兩個函數佔用了CPU13.2%的時間,這是作優化的好地方。
咱們能夠點擊函數調用旁邊的「下一個」箭頭來查看完整的函數調用堆棧。展開後,能夠看到decimalToHex是被makeColorSorter調用的,makeColorSorter是經過$(document).ready調用的。
$(document).ready(function() { makeColorSorter(.05, .05, .05, 0, 2, 4, 128, 127, 121); makeSortable(); });
弄清楚這兩個函數是哪裏調用的,也就弄清楚了讓顏色能夠排序並非最大的性能問題。一般狀況下性能問題都是由多餘的排序操做形成的,可是在個人代碼中相比與排序增長DOM元素花費了更多時間。
我想要讓這些函數執行的更快,可是首先我想要將個人改動區隔開。在頁面載入過程當中會發生不少事情,我不想要這些影響到個人性能分析。
我作了第二個版本,這個版本中「顏色排序器」在我點擊按鈕以後才載入,而不是在document ready的時候載入。這就把文檔載入的過程分離出去,讓我能夠只對顏色分類進行性能測試。調完性能以後我能夠馬上改回去。讓咱們調用新的函數testColorSorter並把它綁定到一個可點擊的按鈕上。
function testColorSorter() { makeColorSorter(.05, .05, .05, 0, 2, 4, 128, 127, 121); makeSortable(); } 1 <button id="clickMe" onclick="testColorSorter();">Click me</button>
在咱們進行性能分析以前改變應用可能致使意外的結果。這個改動看起來很安全,可是我仍是要從新運行性能檢測器來看看我是否是無心中改變了什麼。我會開始一次新的性能分析,點擊應用中的按鈕而後中止。
我首先注意到decimalToHex函數的載入只佔用了4.23%的時間。這是代碼執行花費時間最多的地方。咱們建立一個新的基線來看看這個方案對代碼有多大的優化。
有些事件在我點擊按鈕以前有觸發了,可是我只關注從我點擊鼠標到瀏覽器渲染「顏色排序器」花費的時間。鼠標在390毫秒時點擊,渲染事件在726毫秒處被觸發。726減去390獲得個人基線336毫秒。和第一個基線同樣我重複了3次來取平均值。
這時,我知道如何得到而且獲得了代碼確切的運行時間,咱們已經準備好開始解決問題了。
性能分析器只告訴咱們哪一個函數形成的問題,因此咱們要查看下函數的源碼來了解函數作了些什麼。
function decimalToHex(d) { var hex = Number(d).toString(16); hex = "00".substr(0, 2 - hex.length) + hex; console.log('converting ' + d + ' to ' + hex); return hex; }
「顏色排序器」中的每個顏色點都有一個16進制的色彩值,例如#86F01B和#2345FE.這些值表示一種顏色中紅,綠,藍三原色各自的數值。例如的背景色是#2456FE,表明紅色的值是36,綠色的值是86,藍色的是254,每個數值必須是0到255之間的。
decimalToHex函數把這用RGB值表示的顏色轉化爲頁面中咱們使用的16進制顏色。這個函數十分的簡單,可是我仍是留下了一個能夠去掉的調試代碼console.log在那裏。
decimalToHex 函數還在數字以前加上了補位。這是很重要的一點,由於有些10進制數字對應的是1個16進制數字。好比十進制中的10對應着16進制中的C,可是在CSS中須要一個兩位數。爲了讓這個進制換算更快速,咱們讓這段代碼不是那麼泛化。我知道每一個須要補位的數字長度都爲1,因此咱們能夠這樣重寫這個函數。
function decimalToHex(d) { var hex = Number(d).toString(16); return hex.length === 1 ? '0' + hex : hex; }
第三個版本的「顏色排序器」只有在須要補位的時候才改變字符串,而且不用調用substr函數。有了這個新函數,運行時間是137毫秒。再次對代碼進行性能測試,能夠發現decimalToHex函數只佔用了總時間的%0.04,到了列表的下部。
咱們還能夠發現佔用CPU最多的函數是 jQuery的e.extend.merge。我不知道這個函數的做用,由於代碼是壓縮過的。我可使用開發版本的jQuery,可是我發現這個函數是被makeColorSorter調用的。因此下一步咱們先讓這個函數執行的更快。
「顏色排序器」中的多彩顏色是用過正弦曲線生成的。在光譜中設置一箇中心點,而後以必定的偏移來建立這個曲線。這就把顏色變成了一個「彩虹模型」。咱們還能夠經過改變紅綠藍三原色的使用頻率來改變顏色。
function makeColorSorter(frequency1, frequency2, frequency3, phase1, phase2, phase3, center, width, len) { for (var i = 0; i < len; ++i) { var red = Math.floor(Math.sin(frequency1 * i + phase1) * width + center); var green = Math.floor(Math.sin(frequency2 * i + phase2) * width + center); var blue = Math.floor(Math.sin(frequency3 * i + phase3) * width + center); console.log('red: ' + decimalToHex(red)); console.log('green: ' + decimalToHex(green)); console.log('blue: ' + decimalToHex(blue)); var div = $('<div class="colorBlock"></div>'); div.css('background-color', '#' + decimalToHex(red) + decimalToHex(green) + decimalToHex(blue)); $('#colors').append(div); } }
咱們要去掉console.log函數。這些調用很是的糟糕,由於每次執行都會調用decimalToHex函數,這意味着decimalToHex函數會被多調用2倍的次數。這個函數大幅度的改變了DOM結構。每次循環,都向id爲colors的div中添加一個新的div。這就讓我懷疑這就是e.extend.mergefunction作的事情。用性能分析器作一個小實驗就能夠搞清楚。
我想要一次把全部的div添加進去,而不是在每一個循環中添加一個新的div。建立一個變量來存儲數據,而後在最後一次性添加進去。
function makeColorSorter(frequency1, frequency2, frequency3, phase1, phase2, phase3, center, width, len) { var colors = ""; for (var i = 0; i < len; ++i) { var red = Math.floor(Math.sin(frequency1 * i + phase1) * width + center); var green = Math.floor(Math.sin(frequency2 * i + phase2) * width + center); var blue = Math.floor(Math.sin(frequency3 * i + phase3) * width + center); colors += '<div class="colorBlock" style=" padding: 0px; line-height: 1.5 !important;"> decimalToHex(red) + decimalToHex(green) + decimalToHex(blue) + '"></div>'; } $('#colors').append(colors); }
這個小改動意味着DOM只在添加全部div的時候作一次改變。用時間線進行測試,咱們發現從點擊到渲染花費了31毫秒。這個dom變更,使得第四個版本的運行時間下降了86%。我能夠再次打開性能分析器(profiler),發現e.extend.merge函數佔用了不多的時間,在列表中已經看不到它了。
咱們還能夠徹底移除decimalToHex函數讓代碼更快一點。由於CSS支持RGB顏色,因此咱們不須要把他們轉換到16進制。如今咱們能夠這樣寫makeColorSorter函數。
function makeColorSorter(frequency1, frequency2, frequency3, phase1, phase2, phase3, center, width, len) { var colors = ""; for (var i = 0; i < len; ++i) { var red = Math.floor(Math.sin(frequency1 * i + phase1) * width + center); var green = Math.floor(Math.sin(frequency2 * i + phase2) * width + center); var blue = Math.floor(Math.sin(frequency3 * i + phase3) * width + center); colors += '<div class="colorBlock" style=" padding: 0px; line-height: 1.5 !important;"> red + ',' + green + ',' + blue + ')"></div>'; } $('#colors').append(colors); }
第五個版本的執行只用了26毫秒並且代碼行數從28行減小到18行。
實際工做中的應用要比「顏色排序器」複雜的多,可是作性能分析要遵循一樣的基本原則
一、設置一個基線,這樣你就知道你是從何處開始的。
二、把問題從應用的其餘代碼隔離出來。
三、在一個可控的環境下進行優化,頻繁的使用時間線(timelines)和性能分析器(profiles)
還有一些性能優化的準則
一、從最慢的部分開始,這樣在時間優化上能夠獲得最大的提高。
二、控制環境。若是你換了電腦或者作了任何大的改動,都要設置新的基線。
三、屢次分析以防你電腦的異常致使獲得不正確的結果。
每一個人都想要他的網站更快,你必須開發新的功能,可是新的功能一般會讓網站更慢。因此花費時間來作性能優化是有價值的。
資源面板展現了頁面中的全部資源。
一、資源面板tab;
二、左側欄分類列出頁面資源。如「框架」、「session存儲」,若是前面有箭頭點擊展開還能夠看到更多信息。注意左側欄的大小是能夠調整的;
三、頁面資源包括字體、圖片、js、css和頁面自己。若是頁面中有frame或iframe,展開Frames會看到其對應的frame和iframe。頁面層次結構更清晰
四、數據庫顯示頁面相關的SQL數據庫數據信息;
五、相應IndexedDB 也展現頁面的IndexedDB 信息;
六、以鍵/值 形式列表展現本地存儲的數據;
七、以鍵/值列表顯示session存儲數據;
八、根據域名列舉cookie;
九、顯示經過manifest緩存的資源。包括不少信息,如js庫文件會顯示文件地址、大小和類型;
十、右側用來顯示每一個資源對應的詳細信息。
雖然如今由frame組成的頁面愈來愈少見了,但查看框架內容的方法仍是有必要了解的。下面截圖,是一個由frame組成的頁面。
+每一個frame都相關的資源都在一個文件夾下,一樣點擊展開能夠了解頁面的資源、js、css、圖片文件和字體狀況。點擊選中一個框架,頁面中其對應的區域會高亮顯示。
注:不會列出系統已有的,如「arial」「Helvetica」等,只會列出瀏覽器須要下載安裝的
+保存和查看資源
+cookies
查看某個網站的cookie信息。如http://study.163.com/.
[name]-字段名。如字段名爲「remember_checked」,其值爲1,這可能說明用戶在登錄的時候選擇了記住我;
[value]-字段所對應的值。如「_twitter_sess」所對應的值爲一串加密了的session ID;
[domain]-cookie所在的域。上圖的「.twitter.com」代表其子域也是能夠訪問該cookie的;
[path]-跟域相同,設置有效的路徑。設置爲「/」代表容許所在路徑下均可以訪問cookie;
[expires]-瀏覽器能夠刪除該cookie的日期;
[size]-cookie的大小,單位bytes;
[HTTP]-cookie的訪問容許HTTP協議。這能夠防止跨站js獲取cookie攻擊;
[secure]]-只容許加密鏈接訪問cookie,如HTTPS;
+緩存應用
[resource]-資源的完整路徑。典型的資源包括靜態資源和html文件,manifest文件也屬於其中;
[type]-能夠改變。Manifest文件的文件類型是Manifest,其餘的manifest文件中定義的文件類型爲explicit。Fallback類型的文件是那些須要回調資源文件的回調文件;
[size]-資源文件的大小,單位bytes;
用於優化前端頁面,加速網頁加載速度等。
使用Chrome瀏覽器對頁面性能進行檢測,根據測試的結果進行優化。固然這個結果只是參考,在實際的項目中確定有特殊狀況存在,並不能爲了知足某項測試結果而忽略特定狀況的存在。
點擊Audits而後出現了以下界面,選中重載頁面開始檢測按鈕,而後點擊Run按鈕,以後就是等待結果。
這個檢測結果分爲2類,一個是網絡,一個是網頁性能;
檢測結果不只列出了問題,還定位問題在哪裏,能夠很快入手解決對應的問題。
1)合併JS文件:Combine external JavaScript(總共有29個能夠壓縮的JS文件)
2)There are multiple resources served from same domain. Consider combining them into as few files as possible.一個域名有多個文件,能夠考慮將他們壓縮爲儘量少的文件。
3)
4)啓用gzip壓縮:Enable gzip compression
5)Compressing the following resources with gzip could reduce their transfer size by about two thirds (~715 B).啓用gzip壓縮下降傳輸大小。
6)
7)瀏覽器緩存:Leverage browser caching
8)The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers。資源沒有指定過時時間,瀏覽器可能不會緩存。
網頁性能部分
1)優化樣式和腳本的順序:Optimize the order of styles and scripts (4)
2)把CSS放到head中:Put CSS in the document head (3)
CSS in the document body adversely impacts rendering performance.
3)刪除沒用的CSS:Remove unused CSS rules (44)
44 rules (19%) of CSS not used by the current page.
4)Use normal CSS property names instead of vendor-prefixed ones (3)
應用:本身Css代碼的審覈;下載複製別人代碼,去除無用的Css樣式。可使用FireFox的Dust-Me selectors去除無用的Css樣式。
你們都會用log,但鮮有人很好地利用console.error , console.warn 等將輸出到控制檯的信息進行分類整理。
他們功能區別不大,意義在於將輸出到控制檯的信息進行歸類,或者說讓它們更語義化。
各個所表明的語義以下:
console.log:普通訊息
console.info:提示類信息
console.error:錯誤信息
console.warn:警示信息
當合理使用上述log方法後,能夠很方便地在控制檯選擇查看特定類型的信息。
若是再配合console.group 與console.groupEnd,能夠將這種分類管理的思想發揮到極致。這適合於在開發一個規模很大模塊不少很複雜的Web APP時,將各自的log信息分組到以各自命名空間爲名稱的組裏面。
console.log第一個參數能夠包含一些格式化的指令好比%c,給hello word加了很炫的樣式(全是純CSS用來控制樣式的):
若是還不夠過癮,那我們來log一些圖片:
除此,console.table 更是直接以表格的形式將數據輸出,不能贊得太多!
var data = [{'品名': 'X', '數量': 4}, {'品名': 'Y', '數量': 3}];
console.table(data);
當你想代碼知足某些條件時才輸出信息到控制檯,那麼你大可沒必要寫if或者三元表達式來達到目的,cosole.assert即是這樣場景下一種很好的工具,它會先對傳入的表達式進行斷言,只有表達式爲假時才輸出相應信息到控制檯。
除了條件輸出的場景,還有常見的場景是計數。
當你想統計某段代碼執行了多少次時也大可沒必要本身去寫相關邏輯,內置的console.count能夠很地勝任這樣的任務。
將DOM結點以JavaScript對象的形式輸出到控制檯
而console.log是直接將該DOM結點以DOM樹的結構進行輸出,與在元素審查時看到的結構是一致的。不一樣的展示形式,一樣的優雅,各類體位任君選擇反正就是方便與體貼。
輸出一些調試信息是控制檯最經常使用的功能,固然,它的功能遠不止於此。當作一些性能測試時,一樣能夠在這裏很方便地進行。
好比須要考量一段代碼執行的耗時狀況時,能夠用console.time與 console.timeEnd來作此事。
這裏借用官方文檔的例子:
固然,咱們也能夠選擇本身寫代碼來計時:
當想要查看CPU使用相關的信息時,可使用console.profile配合 console.profileEnd來完成這個需求。
這一功能能夠經過UI界面來完成,Chrome 開發者工具裏面有個tab即是Profile。
與此相似的功能還有console.timeLine配合 console.timeLineEnd,它的做用是開始記錄一段時間軸,一樣能夠經過Chrome開發者工具裏的Timeline 標籤來進行相應操做。
因此在我看來這兩個方法有點雞肋,由於均可以經過操做界面來完成。但至少他提供了一種命令行方式的交互,仍是多了種姿式供選擇吧。
堆棧跟蹤相關的調試可使用console.trace。這個一樣能夠經過UI界面完成。當代碼被打斷點後,能夠在Call Stack面板中查看相關堆棧信息。
上面介紹的都是掛在window.console這個對象下面的方法,統稱爲Console API,接下來的這些方法確切地說應該叫命令,是Chrome內置提供,在控制檯中使用的,他們統稱爲Command Line API。
彷佛美刀老是被程序員及各類編程語言所青睞「你看看PHP代碼就知道PHPer有多愛錢了」,在Chrome的控制檯裏,用處還真是蠻多且方便的。_命令返回最近一次表達式執行的結果,功能跟按向上的方向鍵再回車是同樣的,但它能夠作爲一個變量使用在你接下來的表達式中:
上面的需要領悟其奧義才能使用得當,而0~4則代表了最近5個你選擇過的DOM節點。什麼意思?在頁面右擊選擇審查元素,然後在彈出來的DOM結點樹上面隨便點選,這些被點過的節點會被記錄下來,而45DOMDOM0會返回最近一次點選的DOM結點,以此類推,$1返回的是上上次點選的DOM節點,最多保存了5個,若是不夠5個,則返回undefined。
另外值得一讚的是,Chrome 控制檯中原生支持類jQuery的選擇器,也就是說你能夠用$加上熟悉的css選擇器來選擇DOM節點
(selector)返回的是滿足選擇條件的首個DOM元素。剝去她僞善的外衣,其實selectorDOM(selector)是原生JavaScript document.querySelector() 的封裝。
同時另外一個命令$$(selector)返回的是全部知足選擇條件的元素的一個集合,是對document.querySelectorAll() 的封裝。
經過此命令能夠將在控制檯獲取到的內容複製到剪貼板。
copy(document.body);
這是一對基友。前者返回傳入對象全部屬性名組成的數據,後者返回全部屬性值組成的數組。具體請看下面的例子:
monitor(function),它接收一個函數名做爲參數,好比function a,每次a被執行了,都會在控制檯輸出一條信息,裏面包含了函數的名稱a及執行時所傳入的參數。
而unmonitor(function)即是用來中止這一監聽。
debug一樣也是接收一個函數名做爲參數。當該函數執行時自動斷下來以供調試,相似於在該函數的入口處打了個斷點,能夠經過debugger來作到,同時也能夠經過在Chrome開發者工具裏找到相應源碼而後手動打斷點。
而undebug 則是解除該斷點。
而其餘還有好些命令則讓人沒有說的慾望,由於好些均可以經過Chrome開發者工具的UI界面來操做而且比用在控制檯輸入要方便。
如今不少的網頁都要適配移動端,Chrome的移動設備模式對開發者來講無疑是一個很大的驚喜。
拖動模擬屏幕的標記的兩塊東西能任意調節設備屏幕大小
頂部橙色部分的選項,這個是選擇各類要模擬的設備
下面的是當前設備的顯示屏像素
去掉前面的勾,或者點擊這個刪除的按鈕,網頁將會回到你如今的瀏覽器顯示大小
這個是當前模擬的設備的像素比,例如:iPhone3GS是一、iphone4是二、iPhone6是3....
若是你在操做的時候遇到這個警告,那麼你須要刷新下網頁才能看到實際的顯示效果
這裏的這個Fit是若是你選擇的模擬設備像素的顯示範圍超過了你的瀏覽器框框,那麼就會根據你當前的顯示器高度和寬度自適應的縮放顯示比例。去掉勾選就是實際像素的顯示了。
而後咱們來看看右邊藍色的部分 第一個Network是用來模擬網絡環境的。你能夠模擬各類網絡環境以測試網頁的加載速度,甚至能夠模擬斷網的狀態...
移動設備模式暫時就介紹到這裏。
---------------------------------------------------
就像開始說的,最主要的是本身多打開調試工具多點點,相信用多了就會熟悉。
轉載需註明轉載字樣,標註原做者和原博文地址。