Android程序的內(nèi)存泄漏與規(guī)避方法
引言
本文引用地址:http://www.ex-cimer.com/article/148153.htmAndroid應(yīng)用程序中內(nèi)存使用的問題經(jīng)常容易被忽視,在傳統(tǒng)的編程語言中(例如C語言),回收內(nèi)存的任務(wù)是由程序本身來完成的,程序可以顯式分配和釋放變量所占用的內(nèi)存。Android[1]應(yīng)用程序采用Java編程語言編寫,而Java區(qū)別于其他語言的一個重要優(yōu)點就是它通過垃圾收集器(Garbage Collection,GC) 自動管理內(nèi)存的回收,Java程序員只需通過內(nèi)存分配操作創(chuàng)建對象,而無須關(guān)心對象占用的空間是如何被收回的。因此很多程序員認(rèn)為在Java中不必?fù)?dān)心內(nèi)存泄漏的問題,然而實際并非如此,Java中仍然存在著內(nèi)存泄漏。Android應(yīng)用程序運(yùn)行在嵌入式系統(tǒng)中,而嵌入式系統(tǒng)中內(nèi)存的總量非常有限,因此如何合理地規(guī)避“內(nèi)存泄露”問題也就顯得十分關(guān)鍵。
1 造成Android應(yīng)用程序內(nèi)存泄漏的原因
1.1 引用沒釋放造成的內(nèi)存泄露
(1) 注冊沒有取消造成的內(nèi)存泄漏
這種Android的內(nèi)存泄露比純Java的內(nèi)存泄漏還要嚴(yán)重,因為其他一些Android程序可能引用系統(tǒng)的Android程序的對象(比如注冊機(jī)制)。即使Android程序已經(jīng)結(jié)束了,但是別的應(yīng)用程序仍然還有對Android程序的某個對象的引用,泄漏的內(nèi)存依然不能被垃圾回收。
(2) 集合中對象沒有關(guān)閉造成的內(nèi)存泄漏
通常把一些對象的引用加入到了集合中,當(dāng)我們不需要該對象時,并沒有把它的引用從集合中清理掉,慢慢地這個集合就會越來越大。如果這個集合是靜態(tài)的話,那情況就會更嚴(yán)重。
1.2 資源對象沒有關(guān)閉造成的內(nèi)存泄漏
資源對象比如Cursor、File文件等往往都用了一些緩沖,在不使用的時候應(yīng)該及時關(guān)閉它們,以便它們的緩沖及時回收內(nèi)存。這些緩沖不僅存在于Java虛擬機(jī)內(nèi),還存在于Java虛擬機(jī)外,如果僅僅是把它的引用設(shè)置為空,而不關(guān)閉它們,那么往往會造成內(nèi)存泄漏。
一些不良代碼造成的內(nèi)存壓力原因如下:
◆ Bitmap沒有調(diào)用recycle( );
◆ 構(gòu)造Adapter時,沒有使用緩存的convertView;
◆ ThreadLocal使用不當(dāng);
◆ 其他。
2 內(nèi)存泄漏的檢測及定位
2.1 內(nèi)存泄漏的檢測
Android應(yīng)用程序是基于虛擬機(jī)的,其內(nèi)存管理都是由Dalvik[2]代為管理,GC的回收不是及時的。一個正常的應(yīng)用程序在其運(yùn)行穩(wěn)定后其內(nèi)存的占用量是基本穩(wěn)定的,不應(yīng)該是無限制的增長。同樣,對任何一個類的對象的使用個數(shù)也有一個相對穩(wěn)定的上限,不應(yīng)該是持續(xù)增長的。當(dāng)我們持續(xù)地觀察某個應(yīng)用程序運(yùn)行過程中使用內(nèi)存的大小和各實例的個數(shù)時,如果內(nèi)存的大小持續(xù)增長,則說明系統(tǒng)存在內(nèi)存泄漏的問題;如果特定類的實例對象個數(shù)隨時間而增長,則說明這個類的實例可能存在泄漏情況。比如一個Activity被關(guān)掉之后,其內(nèi)存的引用對象會在下次GC回收[3]的時候通過回收算法計算,如果這部分內(nèi)存已經(jīng)屬于可回收的對象,那么這些垃圾對象會被一并回收,內(nèi)存未泄漏趨勢圖如圖1所示。
圖1 內(nèi)存未泄漏趨勢圖
內(nèi)存泄漏趨勢圖如圖2所示。在重復(fù)打開關(guān)閉某個應(yīng)用程序的時候,內(nèi)存一直在向上爬升,也就是說每次關(guān)閉這個Activity的時候,有些應(yīng)該釋放的內(nèi)存并沒有被釋放掉。由此我們可以確定這個應(yīng)用程序存在著內(nèi)存泄漏的問題。
圖2 內(nèi)存泄漏趨勢圖
2.2 內(nèi)存泄漏的位置定位
查找內(nèi)存泄漏一種比較徹底的方法就是代碼走查,我們可以一行一行地分析對象的創(chuàng)建去留等等[4],但會很耗時間也比較迷茫。這里可以通過Eclipse Memory Analyzer Tool(MAT)工具來定位內(nèi)存泄漏的位置,該方法只適用于Java層的查找,對C/C++沒用,也就是說只針對于被虛擬機(jī)來管理的進(jìn)程和內(nèi)存。MAT的解析文件是.hprof文件,這個文件里面存放了某進(jìn)程的內(nèi)存快照,MAT通過解析.hprof文件就會自動生成一個內(nèi)存泄漏推測報告,通過分析這個報告就可以準(zhǔn)確定位到有可能存在內(nèi)存泄漏的具體位置。
然而,還有一些內(nèi)存泄漏通過MAT是查不出來的,比如native的代碼,對C/C++是無能為力的,對于這些問題本文并沒有做過多的研究。
在編寫應(yīng)用程序的過程中,對于BraodcastReceiver、ContentObserver、FileObserver在Activity onDestory或者某類聲明周期結(jié)束之后一定要注銷掉,否則這個Activity類會被系統(tǒng)強(qiáng)引用,不會被內(nèi)存回收。
在定義成員變量時,不要直接對Activity進(jìn)行引用而作為成員變量。如果不得不這么做,那么可以用private Weak Reference
在應(yīng)用程序中,很多內(nèi)存泄漏是由于循環(huán)引用而造成的,比如a中包含了b,b中包含了c,c中又包含a,這樣只要一個對象存在,那么其他對象肯定會一直常駐內(nèi)存。因此,在編寫應(yīng)用程序時要從邏輯上來分析是否需要這樣的設(shè)計。
Bitmap對象不再使用時,調(diào)用recycle()方法釋放內(nèi)存。如果一個Bitmap對象比較占內(nèi)存,當(dāng)它不再被使用的時候,可以調(diào)用Bitmap.recycle()方法回收此對象的像素所占用的內(nèi)存,這個不是必須的,可視情況而定。
還要注意釋放對象的引用。當(dāng)一個生命周期較短的對象A,被一個生命周期較長的對象B保有其引用的情況下,在A的生命周期結(jié)束時,要在B中清除掉對A的引用。
4 內(nèi)存監(jiān)測工具DDMS和內(nèi)存分析工具M(jìn)AT
4.1 內(nèi)存監(jiān)測工具DDMS
我們在開發(fā)Android應(yīng)用程序時,很容易造成內(nèi)存的泄漏,這時需要一些工具來幫助我們檢查代碼中是否存在會造成內(nèi)存泄漏的不良代碼。在Android tools的DDMS里面帶有一個內(nèi)存監(jiān)測工具Heap,用它來監(jiān)測應(yīng)用程序使用內(nèi)存的情況,這里需要和Eclipse配合使用。利用 Heap工具監(jiān)測應(yīng)用進(jìn)程使用內(nèi)存情況的方法如下:
① 首先啟動Eclipse,切換到DDMS透視圖,并確認(rèn)Devices視圖、Heap視圖都已打開。將要測試的設(shè)備(比如手機(jī))通過USB數(shù)據(jù)線連接到電腦上,連接成功后,會在DDMS的Devices視圖界面中顯示手機(jī)設(shè)備的序列號,以及設(shè)備中正在運(yùn)行的部分進(jìn)程信息。
評論