發(fā)生什么事了？

一個與往常一樣的上午，當(dāng)我沉浸在業(yè)務(wù)需求中不可自拔時，突然被拉入到一個事故大群。一臉懵逼的我還以為和之前的每次線上bug一樣僅僅是個小問題時，殊不知是我簡單了...

看著群里的聊天記錄，瞬間一種不好的預(yù)感涌上心頭。不會是哪個頁面寫了死循環(huán)了吧？

咋了？這是咋了？

死去的頁面突然攻擊我？

因為項目本身過于龐大，且用戶反饋不特定頁面崩潰，這使得問題定位難度較大。

經(jīng)過團(tuán)隊的討論認(rèn)為可能是該用戶的組織架構(gòu)接口數(shù)據(jù)量過大，當(dāng)數(shù)據(jù)到達(dá)頁面后需要經(jīng)過遞歸處理，導(dǎo)致內(nèi)存不足，且通過調(diào)試發(fā)現(xiàn)并非初次調(diào)用該接口就會導(dǎo)致崩潰，而是需要多次調(diào)用才會出現(xiàn)該問題。

而且在調(diào)試的過程中還發(fā)現(xiàn)因數(shù)據(jù)量過大，該接口需要長達(dá) 30s 的時間才能返回。而這么長的時間用戶可能已經(jīng)離開這個頁面了。我們嘗試以這個場景進(jìn)行操作發(fā)現(xiàn)，用戶離開頁面并沒有取消已經(jīng)發(fā)出的請求，當(dāng)該請求響應(yīng)后會導(dǎo)致內(nèi)存占用飆升。

因該接口為項目全局接口，經(jīng)過討論我們決定先修復(fù)這個離開頁面不取消請求的問題，測試能否解決崩潰問題。

陷入僵局

當(dāng)我們在離開頁面時取消未完成的請求后，測試反饋仍然會不定時崩潰，此時的我們有點無從下手了。因為我們發(fā)現(xiàn)問題貌似有點大了。

此時我們已經(jīng)開始懷疑出現(xiàn)了內(nèi)存泄漏，于是我們祭出了 chrome-devtool 使用 Memory 來進(jìn)行內(nèi)存占用分析。

經(jīng)過內(nèi)存分析發(fā)現(xiàn)，內(nèi)存中存在大量的分離元素未能及時回收。我按照內(nèi)存快照的指引開始了漫長的修改。兩天的修改后發(fā)現(xiàn)，雖然修復(fù)了不少的問題，但是仍然不能有效的降低頁面的內(nèi)存占用，每當(dāng)我們跳轉(zhuǎn)新的頁面時某些頁面仍然不能正常釋放。此時我為了高效定位問題，開始使用絕招——刪代碼。

• 將頁面中的組織架構(gòu)樹刪除——內(nèi)存占用沒降下來...

• 將頁面的列表刪除——很棒空頁面果真降下來了

• 將組織架構(gòu)樹加上，列表刪除——內(nèi)存又起來了...

此時的我認(rèn)為組織架構(gòu)樹的寫法有問題，所以花了兩天的時間過了一遍組織架構(gòu)樹的代碼，未發(fā)現(xiàn)有什么異常的地方。

為了確認(rèn)是組織架構(gòu)樹的問題還是頁面列表的問題，我在項目中新建了兩個空白的路由頁面。在這個頁面中單獨(dú)使用這兩個組件，都沒有問題。

問題陷入了僵局...

垂死病中驚坐起

在我們修復(fù)這個問題的期間，另一個用戶也反饋了相同的問題過來，不過用戶說他用的是edge瀏覽器。此時同事說edge好像可以撐的更久一點。??哇，真的嗎？難道和瀏覽器有關(guān)系？

于是我又打開了edge瀏覽器，點開了devtool點開了Memory...哎？這是什么

edge的devtool這么好嗎，專門有獨(dú)立的標(biāo)簽用來查找分離的元素啊，蠻人性化的嘛?？墒沁@和chrome不一樣呀，咋用呢？（戳這里）

它真的好智能，竟然已經(jīng)把所有泄漏的dom按照結(jié)構(gòu)組織好了，這樣就不用我再從一堆內(nèi)存信息中一個個找它們的關(guān)聯(lián)關(guān)系了。

從上圖我發(fā)現(xiàn)原來是有一個全局的tip()方法導(dǎo)致了整個頁面沒能正?；厥?，用戶每進(jìn)一次這個頁面就會在內(nèi)存里多一份這個頁面的dom節(jié)點。而這個頁面又有完整的組織架構(gòu)樹，組織架構(gòu)樹又很大...

查看了tip()方法的源碼發(fā)現(xiàn)，這是一個全局的指令，這個指令每次都會創(chuàng)建一個新的tip對象，而這個tip對象與頁面上的dom節(jié)點關(guān)聯(lián)，且永遠(yuǎn)不會被銷毀。

類似的問題在列表中有個對表格行拖拽排序的功能，使用了第三方包sortablejs而未調(diào)用destory()方法銷毀sortable 實例，進(jìn)而導(dǎo)致表格與頁面也未能正確釋放。

勿以善小而不為

到此，大概的原因已經(jīng)明確了。未及時銷毀的無用對象導(dǎo)致了大面積的內(nèi)存泄漏，疊加用戶的配置較低（8G內(nèi)存，且開啟了很多頁面),導(dǎo)致了頁面的崩潰。

類似以上的問題在本次修復(fù)中還發(fā)現(xiàn)不少，如：

• 公共彈窗組件將傳入的子組件持有，在關(guān)閉彈窗后未能銷毀子組件。
• 全局的EventBus實例未及時調(diào)用$off方法銷毀事件，而事件回調(diào)與頁面又產(chǎn)生關(guān)聯(lián)（如：$refs、$parents)
• 組件接受來自頁面的方法，而該組件未能在頁面離開時銷毀(如在組件內(nèi)將組件的this綁定在window上)，導(dǎo)致整個頁面不能釋放
• 為了在頁面resize時能夠調(diào)節(jié)echarts大小，在window上綁定了resize回調(diào)，離開頁面時為清除resize事件
• 組件實例化時在document上綁定click事件后，銷毀組件時為清除click事件

以上的每一個問題都是小問題，僅僅是因為沒用在beforeDestroy中調(diào)用Element.removeEventListener()或者未調(diào)用destroy()方法。但是會導(dǎo)致很大的后患。

修復(fù)后的頁面已經(jīng)能夠達(dá)到較為正常的內(nèi)存占用了，在此給大家放一張測試同學(xué)提供的修復(fù)前后的內(nèi)存占用對比圖,相較于修復(fù)前的內(nèi)存占用只增不減（峰值4G，然后崩潰）到現(xiàn)在的能及時回收（最復(fù)雜的頁面峰值500M，普通頁面100M以內(nèi)），已經(jīng)有了極大的提升。

修改參考

const handleResizeWindow = () => {
    myChart.resize();
}
window.addEventListener("resize", handleResizeWindow);
this.$once('hook:beforeDestroy', () => {
    myChart.dispose() // 銷毀echart實例
    window.removeEventListener('resize', handleResizeWindow)
})

created () {
    window.removeEventListener('beforeunload', this.closePage)
},
...
beforeDestroy () {
    window.removeEventListener('beforeunload', this.closePage)
}

 mounted() {
     this.$eventBus.$on("eventName", this.handleEvent);
     this.$once('hook:beforeDestroy', () => {
         this.$eventBus.$off('eventName', this.handleEvent)
     })
 }

以上就是JS前端性能優(yōu)化解決內(nèi)存泄漏頁面崩潰的詳細(xì)內(nèi)容，更多關(guān)于JS內(nèi)存泄漏頁面崩潰的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論