JS前端效能優化解決記憶體漏失頁面崩潰

2022-07-19 22:00:20

發生什麼事了？

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

看著群裡的聊天記錄，瞬間一種不好的預感湧上心頭。不會是哪個頁面寫了死迴圈了吧？

因為專案本身過於龐大，且使用者反饋不特定頁面崩潰，這使得問題定位難度較大。

經過團隊的討論認為可能是該使用者的組織架構介面資料量過大，當資料到達頁面後需要經過遞迴處理，導致記憶體不足，且通過偵錯發現並非初次呼叫該介面就會導致崩潰，而是需要多次呼叫才會出現該問題。

而且在偵錯的過程中還發現因資料量過大，該介面需要長達 30s 的時間才能返回。而這麼長的時間使用者可能已經離開這個頁面了。我們嘗試以這個場景進行操作發現，使用者離開頁面並沒有取消已經發出的請求，當該請求響應後會導致記憶體佔用飆升。

因該介面為專案全域性介面，經過討論我們決定先修復這個離開頁面不取消請求的問題，測試能否解決崩潰問題。

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

此時我們已經開始懷疑出現了記憶體漏失，於是我們祭出了 chrome-devtool 使用 Memory 來進行記憶體佔用分析。

經過記憶體分析發現，記憶體中存在大量的分離元素未能及時回收。我按照記憶體快照的指引開始了漫長的修改。兩天的修改後發現，雖然修復了不少的問題，但是仍然不能有效的降低頁面的記憶體佔用，每當我們跳轉新的頁面時某些頁面仍然不能正常釋放。此時我為了高效定位問題，開始使用絕招——刪程式碼。

此時的我認為組織架構樹的寫法有問題，所以花了兩天的時間過了一遍組織架構樹的程式碼，未發現有什麼異常的地方。

為了確認是組織架構樹的問題還是頁面列表的問題，我在專案中新建了兩個空白的路由頁面。在這個頁面中單獨使用這兩個元件，都沒有問題。

問題陷入了僵局...

在我們修復這個問題的期間，另一個使用者也反饋了相同的問題過來，不過使用者說他用的是edge瀏覽器。此時同事說edge好像可以撐的更久一點。