轉(zhuǎn)自：http://www.linuxidc.com/Linux/2011-10/44785.htm

因為Android使用Java作為開發(fā)語言，很多人在使用會不注意內(nèi)存的問題。

于是有時遇到程序運(yùn)行時不斷消耗內(nèi)存，最終導(dǎo)致OutOfMemery，程序異常退出，這就是內(nèi)存泄露導(dǎo)致的。

我們現(xiàn)在就來總結(jié)一下可能導(dǎo)致內(nèi)存泄露的情況：

查詢數(shù)據(jù)庫而沒有關(guān)閉Cursor

在Android中，Cursor是很常用的一個對象，但在寫代碼是，經(jīng)常會有人忘記調(diào)用close, 或者因為代碼邏輯問題狀況導(dǎo)致close未被調(diào)用。

?

通常，在Activity中，我們可以調(diào)用startManagingCursor或直接使用managedQuery讓Activity自動管理Cursor對象。
但需要注意的是，當(dāng)Activity介紹后，Cursor將不再可用！
若操作Cursor的代碼和UI不同步（如后臺線程），那沒需要先判斷Activity是否已經(jīng)結(jié)束，或者在調(diào)用OnDestroy前，先等待后臺線程結(jié)束。

除此之外，以下也是比較常見的Cursor不會被關(guān)閉的情況：

?

try?{??

????Cursor?c?=?queryCursor();??

????int?a?=?c.getInt(1);??

????......??

????c.close();??

}?catch?(Exception?e)?{??

}??

雖然表面看起來，Cursor.close()已經(jīng)被調(diào)用，但若出現(xiàn)異常，將會跳過close()，從而導(dǎo)致內(nèi)存泄露。

所以，我們的代碼應(yīng)該以如下的方式編寫：

Cursor?c?=?queryCursor();??

try?{??????

????int?a?=?c.getInt(1);??

????......??

}?catch?(Exception?e)?{??

}?finally?{??

????c.close();?//在finally中調(diào)用close(),?保證其一定會被調(diào)用???

}??

?

調(diào)用registerReceiver后未調(diào)用unregisterReceiver().

在調(diào)用registerReceiver后，若未調(diào)用unregisterReceiver，其所占的內(nèi)存是相當(dāng)大的。
而我們經(jīng)常可以看到類似于如下的代碼：

registerReceiver(new?BroadcastReceiver()?{??

????...??

},?filter);?...??

這是個很嚴(yán)重的錯誤，因為它會導(dǎo)致BroadcastReceiver不會被unregister而導(dǎo)致內(nèi)存泄露。

?

未關(guān)閉InputStream/OutputStream

在使用文件或者訪問網(wǎng)絡(luò)資源時，使用了InputStream/OutputStream也會導(dǎo)致內(nèi)存泄露

Bitmap使用后未調(diào)用recycle()

根據(jù)SDK的描述，調(diào)用recycle并不是必須的。但在實際使用時，Bitmap占用的內(nèi)存是很大的，所以當(dāng)我們不再使用時，盡量調(diào)用recycle()以釋放資源。

?

Context泄露

?

這是一個很隱晦的內(nèi)存泄露的情況。
先讓我們看一下以下代碼：

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);??

}??

在這段代碼中，我們使用了一個static的Drawable對象。
這通常發(fā)生在我們需要經(jīng)常調(diào)用一個Drawable，而其加載又比較耗時，不希望每次加載Activity都去創(chuàng)建這個Drawable的情況。
此時，使用static無疑是最快的代碼編寫方式，但是其也非常的糟糕。
當(dāng)一個Drawable被附加到View時，這個View會被設(shè)置為這個Drawable的callback (通過調(diào)用Drawable.setCallback()實現(xiàn))。
這就意味著，這個Drawable擁有一個TextView的引用，而TextView又擁有一個Activity的引用。
這就會導(dǎo)致Activity在銷毀后，內(nèi)存不會被釋放。

轉(zhuǎn)載于:https://www.cnblogs.com/wliangde/p/3712619.html

總結(jié)

以上是生活随笔為你收集整理的Android下常见的内存泄露 经典的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。