尹文剛，楊斌

（西南交通大學 信息科學與技術(shù)學院，成都 610031）

引 言

Android應(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)心對象占用的空間是如何被收回的。因此很多程序員認為在Java中不必擔心內(nèi)存泄漏的問題，然而實際并非如此，Java中仍然存在著內(nèi)存泄漏。Android應(yīng)用程序運行在嵌入式系統(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)存泄漏還要嚴重，因為其他一些Android程序可能引用系統(tǒng)的Android程序的對象（比如注冊機制）。即使Android程序已經(jīng)結(jié)束了，但是別的應(yīng)用程序仍然還有對Android程序的某個對象的引用，泄漏的內(nèi)存依然不能被垃圾回收。

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

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

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

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

一些不良代碼造成的內(nèi)存壓力原因如下：

◆Bitmap沒有調(diào)用recycle（）；

◆構(gòu)造Adapter時，沒有使用緩存的convertView；

◆ThreadLocal使用不當；

◆其他。

2 內(nèi)存泄漏的檢測及定位

2.1 內(nèi)存泄漏的檢測

Android應(yīng)用程序是基于虛擬機的，其內(nèi)存管理都是由Dalvik[2]代為管理，GC的回收不是及時的。一個正常的應(yīng)用程序在其運行穩(wěn)定后其內(nèi)存的占用量是基本穩(wěn)定的，不應(yīng)該是無限制的增長。同樣，對任何一個類的對象的使用個數(shù)也有一個相對穩(wěn)定的上限，不應(yīng)該是持續(xù)增長的。當我們持續(xù)地觀察某個應(yīng)用程序運行過程中使用內(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.2 內(nèi)存泄漏的位置定位

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

圖2 內(nèi)存泄漏趨勢圖

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

3 規(guī)避內(nèi)存泄漏的方法

在編寫應(yīng)用程序的過程中，對于BraodcastReceiver、ContentObserver、FileObserver在Activity onDestory或者某類聲明周期結(jié)束之后一定要注銷掉，否則這個Activity類會被系統(tǒng)強引用，不會被內(nèi)存回收。

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

在應(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)存，當它不再被使用的時候，可以調(diào)用Bitmap.recycle（）方法回收此對象的像素所占用的內(nèi)存，這個不是必須的，可視情況而定。

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

4 內(nèi)存監(jiān)測工具DDMS和內(nèi)存分析工具MAT

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)用進程使用內(nèi)存情況的方法如下：

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

② 然后選中想要監(jiān)測的進程，比如system＿process進程，進而選中Devices視圖界面中最上方一排圖標中的“Update Heap”圖標，點擊 Heap視圖中的“Cause GC”按鈕，此時在Heap視圖中就會看到當前選中的進程的內(nèi)存使用量的詳細情況。

③Heap視圖界面會定時地刷新正在監(jiān)測的進程內(nèi)存使用情況，通過不斷地操作被監(jiān)測的應(yīng)用程序來觀察內(nèi)存使用的變化。

那么如何才能知道被監(jiān)測的應(yīng)用程序是否存在內(nèi)存泄漏呢？這里需要注意一個值：Heap視圖中有一個類型值叫做data object，即數(shù)據(jù)對象。在data object一行中有一列是“Total Size”，其值就是當前進程中所有Java數(shù)據(jù)對象的內(nèi)存總量。一般情況下，這個值的大小決定了應(yīng)用程序是否存在內(nèi)存泄漏。我們不斷地操作當前應(yīng)用，同時注意觀察data object的Total Size值，正常情況下Total Size的值都會穩(wěn)定在一個有限的范圍內(nèi)，也就是說由于程序中的代碼良好，沒有造成對象不被垃圾回收的情況，內(nèi)存占用量保持在了一個相對穩(wěn)定的水平；反之，如果代碼中存在沒有釋放對象引用的情況，則data object的Total Size值會隨著操作次數(shù)的增多越來越大，直到到達一個上限后導(dǎo)致進程被殺掉。

通過上面的分析，使用DDMS的Heap視圖工具可以很方便地確認應(yīng)用程序是否存在內(nèi)存泄漏的問題。

4.2 內(nèi)存分析工具MAT

通過DDMS工具可以判斷應(yīng)用程序中是否存在內(nèi)存泄漏的問題，那又如何定位到具體出現(xiàn)問題的代碼片段，最終找到問題所在呢？內(nèi)存分析工具MAT Memory Analyzer Tool解決了這一難題。MAT工具是一個Eclipse插件，同時也有單獨的RCP客戶端，MAT工具的解析文件是.hprof，這個文件存放了某進程的內(nèi)存快照。MAT工具定位內(nèi)存泄漏具體位置的方法如下：

① 生成.hprof文件。Eclipse中生成.hprof文件的方法有很多，不同Android版本中生成.hprof的方式也稍有差別，但它們整體思路是一樣的。我們在DDMS界面選中想要分析的應(yīng)用進程，在Devices視圖界面上方的一行圖標按鈕中，同時選中“Update Heap”和“Dump HPROF file”兩個按鈕，這時DDMS將會自動生成當前選中進程的.hprof文件。

② 將.hprof文件導(dǎo)入到MAT工具中，MAT工具會自動解析并生成報告，點擊“Dominator Tree”按鈕，并按包分組，選擇已定義的包類點右鍵，在彈出的菜單中選擇List objects－>With incoming references，這時會列出所有可疑的類。右鍵點擊某一項，并選擇Path to GC Roots－>exclude weak／soft references，MAT工具會進一步篩選出跟程序相關(guān)的所有內(nèi)存泄漏的類。這樣就可以追蹤到某一個產(chǎn)生內(nèi)存泄漏的類的具體代碼中。

使用MAT內(nèi)存分析工具查找內(nèi)存泄漏的根本思路是找到哪個類的對象的引用沒有被釋放，然后分析沒有被釋放的原因，最終定位到代碼中哪些片段存在著內(nèi)存泄漏。

結(jié) 語

Android應(yīng)用程序中內(nèi)存泄漏是一個特別重要但又難以解決的問題，不再有用的對象被其他依然有用的對象所引用是導(dǎo)致內(nèi)存泄漏的主要原因。程序員良好的編程風格和專業(yè)的檢測工具可以有效地減少內(nèi)存泄漏的問題，比如上面介紹的內(nèi)存監(jiān)測工具DDMS和內(nèi)存分析工具MAT。但如何更好地避免甚至消除內(nèi)存泄漏、如何解決因內(nèi)存泄漏而導(dǎo)致的Android應(yīng)用程序系統(tǒng)性能下降問題，將是內(nèi)存泄漏相關(guān)領(lǐng)域的重要研究方向。

[1] Android project official.Android project[EB／OL].[2012－02].http：／／www.android.com／.

[2] 韓超，梁泉.Android系統(tǒng)原理及開發(fā)要點詳解[M].北京：電子工業(yè)出版社，2010.

[3] 孔凡良.Java程序內(nèi)存泄漏研究[J].科技廣場，2009（9）：33－35.

[4] 賈曉霞，吳際，金茂忠.Java程序內(nèi)存泄漏綜述[J].計算機應(yīng)用研究，2006（9）：1－3.