引言
在開發綜合治理平臺態勢概覽的大屏頁面的過程，遇到了頁面崩潰的問題，本帖子記錄了崩潰的原因分析和解決方案。
問題
打開綜合治理平臺，進入態勢概覽頁面，停留在此頁面一段時間，會出現如下圖所示的頁面崩潰的情況。
原因分析
注：以下操作環境建議在瀏覽器隱身模式下進行，防止其他因素干擾
使用工具
根據頁面崩潰的提示，可以初步判定是頁面內存溢出導致的崩潰，為了驗證內存是否溢出，可以使用 瀏覽器自帶的工具分析驗證。這里介紹三種工具的使用，可以結合實際需求來使用。
任務管理器1) 打開方式：
2) 界面：
3）使用方式：任務管理器的使用方法最為簡單，打開需要分析的頁面，直接觀察內存占用空間與 使用的內存即可。如果這兩個數據持續上升，說明內存正在泄漏。
開發者工具 面板1） 打開方式：按 F12 打開開發者工具，選擇 欄2） 界面：
3） 使用方式：打開需要分析的頁面，等頁面穩定下來后，點擊 左上角的錄制按鈕開始錄制，它會保存下頁面的快照、JS Heap、、Nodes、、GPU 等信息。錄制一段時間（最好在一分鐘以上）后，停止錄制，等待工具生成報告。
開發者工具 面板1） 打開方式：按 F12 打開開發者工具，選擇 欄2） 界面：
3） 使用方式：這個工具的使用方式最為復雜，這里只簡單介紹下 Heap 的使用，感興趣的可以自行搜索其他使用方式。首先，打開需要分析內存的頁面，點擊工具左上方的錄制按鈕，生成分析報告。其次，進行一些可能導致內存上升的操作后，再次點擊錄制按鈕，生成分析報告。最后，我們有了兩份分析報告，通過菜單欄的下拉框選擇 過濾分析結果。觀察 #New、#、#Delta 這三列，分別代表新增對象數、刪除對象數、新增數與刪除數的差值，找到那些只有新增，沒有刪除的對象，看看是被誰引用了瀏覽器崩潰是什么原因，據此來找到可能導致內存溢出的代碼。
確定內存溢出原因
打開態勢概覽頁面后，通過任務管理器觀察頁面使用的內存，發現內存是持續上升的，這時再通過 工具進一步分析。以下是 的分析結果：
通過分析結果可以看到，內存資源在持續上升，再進一步觀察結果，可以發現內存上升是存在一個階梯式的上升周期的，為什么會產生這種現象呢？放大內存上升的部分進一步分析看看：
上圖顯示了內存上升部分細節，把鼠標移動到頁面快照上，可以清楚地看到，當上一個大屏頁面輪播到下一個頁面時，內存就會上升并且不會再下降到之前的水平。現在已經有理由懷疑是頁面輪播引起的內存溢出，所以，通過暫停頁面輪播，再進行一次 分析，看看分析結果：
通過上圖可以看到，暫停頁面輪播后，并沒有明顯的上升趨勢，說明瀏覽器可以正常回收內存，并沒有溢出。至此，已經可以確定當頁面輪播時內存會溢出。
分析內存溢出對象
經過第二步的分析，已經知道了大屏頁面切換會導致內存升高，利用這個證據，用 工具去進一步分析，找到那些被引用本該被釋放，但實際沒有的釋放的對象。首先，打開態勢概覽頁面，先暫停頁面輪播切換，停留在總體態勢頁面，待頁面加載完成，然后打開 工具，點擊錄制按鈕分析總體態勢頁面的內存。分析完成后，手動切換到風險態勢頁面或者其他大屏頁面，再切換回總體態勢頁面，然后在 工具中再次點擊錄制按鈕分析頁面切換之后的內存。完成以上操作之后，就得到了兩份分析報告，分別是內存上升前和上升后的，在 工具的菜單欄下拉框中選擇 ，看看到底是哪些家伙占用了內存！
來分析上面的結果圖，首先，頁面上有各種類型的對象，點擊對象可以看到對象具體的引用信息，我們的任務是通過對象引用信息找到一些蛛絲馬跡。我們可以搜索 開頭歸類的對象，也就是那些在內存中但是沒有在頁面進行渲染的元素。選擇一個，可以看到它的詳細引用信息：
很明顯， 引用了這個對象，而這個對象連同它的引用，理應是在頁面切換之后被銷毀了的，既然他沒有銷毀瀏覽器崩潰是什么原因，說明我們的代碼是有問題的。接下來要做的是，找出 引用的對象沒有被銷毀的原因，修改相關代碼，再驗證。
解決方案使用正確的 實例銷毀方法
根據上面的原因分析，我們知道是 引用的對象沒有正常被銷毀，那么很簡單，我們只要嘗試正確銷毀 實例就好了。進入到我們的 組件代碼，定位到 鉤子，可以看到，已經有一段代碼對 實例進行釋放了。
進入 官網查詢銷毀實例的相關 api，發現.clear()方法只是清空了實例，并沒有銷毀，而.()方法才會銷毀實例。
答案到這里已經呼之欲出了，我們項目中之前一直用的是.clear()方法清空 實例對象，而不是用.()銷毀，所以 實例并沒有被正常銷毀，當我們頻繁地切換頁面的時候， 實例就會不斷的累加，占用的內存也會隨之增加。所以，這里建議，以后我們封裝 組件的時候，統一使用.()方法銷毀組件。
頁面隱藏時停止定時器任務
你以為到這里就結束了嗎？事情沒有那么簡單！在搜索內存溢出解決方案的時候，在網上看到了一篇文章：//p/.html
再次通過 工具分析驗證，結果如下：
果然，內存又在持續增加，那么就使用網上分享的方法解決這個問題，添加一個標簽切換的監聽函數，在離開頁面時，把頁面的定時器清除，回來頁面時重新開啟定時器，這樣就可以了。
結果
保持在態勢概覽頁面，并開啟輪播頁面，使用 工具進行內存分析結果：內存保持在平穩狀態，沒有上升，頁面沒有崩潰
進入態勢概覽頁面，開啟輪播頁面后，切換到其他標簽頁或最小化瀏覽器結果：內存保持在平穩狀態，沒有上升，頁面沒有崩潰
保持在態勢概覽頁面，并開啟輪播頁面，不做其他操作，掛機一天一夜。結果：內存保持在 2G 左右，頁面沒有崩潰
總結
通過此次的內存溢出分析，我們認識了一些內存分析工具及內存分析方法，也發現了代碼中不足的地方，最后通過正確的方法解決了內存溢出的問題。希望這篇文章可以對大家日后的工作有所幫助。當然，這只是很小一部分，也可能有不正確的地方，歡迎大家提出疑問一起探討。
本文由博客群發一文多發等運營工具平臺 發布
