引言

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

1　造成Android應(yīng)用程序內(nèi)存泄漏的原因

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

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

這種Android的內(nèi)存泄露比純Java的內(nèi)存泄漏還要嚴(yán)重，因?yàn)槠渌恍〢ndroid程序可能引用系統(tǒng)的Android程序的對(duì)象(比如注冊(cè)機(jī)制)。即使Android程序已經(jīng)結(jié)束了，但是別的應(yīng)用程序仍然還有對(duì)Android程序的某個(gè)對(duì)象的引用，泄漏的內(nèi)存依然不能被垃圾回收。

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

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

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

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

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

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

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

◆ ThreadLocal使用不當(dāng);

◆ 其他。

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

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

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

圖1　內(nèi)存未泄漏趨勢(shì)圖

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

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

2.2　內(nèi)存泄漏的位置定位

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

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

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

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

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

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

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

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

4　內(nèi)存監(jiān)測(cè)工具DDMS和內(nèi)存分析工具M(jìn)AT

4.1　內(nèi)存監(jiān)測(cè)工具DDMS

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

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

② 然后選中想要監(jiān)測(cè)的進(jìn)程，比如system_process進(jìn)程，進(jìn)而選中Devices視圖界面中最上方一排圖標(biāo)中的“Update Heap”圖標(biāo)，點(diǎn)擊Heap視圖中的“Cause GC”按鈕，此時(shí)在Heap視圖中就會(huì)看到當(dāng)前選中的進(jìn)程的內(nèi)存使用量的詳細(xì)情況。

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

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

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

4.2　內(nèi)存分析工具M(jìn)AT

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

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

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

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

結(jié)語(yǔ)

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