项目中内存泄露,检测,分析,定位,优化
2015-09-29 17:19
309 查看
昨天我们的项目在中兴手机ZTE Grand S II LTE_403上发现严重的内存泄露。现象是点到包含webview的Activity就会有20M左右的内存占用,关闭Activity后内存仍然没有得到释放。
搜索webview内存泄露的相关文章,把webview改成在代码中动态创建,有效地减少了内存的开销。
然后用开源库leakcanary定位到activity基类中的一个对象
LinkedList sAllActivitys = new LinkedList()
在activity create的时候放入了栈里,finish的时候并没有移除,只有在应用退出的时候才全部移除。这样一来每个持有webview的activity都会一直存在内存中。解决方案是在activity基类中destory的时候,把当前的activity从sAllActivitys移除。
后面美珍用MAT工具分析,发现有大量的Context被activity中的对象持有,GC无法回收这些对象,导致大量的内存泄露。用MAT跟踪到singleTon的GendanManger和LoadUrlManager 的有静态成员变量是Context类型,GC无法回收。解决方案是,改成非静态的成员变量,然后在调用时把全局的ApplicationContext传进去。如果单例中方法要用到activity或service,就只能通过方法参数传进去。
搜索webview内存泄露的相关文章,把webview改成在代码中动态创建,有效地减少了内存的开销。
然后用开源库leakcanary定位到activity基类中的一个对象
LinkedList sAllActivitys = new LinkedList()
在activity create的时候放入了栈里,finish的时候并没有移除,只有在应用退出的时候才全部移除。这样一来每个持有webview的activity都会一直存在内存中。解决方案是在activity基类中destory的时候,把当前的activity从sAllActivitys移除。
后面美珍用MAT工具分析,发现有大量的Context被activity中的对象持有,GC无法回收这些对象,导致大量的内存泄露。用MAT跟踪到singleTon的GendanManger和LoadUrlManager 的有静态成员变量是Context类型,GC无法回收。解决方案是,改成非静态的成员变量,然后在调用时把全局的ApplicationContext传进去。如果单例中方法要用到activity或service,就只能通过方法参数传进去。
相关文章推荐
- 在linux下编写动态链接库的步骤
- 堆排序算法实现
- 服务器多项部署
- [题解+总结]20150929
- SQLSERVER 中事务日志的概念
- 系统级性能分析工具 — Perf
- 二维码之Zxing全解
- 减少GC开销的5个编码技巧
- 企业CIO、CTO必读的34个经典故事
- mysql 日期类型字段相关运算
- 保存图片流
- CSS3动画事件
- Linux内核源码分析--内核启动之(1)zImage自解压过程(Linux-3.0 ARMv7) 【转】
- Nodejs连接MySQL
- PHP抓取采集类snoopy介绍
- 数学四则运算的程序
- 【贪心算法】:经典硬币组成问题,内有问题,搞清楚了支付宝转账5块
- linux操作界面配置
- Wifi生态圈固然好,需要抓住谁?
- 面向对象第一次实验