?引言
　　Android應用程序中內存使用的問題經常容易被忽視，在傳統的編程語言中（例如C語言），回收內存的任務是由程序本身來完成的，程序可以顯式分配和釋放變量所占用的內存。Android［1］應用程序采用Java編程語言編寫，而Java區別于其他語言的一個重要優點就是它通過垃圾收集器（Garbage Collection，GC） 自動管理內存的回收，Java程序員只需通過內存分配操作創建對象，而無須關心對象占用的空間是如何被收回的。因此很多程序員認為在Java中不必擔心內存泄漏的問題，然而實際并非如此，Java中仍然存在著內存泄漏。Android應用程序運行在嵌入式系統中，而嵌入式系統中內存的總量非常有限，因此如何合理地規避“內存泄露”問題也就顯得十分關鍵。
　　1　造成Android應用程序內存泄漏的原因
　　1.1　引用沒釋放造成的內存泄露
　　（1） 注冊沒有取消造成的內存泄漏
　　這種Android的內存泄露比純Java的內存泄漏還要嚴重，因為其他一些Android程序可能引用系統的Android程序的對象（比如注冊機制）。即使Android程序已經結束了，但是別的應用程序仍然還有對Android程序的某個對象的引用，泄漏的內存依然不能被垃圾回收。
　　（2） 集合中對象沒有關閉造成的內存泄漏
　　通常把一些對象的引用加入到了集合中，當我們不需要該對象時，并沒有把它的引用從集合中清理掉，慢慢地這個集合就會越來越大。如果這個集合是靜態的話，那情況就會更嚴重。
　　1.2　資源對象沒有關閉造成的內存泄漏
　　資源對象比如Cursor、File文件等往往都用了一些緩沖，在不使用的時候應該及時關閉它們，以便它們的緩沖及時回收內存。這些緩沖不僅存在于Java虛擬機內，還存在于Java虛擬機外，如果僅僅是把它的引用設置為空，而不關閉它們，那么往往會造成內存泄漏。
　　一些不良代碼造成的內存壓力原因如下：
　　◆ Bitmap沒有調用recycle（ ）；
　　◆ 構造Adapter時，沒有使用緩存的convertView；
　　◆ ThreadLocal使用不當；
　　◆ 其他。
　　2　內存泄漏的檢測及定位
　　2.1　內存泄漏的檢測
　　Android應用程序是基于虛擬機的，其內存管理都是由Dalvik［2］代為管理，GC的回收不是及時的。一個正常的應用程序在其運行穩定后其內存的占用量是基本穩定的，不應該是無限制的增長。同樣，對任何一個類的對象的使用個數也有一個相對穩定的上限，不應該是持續增長的。當我們持續地觀察某個應用程序運行過程中使用內存的大小和各實例的個數時，如果內存的大小持續增長，則說明系統存在內存泄漏的問題；如果特定類的實例對象個數隨時間而增長，則說明這個類的實例可能存在泄漏情況。比如一個Activity被關掉之后，其內存的引用對象會在下次GC回收［3］的時候通過回收算法計算，如果這部分內存已經屬于可回收的對象，那么這些垃圾對象會被一并回收，內存未泄漏趨勢圖如圖1所示。
　　
　　圖1　內存未泄漏趨勢圖
　　內存泄漏趨勢圖如圖2所示。在重復打開關閉某個應用程序的時候，內存一直在向上爬升，也就是說每次關閉這個Activity的時候，有些應該釋放的內存并沒有被釋放掉。由此我們可以確定這個應用程序存在著內存泄漏的問題。