在使用java语音之前总听人家说java是面向对象的，内存只需要要申请不用释放，当我开始做Android用上java后我才知道java的回收其实是这样的：
闲话不多说，我们来个栗子：
我直接从项目中抽取部分代码来说明，代码中涉及到三个Activity：LoadingActivity、MainActivity和SettingsActivity，三个Activity均包含一个大背景图。LoadingActivity加载资源后启动MainActivity并finish掉自己，MainActivity点击按钮后跳转到SettingsActivity。
三个Activity打开一遍，按回退键返回到桌面，然后执行两次GC(第一次释放Activity对象，第二次释放Activity对象引用的背景图)后在Android studio中Monitors的Memory占用情况：
剩下的约35M内存怎么GC都无法回收，重新启动app，在MainActivity中不打开SettingsActivity直接回退到桌面然后执行GC，看到内存占用是这样的：
可以看出内存占用不到20M了，证明SettingsActivity存在内存泄漏了。
在Activity中添加打印也可以看到SettingsActivity调用了onDestroy()但在GC时并没有被释放(finalize()方法没被调用)
插个题外话，这个app占用内存这么大是因为使用图片背景，有人推荐用imege-loader，我也尝试用了一下，使用默认设置内存占用是小了那么一点点(大概10m左右吧)不过我这项目占用主要就是三个大的背景图，况且在调用释放缓存后实际上内存也并没有立刻被回收，而且使用imege-loader就要在原本的布局上再嵌套一层放一个match_parent的ImageView我感觉这样并没有优化我app的性能(貌似更严重了，多绘制一层的样子)，这些都是题外话，看官选择性跳过就行。
我们在打开SettingsActivity后返回到桌面，执行完GC后点击Dump Java Heap:
这里我们可以看出来SettingsActivity之所以没被释放是因为其内部类DbUpdateListener有实例化对象(非静态内部类对象会持有父类的引用，Reference Tree第二行)没有被回收。DbUpdateListener对象又被DatabaseUpdate的listener和SettingsActivity的dbUpdateListener引用，我们现在来看看代码(代码是从我项目中截取出关键部分)：
public class SettingsActivity extends Activity{
private DatabaseUpdate dbUpdate;
private DbUpdateListener dbUpdateListener;
@Override
protected void onCreate(Bundle savedInstanceState) {
dbUpdate=DatabaseUpdate.get();
dbUpdateListener=newDbUpdateListener();
dbUpdate.setListener(dbUpdateListener);
}
@Override
protected void onDestroy() {
super.onDestroy();
//findViewById(R.id.activity_settings).setBackgroundResource(0);
Log.d(TAG,"onDestroy "+this);
}
private class DbUpdateListener implements DatabaseUpdateListener {
...
}
@Override
protected voidfinalize()throwsThrowable {
super.finalize();
Log.d(TAG,"finalize "+this);
}
}
public class DatabaseUpdate {
private static DatabaseUpdateinstance;
private DatabaseUpdateListenerlistener;
public staticDatabaseUpdate get(){
if(null==instance){
synchronized(DatabaseUpdate.class) {
if(null==instance)
instance=new DatabaseUpdate();
}
}
return instance;
}
}
从代码中可以看出在SettingsActivity的onCreate方法中实例化了一个内部类对象DbUpdateListener，将其注册给了DatabaseUpdate对象，而DatabaseUpdate是一个单例，从而造成了SettingsActivity无法被回收的问题。在onDestroy()中将DbUpdateListener注销掉后再试，内存可以正常被回收了，Heap中SettingsActivity也没有被引用了：
结尾再补个题外话，这个app内存泄漏问题主要就是大背景图的资源无法释放，如果要加一个保险机制的话就在onDestroy()中将背景设置为空(findViewById(R.id.activity_settings).setBackgroundResource(0))，这样即使Activity没被回收背景资源的回收也不会受影响。在程序中我尝试过移除资源的引用后调用System.gc()并不能触发GC(小米4 Android6.0)，所以这个我感觉没必要手动调用。
为何要降低内存消耗？其一是用户使用会卡，其二就是系统优先杀掉占用内存大的。
