Android內存泄漏簡介

時間 2019-11-29

原文原文鏈接

前言java

很多人認爲JAVA程序，由於有垃圾回收機制，應該沒有內存泄露。android

其實若是咱們一個程序中，已經再也不使用某個對象，可是由於仍然有引用指向它，垃圾回收器就沒法回收它，固然該對象佔用的內存就沒法被使用，這就形成了內存泄露。若是咱們的java運行好久,而這種內存泄露不斷的發生，最後就沒內存可用了。固然java的，內存泄漏和C/C++是不同的。若是java程序徹底結束後，它全部的對象就都不可達了，系統就能夠對他們進行垃圾回收，它的內存泄露僅僅限於它自己，而不會影響整個系統的。C/C++的內存泄露就比較糟糕了，它的內存泄露是系統級，即便該C/C++程序退出，它的泄露的內存也沒法被系統回收，永遠不可用了，除非重啓機器。shell

Android的一個應用程序的內存泄露對別的應用程序影響不大。爲了可以使得Android應用程序安全且快速的運行，Android的每一個應用程序都會使用一個專有的Dalvik虛擬機實例來運行，它是由Zygote服務進程孵化出來的，也就是說每一個應用程序都是在屬於本身的進程中運行的。Android爲不一樣類型的進程分配了不一樣的內存使用上限，若是程序在運行過程當中出現了內存泄漏的而形成應用進程使用的內存超過了這個上限，則會被系統視爲內存泄漏，從而被kill掉，這使得僅僅本身的進程被kill掉，而不會影響其餘進程（若是是system_process等系統進程出問題的話，則會引發系統重啓）。數據庫

1、引用沒釋放形成的內存泄露緩存

1.一、註冊沒取消形成的內存泄露安全

這種Android的內存泄露比純java的內存泄露還要嚴重，由於其餘一些Android程序可能引用咱們的Anroid程序的對象（好比註冊機制）。即便咱們的Android程序已經結束了，可是別的引用程序仍然還有對咱們的Android程序的某個對象的引用，泄露的內存依然不能被垃圾回收。ide

好比函數

假設咱們但願在鎖屏界面(LockScreen)中，監聽系統中的電話服務以獲取一些信息(如信號強度等)，則能夠在LockScreen中定義一個PhoneStateListener的對象，同時將它註冊到TelephonyManager服務中。對於LockScreen對象，當須要顯示鎖屏界面的時候就會建立一個LockScreen對象，而當鎖屏界面消失的時候LockScreen對象就會被釋放掉。佈局

可是若是在釋放LockScreen對象的時候忘記取消咱們以前註冊的PhoneStateListener對象，則會致使LockScreen沒法被垃圾回收。若是不斷的使鎖屏界面顯示和消失，則最終會因爲大量的LockScreen對象沒有辦法被回收而引發OutOfMemory,使得system_process進程掛掉。測試

雖然有些系統程序，它自己好像是能夠自動取消註冊的（固然不及時），可是咱們仍是應該在咱們的程序中明確的取消註冊，程序結束時應該把全部的註冊都取消掉。

1.二、集合容器對象沒清理形成的內存泄露

咱們一般把一些對象的引用加入到了集合容器（好比ArrayList）中，當咱們不須要該對象時，並無把它的引用從集合中清理掉，這樣這個集合就會愈來愈大。若是這個集合是static的話，那狀況就更嚴重了。

1.三、Context泄漏

所謂的Context泄漏，其實更多的是指Activity泄露，這是一個很隱晦的OutOfMemoryError的狀況。

先看一個Android官網提供的例子：

private static Drawable sBackground;

@Override

protected void onCreate(Bundle state) {

super.onCreate(state);

TextView label = new TextView(this);

label.setText("Leaks are bad");

if (sBackground == null) {

sBackground = getDrawable(R.drawable.large_bitmap);

}

label.setBackgroundDrawable(sBackground);

setContentView(label);

}

這段代碼效率很快，但同時又是極其錯誤的；在第一次屏幕方向切換時它泄露了一開始建立的Activity。當一個Drawable附加到一個 View上時， View會將其做爲一個callback設定到Drawable上。上述的代碼片斷，意味着這個靜態的Drawable擁有一個TextView的引用，

而TextView又擁有Activity（Context類型）的引用，換句話說，Drawable擁有了更多的對象引用。即便Activity被銷燬，內存仍然不會被釋放。

另外，對Context的引用超過它自己的生命週期，也會致使該Context沒法回收，從而致使內存泄漏。因此儘可能使用Application這種Context類型。

這種Context擁有和應用程序同樣長的生命週期，而且不依賴Activity的生命週期。若是你打算保存一個長時間的對象，

而且其須要一個 Context，記得使用Application對象。你能夠經過調用Context.getApplicationContext()或 Activity.getApplication()輕鬆獲得Application對象。

最近遇到一種狀況引發了Context泄漏，就是在Activity銷燬時，裏面有其餘線程沒有停。

總結一下避免Context泄漏應該注意的問題：

1.儘可能使用Application這種Context類型。

2.注意對Context的引用不要超過它自己的生命週期。

3.慎重的對Context使用「static」關鍵字。

4.Context裏若是有線程，必定要在onDestroy()裏及時停掉。

1.四、static關鍵字的濫用

當類的成員變量聲明成static後，它是屬於類的而不是屬於對象的，若是咱們將很大的資源對象（Bitmap，context等）聲明成static，那麼這些資源不會隨着對象的回收而回收，會一直存在，因此在使用static關鍵字定義成員變量的時候要慎重。

1.五、WebView對象沒有銷燬

當咱們不要使用WebView對象時，應該調用它的destory()函數來銷燬它，並釋放其佔用的內存，不然其佔用的內存長期也不能被回收，從而形成內存泄露

1.六、GridView的濫用

GridView和ListView的實現方式不太同樣。GridView的View不是即時建立的，而是所有保存在內存中的。好比一個GridView有100項，雖然咱們只能看到10項，可是其實整個100項都是在內存中的。

2、資源對象沒關閉形成的內存泄露

資源性對象好比（Cursor，File文件等）每每都用了一些緩衝，咱們在不使用的時候，應該及時關閉它們，以便它們的緩衝及時回收內存。它們的緩衝不只存在於java虛擬機內，還存在於java虛擬機外。若是咱們僅僅是把它的引用設置爲null,而不關閉它們，每每會形成內存泄露。由於有些資源性對象，好比SQLiteCursor（在析構函數finalize（）,若是咱們沒有關閉它，它本身會調close()關閉），若是咱們沒有關閉它，系統在回收它時也會關閉它，可是這樣的效率過低了。所以對於資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，而後才置爲null.在咱們的程序退出時必定要確保咱們的資源性對象已經關閉。

程序中常常會進行查詢數據庫的操做，可是常常會有使用完畢Cursor後沒有關閉的狀況。若是咱們的查詢結果集比較小，對內存的消耗不容易被發現，只有在常時間大量操做的狀況下才會復現內存問題，這樣就會給之後的測試和問題排查帶來困難和風險。

3、一些不良代碼成內存壓力

有些代碼並不形成內存泄露，可是它們，或是對沒使用的內存沒進行有效及時的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內存，對內存的回收和分配形成很大影響的，容易迫使虛擬機不得不給該應用進程分配更多的內存，形成沒必要要的內存開支。

3.一、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.二、構造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;