Android程序的內存泄漏與規避方法

引言

Android應用程序中內存使用的問(wèn)題經(jīng)常容易被忽視，在傳統的編程語(yǔ)言中(例如C語(yǔ)言)，回收內存的任務(wù)是由程序本身來(lái)完成的，程序可以顯式分配和釋放變量所占用的內存。Android[1]應用程序采用Java編程語(yǔ)言編寫(xiě)，而Java區別于其他語(yǔ)言的一個(gè)重要優(yōu)點(diǎn)就是它通過(guò)垃圾收集器(Garbage Collection，GC) 自動(dòng)管理內存的回收，Java程序員只需通過(guò)內存分配操作創(chuàng )建對象，而無(wú)須關(guān)心對象占用的空間是如何被收回的。因此很多程序員認為在Java中不必擔心內存泄漏的問(wèn)題，然而實(shí)際并非如此，Java中仍然存在著(zhù)內存泄漏。Android應用程序運行在嵌入式系統中，而嵌入式系統中內存的總量非常有限，因此如何合理地規避“內存泄露”問(wèn)題也就顯得十分關(guān)鍵。

1　造成Android應用程序內存泄漏的原因

1.1　引用沒(méi)釋放造成的內存泄露

(1) 注冊沒(méi)有取消造成的內存泄漏

這種Android的內存泄露比純Java的內存泄漏還要嚴重，因為其他一些Android程序可能引用系統的Android程序的對象(比如注冊機制)。即使Android程序已經(jīng)結束了，但是別的應用程序仍然還有對Android程序的某個(gè)對象的引用，泄漏的內存依然不能被垃圾回收。

(2) 集合中對象沒(méi)有關(guān)閉造成的內存泄漏

通常把一些對象的引用加入到了集合中，當我們不需要該對象時(shí)，并沒(méi)有把它的引用從集合中清理掉，慢慢地這個(gè)集合就會(huì )越來(lái)越大。如果這個(gè)集合是靜態(tài)的話(huà)，那情況就會(huì )更嚴重。

1.2　資源對象沒(méi)有關(guān)閉造成的內存泄漏

資源對象比如Cursor、File文件等往往都用了一些緩沖，在不使用的時(shí)候應該及時(shí)關(guān)閉它們，以便它們的緩沖及時(shí)回收內存。這些緩沖不僅存在于Java虛擬機內，還存在于Java虛擬機外，如果僅僅是把它的引用設置為空,而不關(guān)閉它們，那么往往會(huì )造成內存泄漏。

一些不良代碼造成的內存壓力原因如下：

◆ Bitmap沒(méi)有調用recycle( );

◆ 構造Adapter時(shí)，沒(méi)有使用緩存的convertView;

◆ ThreadLocal使用不當;

◆ 其他。

2　內存泄漏的檢測及定位

2.1　內存泄漏的檢測

Android應用程序是基于虛擬機的，其內存管理都是由Dalvik[2]代為管理，GC的回收不是及時(shí)的。一個(gè)正常的應用程序在其運行穩定后其內存的占用量是基本穩定的，不應該是無(wú)限制的增長(cháng)。同樣，對任何一個(gè)類(lèi)的對象的使用個(gè)數也有一個(gè)相對穩定的上限，不應該是持續增長(cháng)的。當我們持續地觀(guān)察某個(gè)應用程序運行過(guò)程中使用內存的大小和各實(shí)例的個(gè)數時(shí)，如果內存的大小持續增長(cháng)，則說(shuō)明系統存在內存泄漏的問(wèn)題;如果特定類(lèi)的實(shí)例對象個(gè)數隨時(shí)間而增長(cháng)，則說(shuō)明這個(gè)類(lèi)的實(shí)例可能存在泄漏情況。比如一個(gè)Activity被關(guān)掉之后，其內存的引用對象會(huì )在下次GC回收[3]的時(shí)候通過(guò)回收算法計算，如果這部分內存已經(jīng)屬于可回收的對象，那么這些垃圾對象會(huì )被一并回收，內存未泄漏趨勢圖如圖1所示。

圖1　內存未泄漏趨勢圖

內存泄漏趨勢圖如圖2所示。在重復打開(kāi)關(guān)閉某個(gè)應用程序的時(shí)候，內存一直在向上爬升，也就是說(shuō)每次關(guān)閉這個(gè)Activity的時(shí)候，有些應該釋放的內存并沒(méi)有被釋放掉。由此我們可以確定這個(gè)應用程序存在著(zhù)內存泄漏的問(wèn)題。

圖2　內存泄漏趨勢圖

2.2　內存泄漏的位置定位

查找內存泄漏一種比較徹底的方法就是代碼走查，我們可以一行一行地分析對象的創(chuàng )建去留等等[4]，但會(huì )很耗時(shí)間也比較迷茫。這里可以通過(guò)Eclipse Memory Analyzer Tool(MAT)工具來(lái)定位內存泄漏的位置，該方法只適用于Java層的查找，對C/C++沒(méi)用，也就是說(shuō)只針對于被虛擬機來(lái)管理的進(jìn)程和內存。MAT的解析文件是.hprof文件，這個(gè)文件里面存放了某進(jìn)程的內存快照，MAT通過(guò)解析.hprof文件就會(huì )自動(dòng)生成一個(gè)內存泄漏推測報告，通過(guò)分析這個(gè)報告就可以準確定位到有可能存在內存泄漏的具體位置。

然而，還有一些內存泄漏通過(guò)MAT是查不出來(lái)的，比如native的代碼，對C/C++是無(wú)能為力的，對于這些問(wèn)題本文并沒(méi)有做過(guò)多的研究。

3　規避內存泄漏的方法

在編寫(xiě)應用程序的過(guò)程中，對于BraodcastReceiver、ContentObserver、FileObserver在A(yíng)ctivity onDestory或者某類(lèi)聲明周期結束之后一定要注銷(xiāo)掉，否則這個(gè)Activity類(lèi)會(huì )被系統強引用，不會(huì )被內存回收。

在定義成員變量時(shí)，不要直接對Activity進(jìn)行引用而作為成員變量。如果不得不這么做，那么可以用private Weak Reference mActivity來(lái)聲明。同樣，對于Service等其他有自己聲明周期的對象來(lái)說(shuō)，直接引用都需要謹慎考慮是否會(huì )存在內存泄漏的可能。

在應用程序中，很多內存泄漏是由于循環(huán)引用而造成的，比如a中包含了b，b中包含了c，c中又包含a，這樣只要一個(gè)對象存在，那么其他對象肯定會(huì )一直常駐內存。因此，在編寫(xiě)應用程序時(shí)要從邏輯上來(lái)分析是否需要這樣的設計。

Bitmap對象不再使用時(shí)，調用recycle()方法釋放內存。如果一個(gè)Bitmap對象比較占內存，當它不再被使用的時(shí)候，可以調用Bitmap.recycle()方法回收此對象的像素所占用的內存，這個(gè)不是必須的，可視情況而定。

還要注意釋放對象的引用。當一個(gè)生命周期較短的對象A，被一個(gè)生命周期較長(cháng)的對象B保有其引用的情況下，在A(yíng)的生命周期結束時(shí)，要在B中清除掉對A的引用。

4　內存監測工具DDMS和內存分析工具M(jìn)AT

4.1　內存監測工具DDMS

我們在開(kāi)發(fā)Android應用程序時(shí)，很容易造成內存的泄漏，這時(shí)需要一些工具來(lái)幫助我們檢查代碼中是否存在會(huì )造成內存泄漏的不良代碼。在A(yíng)ndroid tools的DDMS里面帶有一個(gè)內存監測工具Heap，用它來(lái)監測應用程序使用內存的情況，這里需要和Eclipse配合使用。利用 Heap工具監測應用進(jìn)程使用內存情況的方法如下：

① 首先啟動(dòng)Eclipse，切換到DDMS透視圖，并確認Devices視圖、Heap視圖都已打開(kāi)。將要測試的設備(比如手機)通過(guò)USB數據線(xiàn)連接到電腦上，連接成功后，會(huì )在DDMS的Devices視圖界面中顯示手機設備的序列號，以及設備中正在運行的部分進(jìn)程信息。