摘要：在此，我們可以使用懶加載方式對(duì)其進(jìn)行優(yōu)化，僅展示其對(duì)應(yīng)類型的圖，避免了不必要的資源浪費(fèi)和計(jì)算時(shí)間。

這篇文章將介紹下實(shí)際使用performance對(duì)頁面進(jìn)行優(yōu)化的過程?？偟膩碚f，chrome performance工具讓我們更方便的發(fā)現(xiàn)在代碼運(yùn)行過程中的問題在哪里，便于對(duì)一些可能注意不到的問題進(jìn)行定位、分析和優(yōu)化。原文首發(fā)于個(gè)人博客

首先，我們對(duì)進(jìn)入整個(gè)詳情頁進(jìn)行分析，整個(gè)頁面的結(jié)構(gòu)大致如下，主要包含三個(gè)部分：基本信息，可視化圖和時(shí)間軸。時(shí)間軸內(nèi)部包含時(shí)間軸的詳情信息，包括表格和幾種類型的可視化圖等，內(nèi)部比較重。如圖所示：

我們點(diǎn)擊錄制，查看進(jìn)入頁面的性能圖：

可以看到，渲染當(dāng)前頁面的耗時(shí)將近1.2s，我們看看到底是哪里出現(xiàn)了問題。對(duì)渲染部分進(jìn)行放大，我們發(fā)現(xiàn)在渲染時(shí)間軸的過程中，大部分時(shí)間耗費(fèi)在了每個(gè)時(shí)間節(jié)點(diǎn)詳情內(nèi)容的展示上面，但是默認(rèn)狀態(tài)下，他們是進(jìn)行隱藏的。也就是說，我們進(jìn)行了N個(gè)節(jié)點(diǎn)的不必要的渲染，只需把他們干掉就好了。

查看代碼，發(fā)現(xiàn)是以下位置導(dǎo)致的，我們進(jìn)行了一個(gè)展開盒子的封裝，類似這樣:

在非展開狀態(tài)下，我們依然對(duì)內(nèi)容進(jìn)行了渲染，只是使用樣式進(jìn)行了隱藏，但是這樣React仍然會(huì)進(jìn)行虛擬dom的渲染和計(jì)算，在這里我們對(duì)其進(jìn)行改造，讓其只在展開時(shí)進(jìn)行渲染，并盡量緩存渲染的結(jié)果。修改完成后，我們會(huì)發(fā)現(xiàn)，Scripting由之前的880+ms變成了670ms減少了200ms左右：

我們繼續(xù)看，會(huì)發(fā)現(xiàn)頁面初始化時(shí)，詳情部分會(huì)有大量的Evaluate Script耗時(shí)，主要是耗費(fèi)在告警詳情右側(cè)的分類及各分類下的可視圖及詳情引起的。

我們可能會(huì)想，這里在初始化時(shí)并沒有進(jìn)行渲染，為什么仍然會(huì)耗費(fèi)時(shí)長(zhǎng)進(jìn)行計(jì)算呢？繼續(xù)追查我發(fā)現(xiàn)原因在這里：

在整個(gè)詳情組件中，我們對(duì)包括http,tcp等所有類型的組件進(jìn)行了引用，然后根據(jù)其類型進(jìn)行組件的匹配，在各個(gè)組件中可能包含了每個(gè)類型對(duì)應(yīng)的定義、分類和計(jì)算等等等等，不僅增加了加載時(shí)間，更延長(zhǎng)了初始化時(shí)間，顯然我們這么做是不對(duì)的。

在此，我們可以使用懶加載方式對(duì)其進(jìn)行優(yōu)化，僅展示其對(duì)應(yīng)類型的圖，避免了不必要的資源浪費(fèi)和計(jì)算時(shí)間。

修改之后，我們?cè)俅芜M(jìn)行性能測(cè)試，發(fā)現(xiàn)在進(jìn)入頁面時(shí)，詳情組件的耗費(fèi)時(shí)長(zhǎng)由260ms變?yōu)椴坏?ms：

而Scripting由之前的670+ms變成了415ms減少了250ms左右：

至此，進(jìn)入頁面的耗時(shí)已由最開始的1.2s左右變成了現(xiàn)在的0.7s左右。

我們?cè)邳c(diǎn)擊時(shí)間軸查看詳情時(shí)，會(huì)進(jìn)行幾個(gè)操作。關(guān)閉其他已開啟的詳情內(nèi)容，展開當(dāng)前詳情內(nèi)容，根據(jù)當(dāng)前的類型進(jìn)行對(duì)應(yīng)類型的詳情內(nèi)容展示，上邊已經(jīng)提到過。這個(gè)過程會(huì)涉及到React的update操作，我們來對(duì)這個(gè)過程進(jìn)行一下優(yōu)化。

首先我們點(diǎn)擊錄制按鈕，然后點(diǎn)擊展開，并對(duì)其進(jìn)行錄制。我們會(huì)發(fā)現(xiàn)以下的結(jié)果：

點(diǎn)擊展開按鈕，Timeline組件進(jìn)行了多次重復(fù)渲染，顯然這是不應(yīng)該的，我們來看下是哪里導(dǎo)致的。我們看到整個(gè)時(shí)間軸組件中，有這樣一段代碼，在時(shí)間軸組件中使用connect連接了timeline和alertList兩個(gè)數(shù)據(jù)，其中，alertList數(shù)據(jù)是詳情內(nèi)種中對(duì)應(yīng)的告警列表。兩組數(shù)據(jù)對(duì)應(yīng)的更改都會(huì)映射到組件的更新，比如時(shí)間軸的展開收起，以及alertList請(qǐng)求，請(qǐng)求成功及失敗等。

按理來說，alertList對(duì)應(yīng)的請(qǐng)求，僅對(duì)應(yīng)到當(dāng)前展開內(nèi)容的更新即可。因此，我們對(duì)此有幾種修改方案：

時(shí)間軸組件中棄用對(duì)alertList的引用，以保證alertList不會(huì)牽連到時(shí)間軸組件整體更新

將時(shí)間軸的渲染和詳情渲染進(jìn)行分離，向其傳遞各自對(duì)應(yīng)的數(shù)據(jù)，通過PureComponent來控制更新

使用shouldComponentUpdate進(jìn)行優(yōu)化

在此我們采用第一種，避免alertList對(duì)整個(gè)組件的影響。

我們會(huì)發(fā)現(xiàn)，點(diǎn)開詳情后，整個(gè)timeLine只進(jìn)行了一次大更新，詳情的更新只在展開的組件中進(jìn)行。

我們會(huì)發(fā)現(xiàn)，在對(duì)某一個(gè)時(shí)間點(diǎn)進(jìn)行展開時(shí)，整個(gè)list列表的節(jié)點(diǎn)都進(jìn)行了更新，如下圖所示。顯然這樣的性能耗費(fèi)是及其大且不重要的。假如列表的內(nèi)容很多，那極有可能造成大量的更新導(dǎo)致頁面卡死。

因?yàn)槠渌膌ist列表節(jié)點(diǎn)都引用了alertList這個(gè)prop, 當(dāng)其進(jìn)行改變時(shí)，所有的節(jié)點(diǎn)都會(huì)進(jìn)行更新，所以我們需要使用shouldComponentUpdate手動(dòng)對(duì)其進(jìn)行優(yōu)化:

// 當(dāng)開關(guān)狀態(tài)變化時(shí)，才從新渲染，否則不需要
shouldComponentUpdate (nextProps, nextState) {
  const opened = _.get(this.props, "open")
  const willOpen = _.get(nextProps, "open")
  if (opened === willOpen && !willOpen) {
    return false
  } else {
    // 類似pureComponent進(jìn)行淺比較
    return !_.isEqual(this.props, nextProps) || !_.isEqual(this.state, nextState)
  }
}

再次進(jìn)行錄制，我們發(fā)現(xiàn)只要當(dāng)前Item進(jìn)行了更新，整個(gè)Timeline更新時(shí)間縮短到不到40ms，極大的增加了體驗(yàn)。

其他優(yōu)化過程與上面類似，不再贅述。

通過配合performance工具進(jìn)行一步步優(yōu)化，整個(gè)頁面的渲染和更新性能有了極大的提升，我們也借此知道了在平時(shí)書寫代碼過程中需要注意的問題。我們簡(jiǎn)單的做一下總結(jié)：

避免非展示狀態(tài)的不必要的渲染

必要時(shí)，手動(dòng)進(jìn)行懶加載以避免大型模塊對(duì)頁面進(jìn)行營(yíng)銷，避免加載不必要的模塊

保證展示組件props的純凈性，避免因其他props的更改導(dǎo)致組件進(jìn)行更新

必要時(shí)，可使用shouldComponent進(jìn)行手動(dòng)優(yōu)化

平時(shí)可通過PureComponent來避免不必要的組件更新