資訊專欄INFORMATION COLUMN
摘要：在此，我們可以使用懶加載方式對其進行優化，僅展示其對應類型的圖，避免了不必要的資源浪費和計算時間。
這篇文章將介紹下實際使用performance對頁面進行優化的過程。總的來說，chrome performance工具讓我們更方便的發現在代碼運行過程中的問題在哪里，便于對一些可能注意不到的問題進行定位、分析和優化。原文首發于個人博客
渲染優化首先，我們對進入整個詳情頁進行分析，整個頁面的結構大致如下，主要包含三個部分：基本信息，可視化圖和時間軸。時間軸內部包含時間軸的詳情信息，包括表格和幾種類型的可視化圖等，內部比較重。如圖所示：
我們點擊錄制，查看進入頁面的性能圖：
優化點1可以看到，渲染當前頁面的耗時將近1.2s，我們看看到底是哪里出現了問題。對渲染部分進行放大，我們發現在渲染時間軸的過程中，大部分時間耗費在了每個時間節點詳情內容的展示上面，但是默認狀態下，他們是進行隱藏的。也就是說，我們進行了N個節點的不必要的渲染，只需把他們干掉就好了。
查看代碼，發現是以下位置導致的，我們進行了一個展開盒子的封裝，類似這樣:
在非展開狀態下，我們依然對內容進行了渲染，只是使用樣式進行了隱藏，但是這樣React仍然會進行虛擬dom的渲染和計算，在這里我們對其進行改造，讓其只在展開時進行渲染，并盡量緩存渲染的結果。修改完成后，我們會發現，Scripting由之前的880+ms變成了670ms減少了200ms左右：
優化點2我們繼續看，會發現頁面初始化時，詳情部分會有大量的Evaluate Script耗時，主要是耗費在告警詳情右側的分類及各分類下的可視圖及詳情引起的。
我們可能會想，這里在初始化時并沒有進行渲染，為什么仍然會耗費時長進行計算呢？繼續追查我發現原因在這里：
在整個詳情組件中，我們對包括http,tcp等所有類型的組件進行了引用，然后根據其類型進行組件的匹配，在各個組件中可能包含了每個類型對應的定義、分類和計算等等等等，不僅增加了加載時間，更延長了初始化時間，顯然我們這么做是不對的。
在此，我們可以使用懶加載方式對其進行優化，僅展示其對應類型的圖，避免了不必要的資源浪費和計算時間。
修改之后，我們再次進行性能測試，發現在進入頁面時，詳情組件的耗費時長由260ms變為不到2ms：
而Scripting由之前的670+ms變成了415ms減少了250ms左右：
至此，進入頁面的耗時已由最開始的1.2s左右變成了現在的0.7s左右。
更新優化我們在點擊時間軸查看詳情時，會進行幾個操作。關閉其他已開啟的詳情內容，展開當前詳情內容，根據當前的類型進行對應類型的詳情內容展示，上邊已經提到過。這個過程會涉及到React的update操作，我們來對這個過程進行一下優化。
優化點1首先我們點擊錄制按鈕，然后點擊展開，并對其進行錄制。我們會發現以下的結果：
點擊展開按鈕，Timeline組件進行了多次重復渲染，顯然這是不應該的，我們來看下是哪里導致的。我們看到整個時間軸組件中，有這樣一段代碼，在時間軸組件中使用connect連接了timeline和alertList兩個數據，其中，alertList數據是詳情內種中對應的告警列表。兩組數據對應的更改都會映射到組件的更新，比如時間軸的展開收起，以及alertList請求，請求成功及失敗等。
按理來說，alertList對應的請求，僅對應到當前展開內容的更新即可。因此，我們對此有幾種修改方案：
時間軸組件中棄用對alertList的引用，以保證alertList不會牽連到時間軸組件整體更新
將時間軸的渲染和詳情渲染進行分離，向其傳遞各自對應的數據，通過PureComponent來控制更新
使用shouldComponentUpdate進行優化
在此我們采用第一種，避免alertList對整個組件的影響。
我們會發現，點開詳情后，整個timeLine只進行了一次大更新，詳情的更新只在展開的組件中進行。
優化點2我們會發現，在對某一個時間點進行展開時，整個list列表的節點都進行了更新，如下圖所示。顯然這樣的性能耗費是及其大且不重要的。假如列表的內容很多，那極有可能造成大量的更新導致頁面卡死。
因為其他的list列表節點都引用了alertList這個prop, 當其進行改變時，所有的節點都會進行更新，所以我們需要使用shouldComponentUpdate手動對其進行優化:
// 當開關狀態變化時，才從新渲染，否則不需要
shouldComponentUpdate (nextProps, nextState) {
const opened = _.get(this.props, "open")
const willOpen = _.get(nextProps, "open")
if (opened === willOpen && !willOpen) {
return false
} else {
// 類似pureComponent進行淺比較
return !_.isEqual(this.props, nextProps) || !_.isEqual(this.state, nextState)
}
}
再次進行錄制，我們發現只要當前Item進行了更新，整個Timeline更新時間縮短到不到40ms，極大的增加了體驗。
其他優化過程與上面類似，不再贅述。
總結通過配合performance工具進行一步步優化，整個頁面的渲染和更新性能有了極大的提升，我們也借此知道了在平時書寫代碼過程中需要注意的問題。我們簡單的做一下總結：
避免非展示狀態的不必要的渲染
必要時，手動進行懶加載以避免大型模塊對頁面進行營銷，避免加載不必要的模塊
保證展示組件props的純凈性，避免因其他props的更改導致組件進行更新
必要時，可使用shouldComponent進行手動優化
平時可通過PureComponent來避免不必要的組件更新
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/98232.html
摘要：前言淘寶新勢力周春上新是命運石鏈路鏈路第一次承接級大促，面對級大促內容豐富且復雜的頁面需求，鏈路遇到了一些性能問題，在未進行性能優化之前，搭建出來的頁面，業務方普遍反饋頁面卡頓嚴重，無法滑動。 前言 淘寶新勢力周（春上新）是命運石kimi鏈路（H5鏈路）第一次承接S級大促，面對S級大促內容豐富且復雜的頁面需求，kimi鏈路遇到了一些性能問題，在未進行性能優化之前，搭建出來的頁面，業務方...
摘要：需要注意的一點是，面板下的功能，是對于細節中的細節進行的優化。我們可以很清晰明了得分析按照活動，目錄，域，子域，和進行分組的前端性能。個人理解的話，前者類似事件冒泡，后者類似事件捕獲。同學在點我達，他們正在籌劃改組成大前端團隊。 對Chrome控制臺有一定的了解的朋友都在知道，Network面板會包括很多網絡請求方面的東西，包括Http相關的Request信息，Response信息...
摘要：出現紅幀表示頁面已經超負荷，會出現卡頓，響應緩慢等現象。因此當滑動周日歷時已經不會有紅幀發生了。我的目的是每一次遞歸會調用一次與但是這樣寫只會在遞歸結束時調用一次因此修改如下這樣優化之后，發現內存占用下降一些，但是紅幀仍然存在。 性能優化可以說是衡量一個前端程序員react使用水平的重要標準。 在學習react之初的時候，由于對react不夠了解，寫的項目雖然功能都實現了，但是性能優化...
摘要：分析每一秒的幀是用來分析動畫的一個主要性能指標。軸代表了調用棧。在事件長條的右上角出，如果出現了紅色小三角，說明這個事件是存在問題的，需要特別注意。雙擊這個帶有紅色小三角的的事件。 運行時性能表現（runtime performance）指的是當你的頁面在瀏覽器運行時的性能表現，而不是在下載頁面的時候的表現。這篇指南將會告訴你怎么用Chrome DevTools Performance...
閱讀 1155·2021-10-15 09:39
閱讀 3053·2021-09-10 10:50
閱讀 3455·2019-08-30 15:53
閱讀 1878·2019-08-30 15:52
閱讀 2565·2019-08-29 15:31
閱讀 1978·2019-08-26 13:43
閱讀 2594·2019-08-26 13:37
閱讀 1445·2019-08-23 18:31
