Android Activity泄漏问题解决方案
2016-07-15 15:23
344 查看
我们先来看一个抽象的Activity伪代码:
如果我们想确认这个Activity是否存在泄漏,只需让其覆盖Object的finalize方法,在里面添加一句Logcat打印:
然后运行你的项目,打开这个Activity,然后按返回,退出Activity,然后通过IDE强制触发一次GC操作:
然后查看Logcat,是否有对应的打印,就能确认Activity是否存在内存泄漏了:有打印,则无内存泄漏,无打印则肯定有内存泄漏了!
然后再进出一次Activity,触发GC,确认Activity泄漏已经不存在。然后再把业务逻辑一个个补回来,直到泄漏现象重现。
这样我们就能100%的找出泄漏的原因所在。
如果我们想确认这个Activity是否存在泄漏,只需让其覆盖Object的finalize方法,在里面添加一句Logcat打印:
然后运行你的项目,打开这个Activity,然后按返回,退出Activity,然后通过IDE强制触发一次GC操作:
然后查看Logcat,是否有对应的打印,就能确认Activity是否存在内存泄漏了:有打印,则无内存泄漏,无打印则肯定有内存泄漏了!
定位泄漏原因
定位泄漏原因这个就是比较简单粗暴的排除法,首先把所有复杂业务逻辑注视掉,直到内存泄漏现在不存在:然后再进出一次Activity,触发GC,确认Activity泄漏已经不存在。然后再把业务逻辑一个个补回来,直到泄漏现象重现。
这样我们就能100%的找出泄漏的原因所在。
知识点
这里用到的一个知识点就是Java中Object类的finalize方法。当GC准备回收一个Java Object(所有Java对象都是Object的子类)的时候,GC会调用这个Object的finalize方法。这个方法有点类似于C++中析构函数,本意是让你用来回收一些已经不需要的资源的(主要是针对Native资源)。其实Java日常开发中,并不鼓励依赖于这个方法来实现回收的逻辑,因为如果你重度依赖于finalize的话,finalize本身也有可能造成内存泄漏,但是我们这里只是用来作为是否已经回收的依据,还是可以的。总结
虽然此方法看起来比较简单无脑,但是简单粗暴啊,也不失为给开发的一种便利的自测方式,不用其他工具就可以快速的确定你这次的需求新增的Activity是否存在泄漏,权当减少自己Bug数的一种方法吧!相关文章推荐
- 使用C++实现JNI接口需要注意的事项
- Android IPC进程间通讯机制
- Android Manifest 用法
- [转载]Activity中ConfigChanges属性的用法
- Android之获取手机上的图片和视频缩略图thumbnails
- Android之使用Http协议实现文件上传功能
- Android学习笔记(二九):嵌入浏览器
- android string.xml文件中的整型和string型代替
- i-jetty环境搭配与编译
- android之定时器AlarmManager
- android wifi 无线调试
- Android Native 绘图方法
- Android java 与 javascript互访(相互调用)的方法例子
- android 代码实现控件之间的间距
- android FragmentPagerAdapter的“标准”配置
- Android"解决"onTouch和onClick的冲突问题
- android:installLocation简析
- android searchView的关闭事件
- SourceProvider.getJniDirectories