记录一次Android内存泄漏事件和解决过程

 

 

昨天打算在车机上测一下长时间跑LogWatcher会不会出问题，跑了一上午之后果然出问题了，程序发生了ANR，然后就在Android studio上看了看程序占用的内存，我靠，居然占用了一百多M，这还了得。我当时掐指一算，肯定是发生了内存泄漏。随后我便重新运行了程序，然后一直观察程序的内存变化。果然让我发现了端倪，程序GC的频率很高，并且每一次GC之后，程序占用的内存都会有小的增幅。这代表什么，这不就是程序一直在增加无用的东西，并且不能被GC回收掉吗。由于以前从来没遇到过OOM的问题，都不知道如何下手，开始没头绪的乱改，毫无效果，最后还是沉下心在网上看了几篇内存泄漏分析的文章，最后终于解决了这个问题。
现在总结出来发生内存泄漏的几个常见因素：
1、BitMap相关，BitMap占用大量内存并且没有正确回收，但是我的程序没用到BitMap啊，排除这条。
2、activity相关，大多是activity的Context对象一直被外部某个对象持有，造成无法正常完成声明周期进行回收，不过我的程序主界面根本就不会回收，除非退出程序，所以也排除这条。
3、奢侈的资源未关闭造成的内存泄漏，对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等这些资源的使用，一定要注意回收的方式，不是仅仅将对象置为空就行的。我发现我的OutputStream的成员变量一直都在new 但是在new之前并没有close，然后我在每次new之前都添加判空条件，如果不为空则先执行close。
 

 

 

对于出现内存泄漏问题，光看代码是不够的，还是需要工具去分析一下，我用的就是Eclipse Memory Analyzer，也就是MAT。因为MAT我也是第一次用，也没有什么经验，如果想了解，这篇文章写得挺详细，解释的挺明白 http://tivan.iteye.com/blog/1487855

这是我用MAT得到的图

这里看到ArrayList占用了2.4M的内存，然后我就点进去看

然后我就在那个类里面找到了那段代码，到这里分析就结束了，不得不说内存分析真是个考验耐心的活，不静下心来真是很难发现代码中的端倪。最后附上一个Android内存泄漏分析的总结连接 https://yq.aliyun.com/articles/3009