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

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

?

1 2 3 4 5 6

@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方法如下：

?

1 2 3 4 5 6 7

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

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

摘自：http://my.oschina.net/halfront/blog/407419