Android下常见的内存泄露
轉自:http://www.linuxidc.com/Linux/2011-10/44785.htm
因為Android使用Java作為開發語言,很多人在使用會不注意內存的問題。
于是有時遇到程序運行時不斷消耗內存,最終導致OutOfMemery,程序異常退出,這就是內存泄露導致的。我們現在就來總結一下可能導致內存泄露的情況:
查詢數據庫而沒有關閉Cursor
在Android中,Cursor是很常用的一個對象,但在寫代碼是,經常會有人忘記調用close, 或者因為代碼邏輯問題狀況導致close未被調用。
通常,在Activity中,我們可以調用startManagingCursor或直接使用managedQuery讓Activity自動管理Cursor對象。
但需要注意的是,當Activity介紹后,Cursor將不再可用!
若操作Cursor的代碼和UI不同步(如后臺線程),那沒需要先判斷Activity是否已經結束,或者在調用OnDestroy前,先等待后臺線程結束。
除此之外,以下也是比較常見的Cursor不會被關閉的情況:
所以,我們的代碼應該以如下的方式編寫:
調用registerReceiver后未調用unregisterReceiver().
在調用registerReceiver后,若未調用unregisterReceiver,其所占的內存是相當大的。
而我們經常可以看到類似于如下的代碼:
未關閉InputStream/OutputStream
在使用文件或者訪問網絡資源時,使用了InputStream/OutputStream也會導致內存泄露
Bitmap使用后未調用recycle()
根據SDK的描述,調用recycle并不是必須的。但在實際使用時,Bitmap占用的內存是很大的,所以當我們不再使用時,盡量調用recycle()以釋放資源。
Context泄露
這是一個很隱晦的內存泄露的情況。
先讓我們看一下以下代碼:
在這段代碼中,我們使用了一個static的Drawable對象。
這通常發生在我們需要經常調用一個Drawable,而其加載又比較耗時,不希望每次加載Activity都去創建這個Drawable的情況。
此時,使用static無疑是最快的代碼編寫方式,但是其也非常的糟糕。
當一個Drawable被附加到View時,這個View會被設置為這個Drawable的callback (通過調用Drawable.setCallback()實現)。
這就意味著,這個Drawable擁有一個TextView的引用,而TextView又擁有一個Activity的引用。
這就會導致Activity在銷毀后,內存不會被釋放。
總結
以上是生活随笔為你收集整理的Android下常见的内存泄露的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 宇宙爱宠大机密信用卡额度多少
- 下一篇: 奥海科技和华为的关系 奥海拥有华为等大牌