轉自：
http://hubingforever.blog.163.com/blog/static/17104057920113297362974/
前言
不少人認爲JAVA程序，因爲有垃圾回收機制，應該沒有內存泄露。
其實如果我們一個程序中，已經不再使用某個對象，但是因爲仍然有引用指向它，垃圾回收器就無法回收它，當然該對象佔用的內存就無法被使用，這就造成了內存泄露。如果我們的java運行很久,而這種內存泄露不斷的發生，最後就沒內存可用了。當然java的，內存泄漏和C/C++是不一樣的。如果java程序完全結束後，它所有的對象就都不可達了，系統就可以對他們進行垃圾回收，它的內存泄露僅僅限於它本身，而不會影響整個系統的。C/C++的內存泄露就比較糟糕了，它的內存泄露是系統級，即使該C/C++程序退出，它的泄露的內存也無法被系統回收，永遠不可用了，除非重啓機器。
Android的一個應用程序的內存泄露對別的應用程序影響不大。爲了能夠使得Android應用程序安全且快速的運行，Android的每個應用程序都會使用一個專有的Dalvik虛擬機實例來運行，它是由Zygote服務進程孵化出來的，也就是說每個應用程序都是在屬於自己的進程中運行的。Android爲不同類型的進程分配了不同的內存使用上限，如果程序在運行過程中出現了內存泄漏的而造成應用進程使用的內存超過了這個上限，則會被系統視爲內存泄漏，從而被kill掉，這使得僅僅自己的進程被kill掉，而不會影響其他進程（如果是system_process等系統進程出問題的話，則會引起系統重啓）。
一、引用沒釋放造成的內存泄露
1.1、註冊沒取消造成的內存泄露
這種Android的內存泄露比純java的內存泄露還要嚴重，因爲其他一些Android程序可能引用我們的Anroid程序的對象（比如註冊機制）。即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用，泄露的內存依然不能被垃圾回收。
比如
假設我們希望在鎖屏界面(LockScreen)中，監聽系統中的電話服務以獲取一些信息(如信號強度等)，則可以在LockScreen中定義一個PhoneStateListener的對象，同時將它註冊到TelephonyManager服務中。對於LockScreen對象，當需要顯示鎖屏界面的時候就會創建一個LockScreen對象，而當鎖屏界面消失的時候LockScreen對象就會被釋放掉。
但是如果在釋放LockScreen對象的時候忘記取消我們之前註冊的PhoneStateListener對象，則會導致LockScreen無法被垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會由於大量的LockScreen對象沒有辦法被回收而引起OutOfMemory,使得system_process進程掛掉。
雖然有些系統程序，它本身好像是可以自動取消註冊的（當然不及時），但是我們還是應該在我們的程序中明確的取消註冊，程序結束時應該把所有的註冊都取消掉。
1.2、集合容器對象沒清理造成的內存泄露
我們通常把一些對象的引用加入到了集合容器（比如ArrayList）中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。
二、資源對象沒關閉造成的內存泄露
資源性對象比如（Cursor，File文件等）往往都用了一些緩衝，我們在不使用的時候，應該及時關閉它們，以便它們的緩衝及時回收內存。它們的緩衝不僅存在於java虛擬機內，還存在於java虛擬機外。如果我們僅僅是把它的引用設置爲null,而不關閉它們，往往會造成內存泄露。因爲有些資源性對象，比如SQLiteCursor（在析構函數finalize（）,如果我們沒有關閉它，它自己會調close()關閉），如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。因此對於資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然後才置爲null.在我們的程序退出時一定要確保我們的資源性對象已經關閉。
程序中經常會進行查詢數據庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，對內存的消耗不容易被發現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會給以後的測試和問題排查帶來困難和風險。
三、一些不良代碼成內存壓力
有些代碼並不造成內存泄露，但是它們，或是對沒使用的內存沒進行有效及時的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內存，對內存的回收和分配造成很大影響的，容易迫使虛擬機不得不給該應用進程分配更多的內存，造成不必要的內存開支。
3.1、Bitmap沒調用recycle()
Bitmap對象在不使用時,我們應該先調用recycle()，然後才它設置爲null.
雖然Bitmap在被回收時可以通過BitmapFinalizer來回收內存。但是調用recycle()是一個良好的習慣
在Android4.0之前，Bitmap的內存是分配在Native堆中，調用recycle()可以立即釋放Native內存。
從Android4.0開始，Bitmap的內存就是分配在dalvik堆中，即JAVA堆中的，調用recycle()並不能立即釋放Native內存。但是調用recycle()也是一個良好的習慣。
可以通過dumpsys meminfo命令查看一個進程的內存情況。
示例：adb shell "dumpsys meminfo com.lenovo.robin"
運行結果。
Applications Memory Usage (kB):
Uptime: 18696550 Realtime: 18696541
** MEMINFO in pid 7985 [com.lenovo.robin] **
native dalvik other total
size: 4828 5379 N/A 10207
allocated: 4073 2852 N/A 6925
free: 10 2527 N/A 2537
(Pss): 608 317 1603 2528
(shared dirty): 2240 1896 6056 10192
(priv dirty): 548 36 1276 1860
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 2 AssetManagers: 2
Local Binders: 5 Proxy Binders: 11
Death Recipients: 1
OpenSSL Sockets: 0
SQL
heap: 0 MEMORY_USED: 0
PAGECACHE_OVERFLOW: 0 MALLOC_SIZE: 0
關於內存統計的更多內容請參考《Android內存泄露利器（內存統計篇）》
3.2、構造Adapter時，沒有使用緩存的 convertView
以構造ListView的BaseAdapter爲例，在BaseAdapter中提共了方法：
public View getView(int position, View convertView, ViewGroup parent)
來向ListView提供每一個item所需要的view對象。初始時ListView會從BaseAdapter中根據當前的屏幕布局實例化一定數量的view對象，同時ListView會將這些view對象緩存起來。當向上滾動ListView時，原先位於最上面的list item的view對象會被回收，然後被用來構造新出現的最下面的list item。這個構造過程就是由getView()方法完成的，getView()的第二個形參 View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)。
由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新實例化一個View對象的話，即浪費時間，也造成內存垃圾，給垃圾回收增加壓力，如果垃圾回收來不及的話，虛擬機將不得不給該應用進程分配更多的內存，造成不必要的內存開支。ListView回收list item的view對象的過程可以查看:
android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。
示例代碼：
public View getView(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;
}
3.3、ThreadLocal使用不當