android 查找内存泄漏 优化应用

来源:互联网 发布:淘宝大学vip课送工具 编辑:程序博客网 时间:2024/06/06 01:12

前言:

正如标题所言,查找我们项目的内存泄漏,来优化我们的应用,很早以前就想写篇关于应用优化的文章,
只是一直由于各种各样的原因耽误了。前段时间终于有时间来对自己公司的项目进行优化处理,所以把我
在项目中做的处理拿来谈谈。
当然,也是由于项目一些需求导致单个功能/业务页面越来越庞大以及一些设计上面的要求,
从而导致项目有些卡顿,所以不得不来对项目进行优化。
对于项目的优化,网上也有很多介绍,还有许多工具介绍,这里我就不一一介绍了,
自己可以百度或者google看下android性能优化的工具,自己对着自己应用来操作,然后看操作之后你自己
的项目的性能消耗,以及GC操作,因为频繁的GC会导致你的应用卡顿。
android studio自带的Monitors对于你处理应用的性能优化有很大帮助,所以这个必须要看看,或者是用android
device monitor也行,这个看个人喜好了。
android studio 自带的monitors就如上图,1是手动的触发系统的gc操作,2是截图一段操作应用之后的内存消耗,然后
可以查看你自己的应用个个对象的所占的内存情况,同时也能检测你应用的内存泄漏,3是查看你操作应用之后所开线程的
性能消耗。当然这都是我自己的理解,更详细的介绍可以自己搜索下资料看下。我们对于性能优化基本上是看Memory
这一块。
在准备优化的当天,我就问了下朋友,他们公司应用运行时的内存消耗是多少,(这个主要还是要根据自己的应用来分析)
结果问到的大致情况都差不多20-40MB左右的运行内存,当然这是正常使用情况,不包括压力测试那种。然后我打开自己公司
现在做的应用来看下,瞬间懵逼了。
这是刚点开应用运行的时候


然后点击首页的tab之后的情况


这是最后正常使用的时候运气情况。

一看到竟然跑到83MB+然后不掉下去了,瞬间被吓到了,还好手机给力(公司的测试机是vivo的旗舰机),不然就要
瞬间崩溃了。当然这里有一部分原因是我们应用对view的缓存操作有很多(业务要求)。但是不可否认肯定存在内存泄漏的
地方,不然不可能一直增加然后不掉下去。正常的情况下是这样的:


上面那段画红线的就是代表系统执行了GC操作。
我们项目造成这种情况的原因大部分还是内存泄漏以及一些图片问题,所以我先从内存优化上着手。
通过几个内存泄漏检测的工具,查找到了一些内存泄漏的地方,我这仅仅举例出我自己项目中存在的一块严重的内存
泄漏的地方


上图中就是通过android studio内置的monitors工具检测出来我项目中这个SplashActivity出现了内存泄漏,然后通过
代码分析才知道,这个页面存放了3张大图(引导页),然后这个activity一直无法回收所以导致了内存泄漏。
通过代码分析,查找到了具体内存泄漏的地方:


上图是我处理过之后的代码,context原本是activity的引用。我的应用在这个引导页初始化了数据库,这个DBHelper又
是一个单例,所以造成了常见的---单例模式的内存泄漏,DBHelper这个类一直持有SplashActivity的引用导致它无法被
回收。所以更换成了context.getApplicationContext()来代替SplashActivity的引用。
当然项目中有很多要优化的地方,内存泄漏的地方还有很多,我就不一一叙述了,具体还是要看你自己如何去找
,毕竟这些都是根据自己项目而言的。
这里介绍下避免内存泄漏的的方案,大部分情况都是要被回收的对象的引用一直被持有,所以很多容易出现泄漏的
地方针对这个进行处理就能避免很大一部分的内存泄漏

静态内部类以及弱引用的使用,来减少内存泄漏,上图是朋友提供的。
对于图片的处理,一个是服务端一个是客户端,当然缓存是必须的。
服务端来对图片进行压缩处理,这样能大大的减缓我们应用的性能消耗,从根源上解决问题,还有就是根据你自己imageview的宽高来对服务端的图片进行进一步的压缩处理。
还有就是对于线程的开销处理或者说是对于整个项目来进行日志统计,大部分情况下还是用于针对线程的性能开销处理上,就是不适用工具自己来设定log日志。是不是觉得有点奇怪,为什么好好的工具不用非要自己来增加代码量?原因就是这样处理有更多的可控性,同样自己打印log能更细致也更个性化。
 当然,也可以根据你自己应用出现的情况来处理,由于我自己这边项目对view的缓存有很多,所以我这边对这个也做了下处理,持有缓存点击量大的tab页面,还有就是当内存出现紧张的时候优先从缓存中清除一些重要性没那么高的view。


上图就是我这段时间对自己项目优化之后,正常运行时的内存情况,截图有点不清晰,是41.94MB,可以看到从刚开始的83MB+到现在的41.94MB差不多减少的一半的运行内存,这样大大的减缓了应用在手机上的性能消耗。其中
一大部分内存都是通过排查内存泄漏来减少的,当然项目中还存在很多需要优化的地方,所以革命尚未成功还需努力奋斗,性能优化是当你项目一步步迭代的时候必须要进行的工作,希望通过这篇文章,你能享受到对自己项目优化的乐趣。