1. Bitmap使用完忘記回收
因為bitmap實現(xiàn)部分是通過JNI調(diào)用了Native方法订雾，GC機制無法正城冢回收 Bitmap申請的這部分內(nèi)存空間（API10之前是這樣的炬守，之后分配在Heap中涛救，不過為了兼容老版本...顯示的調(diào)用一下recycled畏邢，讓對象變?yōu)樘撘?也能讓GC到來的幾率更高）；
那Bitmap應(yīng)該怎樣回收呢检吆？
if(bitmap!=null&&!bitmap.isRecycled){
bitmap.recycled(); //回收bitmap
bitmap = null; //使bitmap對象變?yōu)樘撘玫臓顟B(tài)舒萎，讓GC更快的回收
}
2.萬惡的static
被static修飾的變量，生命周期與整個App的生命周期相同蹭沛，需要謹慎使用它來修飾一些耗費資源過多的實例
private static Drawable sBackground;
@Override
protected void onCreate(Bundlestate){
super.onCreate(state);
label.setText("Leaksarebad");
if(sBackground==null){
sBackground=getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
這里的sBackground是個靜態(tài)變量臂寝，也就是說就算Activity銷毀掉了，他也無法被釋放摊灭，就導(dǎo)致了內(nèi)存浪費咆贬，當(dāng)然這還沒完... 當(dāng)Drawable與View綁定之后，Drawable就將View設(shè)置為一個回調(diào)帚呼，由于View中是包含了Context引用的,最終就是 Context發(fā)生內(nèi)存泄露掏缎；
注意：Drawable就將View設(shè)置為一個回調(diào)，是將View引用為一個WeakReference萝挤，這邊是否真正引起內(nèi)存泄漏御毅，還需要測試(API23)。
3.Context的引用問題
當(dāng)然2中也提到了一部分怜珍，咱們再看看這里的
btn_hint.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Toast.makeText(MainActivity.this, "Hello", Toast.LENGTH_SHORT).show();
}
});
是不是很常見端蛆，平時可能也是這樣寫的（將其封裝意義一樣，只要引用了當(dāng)前activity）,你可能想問酥泛，這里有什么問題嗎今豆？
問題在于如果用戶在Toast消失之前，用戶按了返回鍵柔袁，這個Activity就引起了內(nèi)存泄露呆躲，
原因？ Toast持有了當(dāng)前Activity捶索，導(dǎo)致Activity無法被GC銷毀
解決方法：讓Toast持有ApplicationContext;其實只要不是Layout插掂，Context都可以使用ApplicationContext;
關(guān)于Context的tips
- 在單列模式中，如果用到的Context,應(yīng)該使用與App的生命周期相同的ApplicationContext.
- 在非Activity中，正常是不能直接getContext來拿到Context的辅甥，獲取資源有需要靠Context酝润，這時可以考慮在自己的Application中維護一個全局的Context，供無法直接拿到Context的類使用璃弄，省的參數(shù)傳來傳去（視圖相關(guān)的不建議使用ApplicationContext）
在Application中
private static Context mContext;
public static MyApplication getInstance() { //供外界調(diào)用...
return mApplication;
}
@Override
public void onCreate() {
super.onCreate();
mContext = getApplicationContext();
}
4.線程引發(fā)的內(nèi)存泄露
new Thread() {
public void run() {
//網(wǎng)絡(luò)請求
};
}.start();
在Activity中 新建一個線程要销，進行網(wǎng)絡(luò)請求，如果線程未結(jié)束夏块，用戶按了返回鍵疏咐，同樣內(nèi)存泄露
原因：該Thread是匿名內(nèi)部類，所以會隱式的持有外部類（這里也就是Activity）脐供，Handler內(nèi)存泄漏也是這個原因浑塞，詳細可以閱讀我的博客：Handler的終結(jié)者
解決方式：多種多樣; 不使用匿名內(nèi)部類，或者整個應(yīng)用維護一個線程池患民，或者維護一個線程+消息隊列+WeakReference缩举，后兩種都是讓線程不依賴于Activity從而達到避免內(nèi)存泄露的目的；
5.資源未關(guān)閉造成的內(nèi)存泄漏
對于使用了BroadcastReceiver匹颤，ContentObserver仅孩，F(xiàn)ile，Cursor印蓖，Stream辽慕，Bitmap等資源的使用，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷赦肃，否則這些資源將不會被回收溅蛉，造成內(nèi)存泄漏。
