轉(zhuǎn)載地址:http://blog.csdn.net/huang_cai_yuan/article/details/50375019
一荷辕、概述
Android內(nèi)存的文章詳見(jiàn)：http://blog.csdn.net/linghu_java/article/details/39480761
在Android的開(kāi)發(fā)中，經(jīng)常聽(tīng)到“內(nèi)存泄漏”這個(gè)詞件豌〈剑“內(nèi)存泄漏”就是一個(gè)對(duì)象已經(jīng)不需要再使用了，但是因?yàn)槠渌膶?duì)象持有該對(duì)象的引用茧彤，導(dǎo)致它的內(nèi)存不能被回收骡显。“內(nèi)存泄漏”的慢慢積累曾掂，最終會(huì)導(dǎo)致OOM的發(fā)生惫谤，千里之堤，毀于蟻穴珠洗。所以在寫(xiě)代碼的過(guò)程中溜歪，應(yīng)該要注意規(guī)避會(huì)導(dǎo)致“內(nèi)存泄漏”的代碼寫(xiě)法，提高軟件的健壯性险污。
本文將從發(fā)現(xiàn)問(wèn)題痹愚、解決問(wèn)題、總結(jié)問(wèn)題的三個(gè)角度出發(fā)蛔糯，循序漸進(jìn)拯腮，徹底解決“內(nèi)存泄漏”的問(wèn)題。
工欲善其事必先利其器动壤，要檢測(cè)“內(nèi)存泄漏”的發(fā)生，需要借助DDMS中的Heap工具及MAT工具淮逻，Heap工具用于大致分析是否存在“內(nèi)存泄漏”琼懊，而MAT工具則用于分析“內(nèi)存泄漏”發(fā)生在哪里。
Heap工具的使用介紹
具體操作
1.在Devices設(shè)備列表中爬早，找到你所在的設(shè)備哼丈，點(diǎn)擊你想要監(jiān)控的進(jìn)程。
2.點(diǎn)擊“Update Heap”按鈕更新堆內(nèi)存的情況筛严。
3.點(diǎn)擊“Heap”視圖醉旦，查看內(nèi)存的情況。
4.每次在Activity的退出和進(jìn)入的時(shí)候點(diǎn)擊“Cause GC”桨啃，手動(dòng)調(diào)用GC釋放應(yīng)用的內(nèi)存车胡。
5.觀察data oject那一行，每一次點(diǎn)擊“Casue GC”的時(shí)候照瘾，觀察Total Size的值匈棘，如果該值不斷增加，則說(shuō)明該應(yīng)用程序存在“內(nèi)存泄漏”析命。
我們先模擬一下內(nèi)存泄漏主卫，然后通過(guò)Heap工具來(lái)判斷一下是否存在內(nèi)存泄漏逃默。
上一段存在內(nèi)存泄漏的代碼：
一、概述
Android內(nèi)存的文章詳見(jiàn)：http://blog.csdn.net/linghu_java/article/details/39480761
在Android的開(kāi)發(fā)中队秩，經(jīng)常聽(tīng)到“內(nèi)存泄漏”這個(gè)詞笑旺。“內(nèi)存泄漏”就是一個(gè)對(duì)象已經(jīng)不需要再使用了馍资，但是因?yàn)槠渌膶?duì)象持有該對(duì)象的引用筒主，導(dǎo)致它的內(nèi)存不能被回收∧裥罚“內(nèi)存泄漏”的慢慢積累乌妙，最終會(huì)導(dǎo)致OOM的發(fā)生，千里之堤建钥，毀于蟻穴藤韵。所以在寫(xiě)代碼的過(guò)程中，應(yīng)該要注意規(guī)避會(huì)導(dǎo)致“內(nèi)存泄漏”的代碼寫(xiě)法熊经，提高軟件的健壯性泽艘。
本文將從發(fā)現(xiàn)問(wèn)題、解決問(wèn)題镐依、總結(jié)問(wèn)題的三個(gè)角度出發(fā)匹涮，循序漸進(jìn)，徹底解決“內(nèi)存泄漏”的問(wèn)題槐壳。
工欲善其事必先利其器，要檢測(cè)“內(nèi)存泄漏”的發(fā)生务唐，需要借助DDMS中的Heap工具及MAT工具雳攘，Heap工具用于大致分析是否存在“內(nèi)存泄漏”，而MAT工具則用于分析“內(nèi)存泄漏”發(fā)生在哪里枫笛。
Heap工具的使用介紹
具體操作
1.在Devices設(shè)備列表中吨灭，找到你所在的設(shè)備，點(diǎn)擊你想要監(jiān)控的進(jìn)程刑巧。
2.點(diǎn)擊“Update Heap”按鈕更新堆內(nèi)存的情況沃于。
3.點(diǎn)擊“Heap”視圖，查看內(nèi)存的情況海诲。
4.每次在Activity的退出和進(jìn)入的時(shí)候點(diǎn)擊“Cause GC”，手動(dòng)調(diào)用GC釋放應(yīng)用的內(nèi)存檩互。
5.觀察data oject那一行特幔，每一次點(diǎn)擊“Casue GC”的時(shí)候，觀察Total Size的值闸昨，如果該值不斷增加蚯斯，則說(shuō)明該應(yīng)用程序存在“內(nèi)存泄漏”薄风。
我們先模擬一下內(nèi)存泄漏，然后通過(guò)Heap工具來(lái)判斷一下是否存在內(nèi)存泄漏拍嵌。
上一段存在內(nèi)存泄漏的代碼：
上述的代碼存在內(nèi)存泄漏遭赂，new Runnable(){}是一個(gè)非靜態(tài)的匿名內(nèi)部類(lèi)，所以它會(huì)強(qiáng)引用創(chuàng)建它的外圍對(duì)象LeakAty横辆，我們來(lái)測(cè)試一下內(nèi)存泄漏的過(guò)程撇他，開(kāi)啟手機(jī)的方向旋轉(zhuǎn)功能，不斷地旋轉(zhuǎn)手機(jī)狈蚤，讓LeakAty不斷地創(chuàng)建新的實(shí)例困肩。理論上如果不存在上述泄漏的代碼，之前的Activity會(huì)在onDestory之后被回收內(nèi)存脆侮。而一旦存在上述泄漏的代碼锌畸，新創(chuàng)建的Ruannale實(shí)例會(huì)一直處于運(yùn)行狀態(tài)，它不會(huì)被回收靖避，而它強(qiáng)引用的LeakAty當(dāng)然也不會(huì)被回收潭枣，所以在屏幕不斷旋轉(zhuǎn)，之前創(chuàng)建的LeakAty就不會(huì)被釋放幻捏，會(huì)導(dǎo)致旋轉(zhuǎn)n次盆犁，內(nèi)存中就存在n+1個(gè)的LeakAty實(shí)例。
Heap工具第一次按下Cause GC按鈕的截圖:
上圖的data object的Total Size的大小為1.031M粘咖。經(jīng)過(guò)多次的旋轉(zhuǎn)屏幕之后蚣抗，我們?cè)倏匆幌陆貓D
Total Size變成了2.059M，從1.031M到2.059M瓮下，每次調(diào)用GC的過(guò)程中data object的總大小沒(méi)有回落翰铡，所以可以證實(shí)上面的代碼確實(shí)是存在內(nèi)存泄漏的問(wèn)題，那么泄漏發(fā)生在哪里讽坏？答案可以通過(guò)MAT工具來(lái)分析得到锭魔。
要通過(guò)MAT分析路呜，需要提供一個(gè).hprof文件迷捧。我們可以通過(guò)”Dump HPROF file”按鈕轉(zhuǎn)存當(dāng)前的堆內(nèi)存信息。我們將其保存為1.hprof胀葱。
導(dǎo)出的1.hprof的格式需要通過(guò)..\sdk\tools\目錄下的hprof-conv.exe工具進(jìn)行轉(zhuǎn)換才能被MAT成功導(dǎo)入漠秋，我們將其轉(zhuǎn)換成out1.hprof
將out1.hprof導(dǎo)入到MAT工具中,File->Open Heap Dump…
點(diǎn)擊左邊的標(biāo)簽Overview,Actions->Histogram
在Histogram界面中，因?yàn)槲覀兿胍繟ctivity是否泄漏了抵屿，所以輸入關(guān)鍵詞Activity,然后按下回車(chē)鍵庆锦。
之后便可以得到Activity的相關(guān)的搜索結(jié)果,下圖的搜索結(jié)果中Activity的實(shí)例有7個(gè)。點(diǎn)擊選中下圖標(biāo)紅色框框的地方轧葛，右鍵->Merge Shortest Paths to GC Roots->exclude all phantom/weak/soft etc. references搂抒。排除虛引用艇搀、弱引用、軟引用的實(shí)例求晶，剩下的都是強(qiáng)引用實(shí)例焰雕。
從過(guò)濾出來(lái)的強(qiáng)引用的列表中，我們可以看到這七個(gè)實(shí)例都是被Thread所引用了芳杏。所以證實(shí)上面的代碼確實(shí)存在內(nèi)存泄漏矩屁。
內(nèi)存泄漏檢測(cè)可以使用Heap工具蚜锨，內(nèi)存分析可以使用MAT工具档插。本文的案例中提到了一種內(nèi)存泄漏的情況，就是非靜態(tài)內(nèi)部類(lèi)的對(duì)象會(huì)強(qiáng)引用其外圍對(duì)象亚再，一旦這個(gè)非靜態(tài)內(nèi)部類(lèi)的實(shí)例沒(méi)有釋放郭膛，它的外圍對(duì)象也不會(huì)釋放，所以就會(huì)造成內(nèi)存泄漏氛悬。下篇將具體探討一下则剃，在Android的開(kāi)發(fā)過(guò)程中，哪些寫(xiě)法容易造成內(nèi)存泄漏如捅，該如何解決棍现？請(qǐng)閱讀Android內(nèi)存泄漏終極解決篇（下）。
MAT工具下載見(jiàn)：MAT下載地址
上述的代碼存在內(nèi)存泄漏己肮，new Runnable(){}是一個(gè)非靜態(tài)的匿名內(nèi)部類(lèi)，所以它會(huì)強(qiáng)引用創(chuàng)建它的外圍對(duì)象LeakAty悲关，我們來(lái)測(cè)試一下內(nèi)存泄漏的過(guò)程谎僻，開(kāi)啟手機(jī)的方向旋轉(zhuǎn)功能，不斷地旋轉(zhuǎn)手機(jī)寓辱，讓LeakAty不斷地創(chuàng)建新的實(shí)例艘绍。理論上如果不存在上述泄漏的代碼，之前的Activity會(huì)在onDestory之后被回收內(nèi)存秫筏。而一旦存在上述泄漏的代碼诱鞠，新創(chuàng)建的Ruannale實(shí)例會(huì)一直處于運(yùn)行狀態(tài)，它不會(huì)被回收这敬，而它強(qiáng)引用的LeakAty當(dāng)然也不會(huì)被回收航夺，所以在屏幕不斷旋轉(zhuǎn)，之前創(chuàng)建的LeakAty就不會(huì)被釋放崔涂，會(huì)導(dǎo)致旋轉(zhuǎn)n次敷存，內(nèi)存中就存在n+1個(gè)的LeakAty實(shí)例。
Heap工具第一次按下Cause GC按鈕的截圖:
上圖的data object的Total Size的大小為1.031M。經(jīng)過(guò)多次的旋轉(zhuǎn)屏幕之后锚烦，我們?cè)倏匆幌陆貓D
Total Size變成了2.059M，從1.031M到2.059M帝雇，每次調(diào)用GC的過(guò)程中data object的總大小沒(méi)有回落涮俄，所以可以證實(shí)上面的代碼確實(shí)是存在內(nèi)存泄漏的問(wèn)題，那么泄漏發(fā)生在哪里尸闸？答案可以通過(guò)MAT工具來(lái)分析得到彻亲。
要通過(guò)MAT分析吮廉，需要提供一個(gè).hprof文件苞尝。我們可以通過(guò)”Dump HPROF file”按鈕轉(zhuǎn)存當(dāng)前的堆內(nèi)存信息。我們將其保存為1.hprof宦芦。
導(dǎo)出的1.hprof的格式需要通過(guò)..\sdk\tools\目錄下的hprof-conv.exe工具進(jìn)行轉(zhuǎn)換才能被MAT成功導(dǎo)入宙址，我們將其轉(zhuǎn)換成out1.hprof
將out1.hprof導(dǎo)入到MAT工具中,File->Open Heap Dump…
點(diǎn)擊左邊的標(biāo)簽Overview,Actions->Histogram
在Histogram界面中，因?yàn)槲覀兿胍繟ctivity是否泄漏了调卑，所以輸入關(guān)鍵詞Activity,然后按下回車(chē)鍵抡砂。
之后便可以得到Activity的相關(guān)的搜索結(jié)果,下圖的搜索結(jié)果中Activity的實(shí)例有7個(gè)。點(diǎn)擊選中下圖標(biāo)紅色框框的地方恬涧，右鍵->Merge Shortest Paths to GC Roots->exclude all phantom/weak/soft etc. references注益。排除虛引用、弱引用溯捆、軟引用的實(shí)例丑搔，剩下的都是強(qiáng)引用實(shí)例。
從過(guò)濾出來(lái)的強(qiáng)引用的列表中提揍，我們可以看到這七個(gè)實(shí)例都是被Thread所引用了啤月。所以證實(shí)上面的代碼確實(shí)存在內(nèi)存泄漏。
內(nèi)存泄漏檢測(cè)可以使用Heap工具顽冶，內(nèi)存分析可以使用MAT工具。本文的案例中提到了一種內(nèi)存泄漏的情況售碳，就是非靜態(tài)內(nèi)部類(lèi)的對(duì)象會(huì)強(qiáng)引用其外圍對(duì)象强重，一旦這個(gè)非靜態(tài)內(nèi)部類(lèi)的實(shí)例沒(méi)有釋放，它的外圍對(duì)象也不會(huì)釋放贸人，所以就會(huì)造成內(nèi)存泄漏间景。下篇將具體探討一下，在Android的開(kāi)發(fā)過(guò)程中艺智，哪些寫(xiě)法容易造成內(nèi)存泄漏倘要，該如何解決？請(qǐng)閱讀Android內(nèi)存泄漏終極解決篇（下）。
MAT工具下載見(jiàn)：MAT下載地址
