关于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的引用,然后用另外一种方式释放。

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

展开阅读全文

没有更多推荐了,返回首页