android 記憶體洩露總結

一、引用沒釋放造成的記憶體洩露

1.註冊沒有取消造成的記憶體洩露

2.集合容器物件沒有清理造成的記憶體洩露，僅僅是顯示的賦為了null

3.不要保留對context----activity長時間的引用，對activity的引用，一定要確保擁有和activity一樣的生命週期

4.如果你不想控制內部類的生命週期，應該避免在activity中使用非靜態的內部類，而應該是靜態的內部類

二、資源物件沒有關閉造成的記憶體洩露

1.cursor 未及時關閉

2.網路連線、io流沒有及時關閉

3.handlerthread 沒有quit

三、一些不良**造成的記憶體壓力

1、bitmap物件，使用完成後沒有呼叫recycle（）方法，告訴gc優先**

2、盡量採用stringbuff而不是string，string物件在程序處理時是新建乙個物件。

3、threadlocal使用不當，如果我們粗暴的把threadlocal設定null，而不呼叫renmove方法或者set（null）。那麼就可能造成threadlocal繫結的物件長期也不能夠**，因而產生洩露

4.adapter getview方法未使用contantview快取機制

5.webview 物件沒有銷毀

6.typedarray recycle

7.gridview的濫用，gridview和listview的實現方式一樣，gridview的view不是及時建立，而全部儲存在記憶體中，比如gridview有100項，雖然我們只能看10項，但是其實整個100項都是在記憶體中

8.new message的洩露，盡量採用message.obtain();

9.android 直到4.1.3 之前的版本，通知欄api 都存在記憶體洩露bug，反覆呼叫 notificationmanager.notify 方法會造成手機宕機重啟。繞過此bug 的方法是每次呼叫notify 時都必須 new 乙個新的remoteviews。