关于Activity调用Ondestroy（）方法之后内存管理器为什么没有释放占用资源

    最近在研究activity 执行了finish之后为什么还有很多资源没有释放的问题，关于这个原因的产生，最直接的想法就是activity里面还有很多资源没有手动释放，因为大家知道,activity只不过是一个高度抽象的UI组件，他仅仅只是一个控制界面的功能，包括分发touch时间还有一些列的作用，展示界面的工作是交给DecorView下的所有view以及viewGroup，所以我们可以认为activity持有了所有在他内部绑定的view的引用，但是这些view不仅仅只有activity的引用，还有其他的引用（具体还有其他的哪些引用，最近仍旧在研究。），所以根据这个原理，当activity执行ondestroy方法的时候，activity这个对象确实是被回收了，但是对象绑定的view却没有被回收，我们还需要手动去回收他们。

@Override
protected void onDestroy() {
    super.onDestroy();
    fruitList = null ;
    layout_bottom= null ;
    }

    比如类似这样的，在ondestory方法里面做释放控件的操作，这样我们就可以把占用内存比较大的那些空间都释放出来，关于这个大家可以通过ddms 或者 mat来 cause gc 查看 反复开启一个activity的时候 app的内存占用情况。

    光做到以上这点还是不够的，因为通过查看内存我发现还有零点几M的内存仍然没有被释放，于是又查了很多资料，发现问题出在contentView上面，关于ContentView的绑定XML机制的内容大家可以去看《老罗的Android之旅》(由于我也没有看完，只是看到了可以给我解决问题的地方就来写博客了。。惭愧一个。)，于是网上搜索得到答案，不能在Ondestroy的时候调用setContentView（null），这样很容易报异常的，解决方法是写一个空的layout文件，然后绑定。经过修改之后的ondestry方法如下：

@Override
protected void onDestroy() {
    super.onDestroy();
    this.setContentView(R.layout.empty_view);
    fruitList = null ;
    layout_bottom= null ;
    }

    另外其实每次都要把绑定的view给释放掉这样很麻烦，有人就问能不能直接通过遍历把所有的view都释放，这个方法尝试过，但是没能成功，接下来我会研究还有哪些对象持有了这些view的引用，然后用另外一种方式释放。

    仅供自己记忆。如有错误欢迎指正。（大家态度好一点。。。）