石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經(jīng)常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結(jié)合在一起的產(chǎn)品，通常這樣的詞是貶義詞，但如果真的是產(chǎn)品縫合的好、縫合的實用的話，那它就成了中性詞，今
對于前端的性能優(yōu)化，優(yōu)化手段其實是非常多的，但是不能盲目的進行優(yōu)化，一定要先分析出項目的性能瓶頸，否則只會做無用功。那么如何才能更好的分析出項目的瓶頸呢？其實最關(guān)鍵的就是要分析頁面的整個加載過程，找出有問題的地方再進行優(yōu)化。使用谷歌瀏覽器自帶的 Performance 工具可以幫我們解決這個問題，下面通過一個例子來進行分析優(yōu)化！
在優(yōu)化之前，我們先要了解一些知識，比如瀏覽器的渲染幀、Performance 工具的使用，這樣才有助于更好地理解優(yōu)化的過程！
對于渲染，我們首先需要了解一個概念：設(shè)備刷新率。設(shè)備刷新率是設(shè)備屏幕渲染的頻率，通俗一點就是，把屏幕當作墻，設(shè)備刷新率就是多久重新粉刷一次墻面。基本我們平常接觸的設(shè)備，如手機、電腦，它們的默認刷新頻率都是 60FPS，也就是屏幕在 1s 內(nèi)渲染 60次，約 16.7ms 渲染一次屏幕。這就意味著，我們的瀏覽器最佳的渲染性能就是所有的操作在一幀 16.7ms 內(nèi)完成，能否做到一幀內(nèi)完成直接決定著渲染性，影響用戶交互。
瀏覽器的 fps 指瀏覽器每一秒的幀數(shù)，fps 越大，每秒的畫面就越多，瀏覽器的顯示就越流暢。
圖片
標準渲染幀：在一個標準幀渲染時間 16.7ms之內(nèi)，瀏覽器需要完成 Main 線程的操作，并 commit 給 Compositor 進程
圖片
丟幀：主線程里操作太多，耗時長，commit 的時間被推遲，瀏覽器來不及將頁面 draw 到屏幕，這就丟失了一幀
圖片
在瀏覽器的一個渲染幀（16.7ms）里，會存在一段時間，叫做空閑時間（idle period），如果完成各種任務(wù)的執(zhí)行以及頁面渲染的工作等的時間少于 16.7 ms，那么這一幀就會存在空閑時間，可以把一些耗時操作拆分開來，然后在每一幀的空閑時間中去執(zhí)行。
圖片
所謂的頁面卡頓、首屏加載慢，根本原因都是執(zhí)行長任務(wù)，使得頁面的渲染時機推后，在每一幀里得不到渲染，從而造成用戶的不好體驗。要想解決用戶體驗差的問題，那么就需要知道瀏覽器渲染過程中的每一幀都干了些啥任務(wù)，是啥原因?qū)е落秩緯r機推后，這個時候我們就需要借助瀏覽器性能檢測工具 Performance 來進行分析，然后再做針對性的優(yōu)化，下面我們來了解下該工具的具體使用。
圖片
簡單的使用教程：
在 Chrome 瀏覽器中，按下 F12 鍵或右鍵點擊頁面并選擇 "檢查"，打開開發(fā)者工具面板。
在開發(fā)者工具中，切換到 "Performance"（性能）選項卡，你會看到一個記錄性能數(shù)據(jù)的界面。
圖片
點擊頁面頂部的 "Record"（錄制）按鈕，開始記錄性能數(shù)據(jù)，刷新頁面或執(zhí)行你想要分析的操作。
圖片
在你完成操作后，點擊 "Stop"（停止）按鈕，停止記錄性能數(shù)據(jù)。此時，會看到一個包含了各種性能數(shù)據(jù)的時間軸圖表。
圖片
時間軸圖表將顯示頁面加載期間的各種事件，如 JavaScript 執(zhí)行、網(wǎng)絡(luò)請求、繪制等。可以縮放和選擇特定時間段來深入分析。
圖片
谷歌官方提供的一個 Demo：googlechrome.github.io/devtools-sa…[2]
左側(cè)有一些按鈕，點擊 Stop 小球停止運動，點擊 Add、Subtract 可以控制小球數(shù)量的增減，比較有意思的一個點是，當小球的數(shù)量越來越多，頁面會越來越卡頓，如果點擊 Optimize（優(yōu)化），那么頁面就會恢復正常。
當小球數(shù)量很多時，頁面會非常卡頓：
圖片
接下來借助 Performance 來分析頁面卡頓的原因：
圖片
錄制大概 4 秒鐘，可以看到該頁面的性能確實存在很大的問題，我們首先分析這張圖里面的一些內(nèi)容：
總覽區(qū)： 可以看到每個階段的具體耗時，這里很明顯是渲染占據(jù)了 90% 的時間，而 JS 腳本的執(zhí)行、頁面繪制并不耗時，現(xiàn)在已經(jīng)可以定位到是渲染存在問題。
圖片
幀： 綠色代表該幀正常，黃色表示丟幀
圖片
主線程：
圖片
以其中的一個 Task 為例：標紅代表該任務(wù)是長任務(wù)（一般認為超過 50ms 的任務(wù)是長任務(wù)），往下是該任務(wù)具體的細節(jié)，比如這個 Task 里主要執(zhí)行了 Animation Frame Fired 方法，它里面調(diào)用了 Function Call，F(xiàn)unction Call 里面調(diào)用了 app.update 的方法，一層一層往下調(diào)用執(zhí)行，然后在 app.update 下面我們可以看到很多紫色的線條，紫色代表回流重繪。
圖片
現(xiàn)在可以初步下結(jié)論：頻繁的回流重繪導致頁面卡頓，后面還要再進行分析才能確定。
接下來點擊其中的一個任務(wù)，觀察 Call Tree，每個方法的執(zhí)行時間都能看到，以及時間的占比
圖片
我們的分析目標主要是尋找花費時間長的任務(wù)，依次點開，可以發(fā)現(xiàn) 90% 的時間是花費在 Layout，點擊右側(cè)進入源碼：
圖片
圖片
分析這段代碼我們已經(jīng)可以知道問題出在哪里了，讀取offsetTop會觸發(fā)回流重繪，這里用了個 for 循環(huán)，所以當小球的數(shù)量越來越多的時候，不斷的讀取 offsetTop 屬性，導致頻繁的觸發(fā)回流重繪，最終頁面卡頓。
我們需要解答兩個問題：
計算復雜度： 回流涉及到重新計算元素的位置和幾何屬性，這可能需要遍歷整個DOM樹，并重新計算樣式。這個計算過程比較復雜，尤其是在大型、復雜的頁面上。
渲染的停頓： 當發(fā)生回流時，瀏覽器可能需要停止渲染，重新計算布局，然后再重新繪制，這可能導致頁面的停頓或閃爍。
頻繁觸發(fā)： 如果在用戶與頁面交互的過程中頻繁地觸發(fā)回流和重繪，可能會導致性能問題。比如，在滾動頁面時，如果頻繁改變元素的樣式，可能會引起多次回流和重繪，從而影響流暢度。
也就是說，頻繁的回流重繪可以看做是耗時嚴重的任務(wù)，阻礙了頁面的渲染，從而導致卡頓！
這與瀏覽器的優(yōu)化機制有關(guān)：由于每次回流與重繪都會帶來額外的計算消耗，為了優(yōu)化這個過程，大多數(shù)瀏覽器采用了隊列化修改并批量執(zhí)行的策略。瀏覽器會將修改操作添加到隊列中，直至一定時間段過去或操作達到閾值時，才會清空隊列。
然而，當需要獲取布局信息時，瀏覽器會強制刷新隊列。這意味著，當你讀取元素的布局信息如 offsetTop、offsetLeft 等時，需要返回最新的布局信息，因此瀏覽器不得不清空隊列，觸發(fā)回流和重繪操作以返回正確的值。
那么如何進行優(yōu)化呢？知道是 offsetTop 的問題后，不用這個屬性就行了，我們看下這個例子的處理方式：
圖片
使用 style.top 屬性取代 offsetTop 即可，當然這兩個屬性也有一定的區(qū)別，這里不再展開，這樣就能完美的解決頁面卡頓的問題！
總的來說，其實優(yōu)化方法很簡單，最關(guān)鍵的是要找出頁面的性能瓶頸，到底是哪里影響了性能。因此，前端開發(fā)者想要提升自己的能力、提升自己對性能優(yōu)化的理解，就必須具備熟悉瀏覽器的渲染原理、使用 Performance 工具、分析項目的性能瓶頸等方面的能力！
本文鏈接：http://www.tebozhan.com/showinfo-26-71931-0.html性能優(yōu)化例子：使用Performance工具分析性能瓶頸，解決頁面卡頓！
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號