什麼是記憶體洩露?記憶體洩露是指new了一塊記憶體,但無法被釋放或者被垃圾回收。new了一個物件之後,它申請佔用了一塊堆記憶體,當把這個物件指標置為null時或者離開作用域導致被銷燬,那麼這塊記憶體沒有人引用它了在JS裡面就會被自動垃圾回收。但是如果這個物件指標沒有被置為null,且程式碼裡面沒辦法再獲取到這個物件指標了,就會導致無法釋放掉它指向的記憶體,也就是說發生了記憶體洩露。為什麼程式碼裡面會拿不到這個物件指標了呢,舉一個例子:
1 2 3 4 5 6 7 8 9 10 11 |
// module date.js let date = null; export default { init () { date = new Date(); } } // main.js import date from 'date.js'; date.init(); |
在main.js初始化了date之後,date這個變數就一會直存在了,直到你把頁面關了,因為date的引用是在另一個module裡面,可以理解為模組就是一個閉包對外是不可見的。所以如果你是希望這個date物件一直存在、需要一直使用的話,那麼沒有問題,但是如果想用一次就不用了那就會有問題,這個物件一直在記憶體裡面沒有被釋放就發生了記憶體洩露。
另一種比較隱蔽並且很常見的記憶體洩露是事件繫結,形成了一個閉包,導致一些變數一直存在。如下例子所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// 一個圖片懶惰載入引擎示例 class ImageLazyLoader { constructor ($photoList) { $(window).on('scroll', () => { this.showImage($photoList); }); } showImage ($photoList) { $photoList.each(img => { // 通過位置判斷圖片滑出來了就載入 img.src = $(img).attr('data-src'); }); } } // 點選分頁的時候就初始化一個圖片懶惰載入的 $('.page').on('click', function () { new ImageLazyLoader($('img.photo')); }); |
這是一個圖片懶惰載入的模型,每次點分頁的時候就會清掉上一頁的資料更新為當前頁的DOM,並重新初始化一個懶惰載入的引擎。它裡面監聽了scroll事件,對傳進來的圖片列表的DOM進行處理。每點一次分頁就會重新new一個,這裡就發生了記憶體洩露,主要是以下3行程式碼導致的:
1 2 3 |
$(window).on('scroll', () => { this.showImage($photoList); }); |
因為這裡的事件繫結形成了一個閉包,this/$photoList這兩個變數一直沒有被釋放,this是指向ImageLazyLoader的例項,而$photoList是指向DOM結點,當清除掉上一頁的資料的時候,相關DOM結點已經從DOM樹分離出來了,但是仍然還有一個$photoList指向它們,導致這些DOM結點無法被垃圾回收一直在記憶體裡面,就發生了記憶體洩露。由於this變數也被閉包困住了沒有被釋放,所以還有一個ImageLazyLoader的例項發生記憶體洩露。
這個的解決方法比較簡單,就是銷燬例項的時候把繫結的事件off掉,如下程式碼所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
class ImageLazyLoader { constructor ($photoList) { this.scrollShow = () => { this.showImage($photoList); }; $(window).on('scroll', this.scrollShow); } // 新增一個事件解綁 clear () { $(window).off('scroll', this.scrollShow); } showImage ($photoList) { $photoList.each(img => { // 通過位置判斷圖片滑出來了就載入 img.src = $(img).attr('data-src'); }); // 判斷如果圖片已全部顯示,就把事件解綁了 if (this.allShown) { this.clear(); } } } // 點選分頁的時候就初始化一個圖片懶惰載入的 let lazyLoader = null; $('.page').on('click', function () { lazyLoader && (lazyLoader.clear()); lazyLoader = new ImageLazyLoader($('img.photo')); }); |
在每次例項化一個ImageLazyLoader之前把先把上一個例項clear掉,clear裡面進行解綁,由於JS有建構函式但是沒有解構函式,所以需要自己寫一個clear,在外面手動調一下clear。同時在事件的執行過程的合適時機自動把事件給解綁了,上面是判斷如果所有的圖片都展示出來了那麼就沒必要監聽scroll事件了直接解綁了。這樣就能解決記憶體洩露的問題了,能夠觸發自動垃圾回收。
為什麼把事件解綁了,就不會有閉包引用了呢?因為JS引擎檢測到那個閉包沒用了,就把那個閉包銷燬了,那麼閉包引用的外部變數也自然會被置空。
好了,基礎知識就講解到這裡,現在用Chrome devtools的記憶體檢測工具來實際操作一遍,方便發現頁面的一些記憶體洩露行為。為了避免裝給瀏覽器裝的一些外掛造成影響,使用Chome的隱身模式頁面,它會把所有的外掛都給禁掉。
然後開啟devtools,切到Memory的tab,選中Heap snapshot,如下所示:
什麼叫heap snapshot呢?翻譯一下就是堆快照,給當前記憶體堆拍一張照片。因為動態申請的記憶體都是在堆裡面的,而區域性變數是在記憶體棧裡面,是由作業系統分配管理的是不會記憶體洩露了。所以關心堆的情況就好了。
然後做一些增刪改DOM的操作,如:
(1)彈一個框,然後把彈框給關了
(2)單頁面的點選跳轉到另一個路由,然後再點後退返回
(3)點選分頁觸發動態改DOM
就是先增加DOM,然後把這些DOM給刪了,看一下這些被刪除的DOM是否還有物件引用它們。
這裡我是第2種方式的場景,檢測單頁面應用的某個路由頁面是否存在記憶體洩露。先開啟首頁,點到另一個頁面,再點後退,接著點一下垃圾回收的按鈕:
觸發垃圾回收,避免一些不必要的干擾。
然後再點一下拍照按鈕:
它就會把當前頁面的記憶體堆掃描一遍顯示出來,如下圖所示:
然後在上面中間的Class Filter的搜尋框裡搜一下detached:
它就會顯示所有已經分離了DOM樹的DOM結點,重點關注distance值不為空的,這個distance表示距離DOM根結點的距離。上圖展示的這些div具體是啥呢?我們把滑鼠放上去不動等個2s,它就會顯示這個div的DOM資訊:
通過className等資訊可以知道它就是那個要檢查的頁面的DOM節點,在下面的Object的視窗裡面依次展開它的父結點,可以看到它最外面的父結點是一個VueComponent例項:
下面黃色字型native_bind表示有個事件指向了它,黃色表示引用仍然生效,把滑鼠放到native_bind上面停留2秒:
它會提示你是在homework-web.vue這個檔案有一個getScale函式繫結在了window上面,檢視一下這個檔案確實是有一個繫結:
1 2 3 |
mounted () { window.addEventListener('resize', this.getScale); } |
所以雖然Vue元件把DOM刪除了,但是還有個引用存在,導致元件例項沒有被釋放,元件裡面又有一個$el指向DOM,所以DOM也沒有被釋放。
但是看程式碼的話是在beforeDestroyed裡面解綁的:
1 2 3 |
beforeDestroyed () { window.removeEventListener('resize', this.getScale); } |
所以應該沒有問題啊?
定睛一看,傻眼了,原來函式名寫錯了,應該是:
1 2 3 |
beforeDestroy () { window.removeEventListener('resize', this.getScale); }, |
發現了一個隱藏多日的bug,因為這個比較隱蔽,就算寫錯了也不會有明顯的感知了。
把這個地方改一下,重複操作一遍,再拍一張記憶體快照。我們發現遊離的div節點仍然是74個且disance不為空,沒有改進如下圖所示:
難道剛剛改得不對?繼續檢視剛剛第2個節點:
可以發現,這次是有一個事件匯流排EventBus的事件繫結指向了它,說明除了剛剛那個resize事件繫結之外,還有一個EventBus的事件沒有釋放,事件名稱是gToNextHomworkTask。我們搜一下這個事件是在哪裡綁的,可以找到它是在路由元件的一個子元件裡面綁的:
1 2 3 |
beforeDestroy () { window.removeEventListener('resize', this.getScale); }, |
果不其然,這個元件只有$on,沒有$off,所以導致元件解除安裝的時候仍然有一個事件的引用。所以需要在這個元件的destroyed裡面給$off掉:
1 2 3 |
destroyed () { EventBus.$off('goToNextHomeworkTask', this.go2NextQuestion); } |
改完後重新整理頁面操作第3次,再拍一張記憶體快照,比較尷尬的是情況還是一樣:
說明還有人引用它,繼續檢視是誰引用了沒有釋放:
可以發現是一個Vuex的$store的watch監聽沒有釋放,藉助Watcher的cb屬性可以知道具體是哪個監聽函式。利用簡單的文字搜尋發現是在一個子元件裡面進行了watch:
1 2 3 4 5 6 7 |
mounted () { this.$store.watch(state => state.currentIndex, (newIndex, oldIndex) => { if (this.$refs.animation && newIndex === this.task.index - 1) { this.$refs.animation.beginElement(); } }); } |
watch裡面有一個this指標指向了元件的DOM元素,由於子元件沒有被釋放,那麼包含它的父元件自然不會被釋放,所以一層層往上,導致最外面那個路由元件也不會被釋放。
這個需要在destroyed的時候unwatch一下:
1 2 3 4 5 6 7 8 |
mounted () { this.unwatchStore = this.$store.watch(state => state.currentIndex, (newIndex, oldIndex) => { // 程式碼略 }); }, destroyed () { this.unwatchStore(); } |
處理完之後再拍一張記憶體快照,如下圖所示:
雖然還是74個但是distance已經為空了,可對比前3步distance都不為空,並且下面Object展開沒有找到標黃的部分了,也就是說這個路由元件記憶體洩露的問題已經得到解決。
我們繼續檢視其它distance不為空的div節點,如下圖所示,可以按照distance排下序:
其中有一個是.animate-container:
它是一個用來放lottie動畫的DOM容器,lottie物件裡面仍有引用它:
這個是一個用lottie做的loading動畫,當loading結束的時候,我會手動調一下它的stop api停止動畫,並且把.animte-container給remove掉,但是為什麼lottie還不肯放過它呢?我的程式碼是這麼寫的:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
let loadingAnimate = null; let bodymovinAnimate = { // 顯示loading動畫 showLoading () { loadingAnimate = bodymovinAnimate._showAnimate(); return loadingAnimate; }, // 停止loading動畫 stopLoading () { loadingAnimate && bodymovinAnimate._stopAnimate(loadingAnimate); }, // 開始lottie動畫 _showAnimate () { const animate = lottie.loadAnimation({ // 引數省略 }); return animate; } // 結束lottie動畫 _stopAnimate (animate) { animate.stop(); let $container = $(animate.wrapper).closest('.bodymovin-container'); $container.remove(); }, }; export default bodymovinAnimate; |
我猜想是調了stop之後lottie仍然沒有釋放對DOM的引用,因為stop之後還能夠夠支援重新start的,所以它得咬著DOM不放,因此如果要徹底結束動畫,應該不是調stop,查了一下它還有一個destroy的方法,把stop換成destroy:
1 2 3 4 5 6 |
// 結束lottie動畫 _stopAnimate (animate) { animate.destroy(); let $container = $(animate.wrapper).closest('.bodymovin-container'); $container.remove(); }, |
這樣改了之後,lottie的引用就會把它給釋放了,問題解決了,然後再重新拍一張照片:
仍然有一個exports.default指向它,它是webpack的模組,我猜想是因為本文開篇提到的例子的原因,就是模組形成了閉包,它的變數沒有被釋放造成記憶體洩露,所以在stopLoading裡面把它置成null:
1 2 3 4 5 |
// 停止loading動畫 stopLoading () { loadingAnimate && bodymovinAnimate._stopAnimate(loadingAnimate); loadingAnimate = null; }, |
這樣試了之後,.animate-container這個DOM物件就沒有人引用它了。
最後div還剩下3個有distance:
其中兩個是jq的$.support.boxSizingReliable,是jq用來檢測boxszing是否可用建立的div:
還有一個是Vue的:
這些都是使用的庫造成的記憶體洩露,暫時先不管。
再去分析其它的標籤也有類似的情況。
所以綜合上面的分析,造成記憶體洩露的可能會有以下幾種情況:
(1)監聽在window/body等事件沒有解綁
(2)綁在EventBus的事件沒有解綁
(3)Vuex的$store watch了之後沒有unwatch
(4)模組形成的閉包內部變數使用完後沒有置成null
(5)使用第三方庫建立,沒有呼叫正確的銷燬函式
並且可以藉助Chrome的記憶體分析工具進行快速排查,本文主要是用到了記憶體堆快照的基本功能,讀者可以嘗試分析自己的頁面是否存在記憶體洩漏,方法是做一些操作如彈個框然後關了,拍一張堆快照,搜尋detached,按distance排序,把非空的節點展開父級,找到標黃的字樣說明,那些就是存在沒有釋放的引用。也就是說這個方法主要是分析仍然存在引用的遊離DOM節點。因為頁面的記憶體洩露通常是和DOM相關的,普通的JS變數由於有垃圾回收所以一般不會有問題,除非使用閉包把變數困住了用完了又沒有置空。
DOM相關的記憶體洩露通常也是因為閉包和事件繫結引起的。綁了(全域性)事件之後,在不需要的時候需要把它解綁。當然直接綁在div上面的可以直接把div刪了,綁在它上面的事件就自然解綁了。