关于Activity调用Ondestroy()方法之后内存管理器为什么没有释放占用资源
2015-07-29 20:43
429 查看
最近在研究activity 执行了finish之后为什么还有很多资源没有释放的问题,关于这个原因的产生,最直接的想法就是activity里面还有很多资源没有手动释放,因为大家知道,activity只不过是一个高度抽象的UI组件,他仅仅只是一个控制界面的功能,包括分发touch时间还有一些列的作用,展示界面的工作是交给DecorView下的所有view以及viewGroup,所以我们可以认为activity持有了所有在他内部绑定的view的引用,但是这些view不仅仅只有activity的引用,还有其他的引用(具体还有其他的哪些引用,最近仍旧在研究。),所以根据这个原理,当activity执行ondestroy方法的时候,activity这个对象确实是被回收了,但是对象绑定的view却没有被回收,我们还需要手动去回收他们。
?
比如类似这样的,在ondestory方法里面做释放控件的操作,这样我们就可以把占用内存比较大的那些空间都释放出来,关于这个大家可以通过ddms 或者 mat来 cause gc 查看 反复开启一个activity的时候 app的内存占用情况。
光做到以上这点还是不够的,因为通过查看内存我发现还有零点几M的内存仍然没有被释放,于是又查了很多资料,发现问题出在contentView上面,关于ContentView的绑定XML机制的内容大家可以去看《老罗的Android之旅》(由于我也没有看完,只是看到了可以给我解决问题的地方就来写博客了。。惭愧一个。),于是网上搜索得到答案,不能在Ondestroy的时候调用setContentView(null),这样很容易报异常的,解决方法是写一个空的layout文件,然后绑定。经过修改之后的ondestry方法如下:
?
另外其实每次都要把绑定的view给释放掉这样很麻烦,有人就问能不能直接通过遍历把所有的view都释放,这个方法尝试过,但是没能成功,接下来我会研究还有哪些对象持有了这些view的引用,然后用另外一种方式释放。
仅供自己记忆。如有错误欢迎指正。(大家态度好一点。。。)
?
光做到以上这点还是不够的,因为通过查看内存我发现还有零点几M的内存仍然没有被释放,于是又查了很多资料,发现问题出在contentView上面,关于ContentView的绑定XML机制的内容大家可以去看《老罗的Android之旅》(由于我也没有看完,只是看到了可以给我解决问题的地方就来写博客了。。惭愧一个。),于是网上搜索得到答案,不能在Ondestroy的时候调用setContentView(null),这样很容易报异常的,解决方法是写一个空的layout文件,然后绑定。经过修改之后的ondestry方法如下:
?
仅供自己记忆。如有错误欢迎指正。(大家态度好一点。。。)
相关文章推荐
- 数据结构之---C++语言实现图的十字链表存储表示
- 可恶的QT隐式共享
- Understanding Convolution in Deep Learning
- System 类的使用
- RHEL6配置multipath多路径软件连存储
- Caffe:cifar10
- HDU 1856~More is better~
- JAVA反射机制
- 在Lucene或Solr中实现高亮的策略
- hdoj 1856 More is better 【并查集】
- UIView的layoutSubviews和drawRect方法何时调用
- 关于windows server 2008 连接oracle数据库响应极慢的问题
- hdoj1051Wooden Sticks
- 泛型初识
- Activity之间参数的传递、隐士意图激活组件
- C/C++源代码的网站
- docker 使用总结
- 图解HTTP-笔记
- Ice_cream's world I
- 菜鸟学习百度地图总结