轉帖|行業資訊|編輯:龔雪|2016-06-01 10:24:34.000|閱讀 457 次
概述:測試跟你說你的XXActivity泄露了,你如何確認是否真的泄漏? 確認泄漏后,你又如何定位是哪里的問題導致內存泄漏? 文將另辟蹊徑,從更簡單的角度定位并解決這種問題。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關鏈接:
Android日常開發中,內存泄漏的重災區就是Activity,相信這兩個是每個Android開發者都碰到過的問題,遇到這種問題,我們一般都會祭出我們的殺手锏:Dump Java Heap然后MAT靜態分析GC鏈。本文將另辟蹊徑,從更簡單的角度定位并解決這種問題。
內存和性能分析工具AQtime Pro 點擊下載
C/C++語言內存分析和錯誤檢測工具Parasoft Insure++ 點擊查看
我們先來看一個抽象的Activity偽代碼:
如果我們想確認這個Activity是否存在泄漏,只需讓其覆蓋Object的finalize方法,在里面添加一句Logcat打印:
然后運行你的項目,打開這個Activity,然后按返回,退出Activity,然后通過IDE強制觸發一次GC操作:
然后查看Logcat,是否有對應的打印,就能確認Activity是否存在內存泄漏了:有打印,則無內存泄漏,無打印則肯定有內存泄漏了!
定位泄漏原因這個就是比較簡單粗暴的排除法,首先把所有復雜業務邏輯注視掉,直到內存泄漏現在不存在:
然后再進出一次Activity,觸發GC,確認Activity泄漏已經不存在。然后再把業務邏輯一個個補回來,直到泄漏現象重現。
這樣我們就能100%的找出泄漏的原因所在。
這里用到的一個知識點就是Java中Object類的finalize方法。當GC準備回收一個Java Object(所有Java對象都是Object的子類)的時候,GC會調用這個Object的finalize方法。這個方法有點類似于C++中析構函數,本意是讓你用來回收一些已經不需要的資源的(主要是針對Native資源)。其實Java日常開發中,并不鼓勵依賴于這個方法來實現回收的邏輯,因為如果你重度依賴于finalize的話,finalize本身也有可能造成內存泄漏,但是我們這里只是用來作為是否已經回收的依據,還是可以的。
雖然此方法看起來比較簡單無腦,但是簡單粗暴啊,也不失為給開發的一種便利的自測方式,不用其他工具就可以快速的確定你這次的需求新增的Activity是否存在泄漏,權當減少自己Bug數的一種方法吧!
原文轉載自:
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn