Android 內(nèi)存泄漏研究及調(diào)試

1、Android 內(nèi)存泄漏調(diào)試一、概述Java 編程中經(jīng)常容易被忽視，但本身又十分重要的一個問題就是內(nèi)存使用的問題。Android 應(yīng)用主要使用Java 語言編寫，因此這個問題也同樣會在Android 開發(fā)中出現(xiàn)。本文不對Java 編程問題做探討，而是對于在Android 中，特別是應(yīng)用開發(fā)中的此類問題進(jìn)行整理。二、Android(Java)中常見的容易引起內(nèi)存泄漏的不良代碼Android 主要應(yīng)用在嵌入式設(shè)備當(dāng)中，而嵌入式設(shè)備由于一些眾所周知的條件限制，通常都不會有很高的配置，特別是內(nèi)存是比較有限的。如果我們編寫的代碼當(dāng)中有太多的對內(nèi)存使用不當(dāng)?shù)牡胤?，難免會使得我們的設(shè)備運(yùn)行緩慢，甚至是死機(jī)。

2、為了能夠使得Android應(yīng)用程序安全且快速的運(yùn)行，Android 的每個應(yīng)用程序都會使用一個專有的Dalvik 虛擬機(jī)實(shí)例來運(yùn)行，它是由Zygote 服務(wù)進(jìn)程孵化出來的，也就是說每個應(yīng)用程序都是在屬于自己的進(jìn)程中運(yùn)行的。一方面，如果程序在運(yùn)行過程中出現(xiàn)了內(nèi)存泄漏的問題，僅僅會使得自己的進(jìn)程被kill 掉，而不會影響其他進(jìn)程（如果是system_process 等系統(tǒng)進(jìn)程出問題的話，則會引起系統(tǒng)重啟）。另一方面Android 為不同類型的進(jìn)程分配了不同的內(nèi)存使用上限，如果應(yīng)用進(jìn)程使用的內(nèi)存超過了這個上限，則會被系統(tǒng)視為內(nèi)存泄漏，從而被kill 掉。Android 為應(yīng)用進(jìn)程分配的內(nèi)存上限如下所

3、示：位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分腳本# Define the oom_adj values for the classes of processes that can be# killed by the kernel. These are used in ActivityManagerService.setprop ro.FOREGROUND_APP_ADJ 0setprop ro.VISIBLE_APP_ADJ 1setprop ro.SECONDARY_SERVER_ADJ 2setprop ro.BACKUP_APP

4、_ADJ 2setprop ro.HOME_APP_ADJ 4setprop ro.HIDDEN_APP_MIN_ADJ 7setprop ro.CONTENT_PROVIDER_ADJ 14setprop ro.EMPTY_APP_ADJ 15# Define the memory thresholds at which the above process classes will# be killed. These numbers are in pages (4k).setprop ro.FOREGROUND_APP_MEM 1536setprop ro.VISIBLE_APP_MEM 2

5、048setprop ro.SECONDARY_SERVER_MEM 4096setprop ro.BACKUP_APP_MEM 4096setprop ro.HOME_APP_MEM 4096setprop ro.HIDDEN_APP_MEM 5120setprop ro.CONTENT_PROVIDER_MEM 5632setprop ro.EMPTY_APP_MEM 6144# Write value must be consistent with the above properties.# Note that the driver only supports 6 slots, so

6、we have HOME_APP at the# same memory level as services.write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15write /proc/sys/vm/overcommit_memory 1write /proc/sys/vm/min_free_order_shift 4write /sys/module/lowmemorykiller/parameters/minfree1536,2048,4096,5120,5632,6144# Set init its forked c

7、hildren's oom_adj.write /proc/1/oom_adj -16正因?yàn)槲覀兊膽?yīng)用程序能夠使用的內(nèi)存有限，所以在編寫代碼的時候需要特別注意內(nèi)存使用問題。如下是一些常見的內(nèi)存使用不當(dāng)?shù)那闆r。(一) 查詢數(shù)據(jù)庫沒有關(guān)閉游標(biāo)描述：程序中經(jīng)常會進(jìn)行查詢數(shù)據(jù)庫的操作，但是經(jīng)常會有使用完畢Cursor 后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小，對內(nèi)存的消耗不容易被發(fā)現(xiàn)，只有在常時間大量操作的情況下才會復(fù)現(xiàn)內(nèi)存問題，這樣就會給以后的測試和問題排查帶來困難和風(fēng)險。示例代碼：Cursor cursor = getContentResolver().query(uri .);if

8、(cursor.moveToNext() . .修正示例代碼：Cursor cursor = null;try cursor = getContentResolver().query(uri .);if (cursor != null && cursor.moveToNext() . . finally if (cursor != null) try cursor.close(); catch (Exception e) /ignore this(二) 構(gòu)造Adapter時，沒有使用緩存的convertView描述：以構(gòu)造ListView 的BaseAdapter 為例，在Ba

9、seAdapter 中提高了方法：public View getView(int position, View convertView, ViewGroup parent)來向ListView 提供每一個item 所需要的view 對象。初始時ListView 會從BaseAdapter 中根據(jù)當(dāng)前的屏幕布局實(shí)例化一定數(shù)量的view 對象，同時ListView 會將這些view 對象緩存起來。當(dāng)向上滾動ListView 時，原先位于最上面的list item 的view 對象會被回收，然后被用來構(gòu)造新出現(xiàn)的最下面的list item。這個構(gòu)造過程就是由getView()方法完成的，getVie

10、w()的第二個形參View convertView 就是被緩存起來的list item 的view 對象(初始化時緩存中沒有view對象則convertView 是null)。由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新實(shí)例化一個View 對象的話，即浪費(fèi)資源也浪費(fèi)時間，也會使得內(nèi)存占用越來越大。ListView 回收listitem 的view 對象的過程可以查看:android.widget.AbsListView.java -> void addScrapView(View scrap) 方法。示例代碼：public View getV

11、iew(int position, View convertView, ViewGroup parent) View view = new Xxx(.);. .return view;修正示例代碼：public View getView(int position, View convertView, ViewGroup parent) View view = null;if (convertView != null) view = convertView;populate(view, getItem(position);. else view = new Xxx(.);.return view

12、;(三) Bitmap對象不在使用時調(diào)用recycle()釋放內(nèi)存描述：有時我們會手工的操作Bitmap 對象，如果一個Bitmap 對象比較占內(nèi)存，當(dāng)它不在被使用的時候，可以調(diào)用Bitmap.recycle()方法回收此對象的像素所占用的內(nèi)存，但這不是必須的，視情況而定?？梢钥匆幌麓a中的注釋：/* Free up the memory associated with this bitmap's pixels, and mark the* bitmap as "dead", meaning it will throw an exception if getPixe

13、ls() or* setPixels() is called, and will draw nothing. This operation cannot be* reversed, so it should only be called if you are sure there are no* further uses for the bitmap. This is an advanced call, and normally need* not be called, since the normal GC process will free up this memory when* the

14、re are no more references to this bitmap.*/(四) 釋放對象的引用描述：這種情況描述起來比較麻煩，舉兩個例子進(jìn)行說明。示例A：假設(shè)有如下操作public class DemoActivity extends Activity . .private Handler mHandler = .private Object obj;public void operation() obj = initObj();.MarkmHandler.post(new Runnable() public void run() useObj(obj););我們有一個成員變量o

15、bj，在operation()中我們希望能夠?qū)⑻幚韔bj 實(shí)例的操作post 到某個線程的MessageQueue 中。在以上的代碼中，即便是mHandler 所在的線程使用完了obj所引用的對象，但這個對象仍然不會被垃圾回收掉，因?yàn)镈emoActivity.obj 還保有這個對象的引用。所以如果在DemoActivity 中不再使用這個對象了，可以在Mark的位置釋放對象的引用，而代碼可以修改為：. .public void operation() obj = initObj();.final Object o = obj;obj = null;mHandler.post(new Runna

16、ble() public void run() useObj(o);. .示例B:假設(shè)我們希望在鎖屏界面(LockScreen)中，監(jiān)聽系統(tǒng)中的電話服務(wù)以獲取一些信息(如信號強(qiáng)度等)，則可以在LockScreen 中定義一個PhoneStateListener 的對象，同時將它注冊到TelephonyManager 服務(wù)中。對于LockScreen 對象，當(dāng)需要顯示鎖屏界面的時候就會創(chuàng)建一個LockScreen 對象，而當(dāng)鎖屏界面消失的時候LockScreen 對象就會被釋放掉。但是如果在釋放LockScreen 對象的時候忘記取消我們之前注冊的PhoneStateListener 對象，則會

17、導(dǎo)致LockScreen 無法被垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會由于大量的LockScreen 對象沒有辦法被回收而引起OutOfMemory,使得system_process 進(jìn)程掛掉?？傊?dāng)一個生命周期較短的對象A，被一個生命周期較長的對象B 保有其引用的情況下，在A 的生命周期結(jié)束時，要在B 中清除掉對A 的引用。(五) 其他Android 應(yīng)用程序中最典型的需要注意釋放資源的情況是在Activity 的生命周期中，在onPause()、onStop()、onDestroy()方法中需要適當(dāng)?shù)尼尫刨Y源的情況。由于此情況很基礎(chǔ)，在此不詳細(xì)說明，具體可以查看官方文檔對Act

18、ivity 生命周期的介紹，以明確何時應(yīng)該釋放哪些資源。三、內(nèi)存監(jiān)測工具DDMS -> Heap無論怎么小心，想完全避免bad code 是不可能的，此時就需要一些工具來幫助我們檢查代碼中是否存在會造成內(nèi)存泄漏的地方。Android tools 中的DDMS 就帶有一個很不錯的內(nèi)存監(jiān)測工具Heap(這里我使用eclipse 的ADT 插件，并以真機(jī)為例，在模擬器中的情況類似)。用Heap 監(jiān)測應(yīng)用進(jìn)程使用內(nèi)存情況的步驟如下：1. 啟動eclipse 后，切換到DDMS 透視圖，并確認(rèn)Devices 視圖、Heap 視圖都是打開的；2. 將手機(jī)通過USB 鏈接至電腦，鏈接時需要確認(rèn)手機(jī)是處

19、于“USB 調(diào)試”模式，而不是作為“Mass Storage”；3. 鏈接成功后，在DDMS 的Devices 視圖中將會顯示手機(jī)設(shè)備的序列號，以及設(shè)備中正在運(yùn)行的部分進(jìn)程信息；4. 點(diǎn)擊選中想要監(jiān)測的進(jìn)程，比如system_process 進(jìn)程；5. 點(diǎn)擊選中Devices 視圖界面中最上方一排圖標(biāo)中的“Update Heap”圖標(biāo)；6. 點(diǎn)擊Heap 視圖中的“Cause GC”按鈕；7. 此時在Heap 視圖中就會看到當(dāng)前選中的進(jìn)程的內(nèi)存使用量的詳細(xì)情況如圖所示。說明：a) 點(diǎn)擊“Cause GC”按鈕相當(dāng)于向虛擬機(jī)請求了一次gc 操作；b) 當(dāng)內(nèi)存使用信息第一次顯示以后，無須再不斷的點(diǎn)

20、擊“Cause GC”，Heap 視圖界面會定時刷新，在對應(yīng)用的不斷的操作過程中就可以看到內(nèi)存使用的變化；c) 內(nèi)存使用信息的各項(xiàng)參數(shù)根據(jù)名稱即可知道其意思，在此不再贅述。如何才能知道我們的程序是否有內(nèi)存泄漏的可能性呢。這里需要注意一個值：Heap 視圖中部有一個Type 叫做data object，即數(shù)據(jù)對象，也就是我們的程序中大量存在的類類型的對象。在data object 一行中有一列是“Total Size”，其值就是當(dāng)前進(jìn)程中所有Java 數(shù)據(jù)對象的內(nèi)存總量，一般情況下，這個值的大小決定了是否會有內(nèi)存泄漏?？梢赃@樣判斷：a) 不斷的操作當(dāng)前應(yīng)用，同時注意觀察data object 的

21、Total Size 值；b) 正常情況下Total Size 值都會穩(wěn)定在一個有限的范圍內(nèi)，也就是說由于程序中的的代碼良好，沒有造成對象不被垃圾回收的情況，所以說雖然我們不斷的操作會不斷的生成很多對象，而在虛擬機(jī)不斷的進(jìn)行GC 的過程中，這些對象都被回收了，內(nèi)存占用量會會落到一個穩(wěn)定的水平；c) 反之如果代碼中存在沒有釋放對象引用的情況，則data object 的Total Size 值在每次GC后不會有明顯的回落，隨著操作次數(shù)的增多Total Size 的值會越來越大，直到到達(dá)一個上限后導(dǎo)致進(jìn)程被kill 掉。d) 此處已system_process 進(jìn)程為例，在我的測試環(huán)境中syste

22、m_process 進(jìn)程所占用的內(nèi)存的data object 的Total Size 正常情況下會穩(wěn)定在2.22.8 之間，而當(dāng)其值超過3.55 后進(jìn)程就會被kill?？傊?，使用DDMS 的Heap 視圖工具可以很方便的確認(rèn)我們的程序是否存在內(nèi)存泄漏的可能性。四、內(nèi)存分析工具M(jìn)AT(MemoryAnalyzerTool)如果使用DDMS 確實(shí)發(fā)現(xiàn)了我們的程序中存在內(nèi)存泄漏，那又如何定位到具體出現(xiàn)問題的代碼片段，最終找到問題所在呢？如果從頭到尾的分析代碼邏輯，那肯定會把人逼瘋，特別是在維護(hù)別人寫的代碼的時候。這里介紹一個極好的內(nèi)存分析工具- Memory Analyzer Tool(MAT)。M

23、AT 是一個Eclipse 插件，同時也有單獨(dú)的RCP 客戶端。官方下載地址、MAT 介紹和詳細(xì)的使用教程請參見：/mat，在此不進(jìn)行說明了。另外在MAT 安裝后的幫助文檔里也有完備的使用教程。在此僅舉例說明其使用方法。我自己使用的是MAT 的eclipse 插件，使用插件要比RCP 稍微方便一些。使用MAT 進(jìn)行內(nèi)存分析需要幾個步驟，包括：生成.hprof 文件、打開MAT 并導(dǎo)入.hprof文件、使用MAT 的視圖工具分析內(nèi)存。以下詳細(xì)介紹。(一) 生成.hprof文件生成.hprof 文件的方法有很多，而且Android 的不同版本中生成.hprof 的方式

24、也稍有差別，我使用的版本的是2.1，各個版本中生成.prof 文件的方法請參考：/?p=platform/dalvik.git;a=blob_plain;f=docs/heapprofiling.html;hb=HEAD。1. 打開eclipse 并切換到DDMS 透視圖，同時確認(rèn)Devices、Heap 和logcat 視圖已經(jīng)打開了；2. 將手機(jī)設(shè)備鏈接到電腦，并確保使用“USB 調(diào)試”模式鏈接，而不是“Mass Storage“模式；3. 鏈接成功后在Devices 視圖中就會看到設(shè)備的序列號，和設(shè)備中正在運(yùn)行的部分進(jìn)程；4. 點(diǎn)擊

25、選中想要分析的應(yīng)用的進(jìn)程，在Devices 視圖上方的一行圖標(biāo)按鈕中，同時選中“Update Heap”和“Dump HPROF file”兩個按鈕；5. 這是DDMS 工具將會自動生成當(dāng)前選中進(jìn)程的.hprof 文件，并將其進(jìn)行轉(zhuǎn)換后存放在sdcard 當(dāng)中，如果你已經(jīng)安裝了MAT 插件，那么此時MAT 將會自動被啟用，并開始對.hprof文件進(jìn)行分析；注意：第4 步和第5 步能夠正常使用前提是我們需要有sdcard，并且當(dāng)前進(jìn)程有向sdcard中寫入的權(quán)限(WRITE_EXTERNAL_STORAGE)，否則.hprof 文件不會被生成，在logcat 中會顯示諸如ERROR/dalvik

26、vm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied.的信息。如果我們沒有sdcard，或者當(dāng)前進(jìn)程沒有向sdcard 寫入的權(quán)限（如system_process）， 那我們可以這樣做：6. 在當(dāng)前程序中，例如framework 中某些代碼中，可以使用android.os.Debug 中的：public static void dumpHprofData(String fileName) throws IOException方法，手動的指定.hprof 文件的生成位置。例如：xxxButt

27、on.setOnClickListener(new View.OnClickListener() public void onClick(View view) android.os.Debug.dumpHprofData("/data/temp/myapp.hprof");. .上述代碼意圖是希望在xxxButton 被點(diǎn)擊的時候開始抓取內(nèi)存使用信息，并保存在我們指定的位置：/data/temp/myapp.hprof，這樣就沒有權(quán)限的限制了，而且也無須用sdcard。但要保證/data/temp 目錄是存在的。這個路徑可以自己定義，當(dāng)然也可以寫成sdcard 當(dāng)中的某個路徑。(二) 使用MAT導(dǎo)入.hprof文件1. 如果是eclipse 自動生成的.hprof 文件，可以使用MAT 插件直接打開（可能是比較新的ADT才支持）；2. 如果eclipse 自動生