Eclipse-mat

2016-11-11  本文已影响0人  一笑yo

Eclipse MAT -- android 内存分析工具

资料

介绍

目前产品中,一直存在内存溢出,频繁崩溃的现象,作为一个门外汉,也需要了解下android 具体的测试方法以及优化策略.
在搜索了许多问题之后,我们把问题定位到内存溢出. 那么如何监控移动设备(android)的内存使用情况呢? 
经过对比,MAT 在我们场景中已经可以作为分析内存的工具来使用.

Eclipse MAT

android studio 自带了android device monitor ,可以提供录制的hprof文件,并且拖拉到studio 中就可以进行简单的分析,but .
看不懂~~ 回过头来 ,还是使用eclipse-mat 来分析内存吧 ,毕竟这个资料会多一些.
studio 录制的 hprof 文件,需要通过SDK 自带的hprof-conv 进行转换之后才可以导入到eclipse-mat 
导入进来之后就需要对eclipse mat 的简单使用有一个初步的了解.

名词解释

  1. Shallow heap : 对象自身占用的内存
  2. Retained heap: 对象自身占用的内存 + 对象直接或间接引用占用的内存
  3. outgoing : 被引用
  4. ingoing: 引用
  5. weak reference: 弱引用 ,简单描述为: 假如一个A 对象依赖一个弱引用的B对象,则,如果A 对象为null ,GC回收时候就会回收A
  6. soft reference: 软引用,如果内存足够就不回收,如果不够就回收,不回收时候该对象可以被程序使用.
  7. phantom reference: 虚引用, 无论从哪里都无法访问虚引用所引用的对象,GC时候,直接就finalize,该对象清除时才加入到Reference队列.
  8. GC root: 生成一个到gc 根 的引用关系
  9. dominator tree: 支配树
  10. heap size: 堆大小,当前空间不足则系统会自动增加大小
  11. Allocated: 堆中已分配大小,即app实际占用内存大小,资源回收后,该值会变小.

内存分析流程

    在android 平台,长期占用一些资源的引用,造成内存不能释放,带来的问题有很多,
    1. Drawable 由于加载Bitmap 导致的问题 ,比如旋转屏幕会销毁当前activity,并创建一个新的activity.
                这时候则会重新加载UI视图和资源.
    2. bitmap 图片过大导致内存溢出,编码上需要options来减小图片
    3. Handler 导致的内存溢出.
    4. AsyncTask 由于非静态匿名内部类导致的内存溢出
    5. Context 上下文的长时间引用导致的内存溢出,如果需要缓存context 则需要使用applicationContext代替.
    
导致内存溢出,也就是内存中存在的引用关系得不到清理所导致的,所以,以后在开发过程中要考虑好对象的应用.
那么配合mat 如何才能找出问题呢?


如何判断内存溢出风险?

    在开启 android device monitor 之后, 我们监控 heap size , allocated 的大小变化,
通过观察,发现没问的应用在几个Activity 切换之后,内存有最初的15M 维持到25-40 之间
设想,是否存在有些对象没有释放,导致内存一直增加不降低呢? 
    通过导出的hprof 文件,我们 看看eclipse-mat 中又有哪些记录呢?
    导入之后,我们发现mat 已经发现了可能产生的问题 Leak Suspects ,当然这是mat 怀疑的,
是否真的有问题,我们需要查看下GC root 依赖关系.
    Problem 1:　Bitmap 的实例 占用了太多的引用. byte[]的积累已经占用了16%.原因是内存中 byte[] (可能)导致了问题.
我们通过histogram 发现排第一的就是byte ,查找下他的引用有哪些(使用list Object) 发现了被很多个实体引用.
通过sort 我们找几个来看看问题,选中一个最大的(Path to GC Roots 去除掉弱引用和软引用),这里出现了一个引用ROOT树, 
找到有一个GuideRedActivity. 那么接下来查看下这个类,为什么一直在内存中. 这个Activity 负责生成一个图片遮罩效果.

    images.setBackgroundResource(xx);

通过一个点击事件频繁调用了 4次 setbackGroundResource,图片大小为640*1200 ,通过分析,这里使用setbackgroundResource 确实
存在内存泄漏的风险.
    Problem 2: 40 byte[] 实例占用了大量的内存12% . 这个问题和上面的Bitmap 问题应该一直,那么我们再来分析一个. 我们通过
以上步骤找到第二个占用内存比较大的byte[] ,查询他的引用,好了,这个是应用首页,所有可能出现的地方比较多,随便找一个看看

    webView.loadUrl(xx)

这是一个webview 页面,这个加载了资源为什么也没有释放呢? 
查找原因 [webview oom](https://my.oschina.net/zhibuji/blog/100580) 

    Problem 3: 62个ImageView实例 占用的内存太大.为什么ImageView 没有销毁呢? 并且还这么大呢? 通过跟踪发现,ImageView有些属于
启动之后就依赖的,所以导致他不会消失,特别是如果ImageView 每次都加载图片, 这个时候就(有可能)导致内存占用比较大,并且不销毁的情况.

内存解决方案

程序本身存在内存溢出的风险,那么,如何才能管控呢?
Bitmap一定要特别注意.如果使用之后,可以调用recycle 进行回收.bitmap = null 使其变成虚引用,加快GC回收
关于contenxt 的引用,尽量避免你使用.使用applicationContext 代替,比如 toast ,View 中都要注意避免使用contenxt,
最好全局中static 一个applicationcontext对象方便非Activity使用.
尽量避免使用非静态的匿名内部类.如果是线程则最好维护一个整个应用的线程池.

开发建议

开发人员可以通过 leakcanary 来运行debug测试内存溢出问题.

上一篇下一篇

猜你喜欢

热点阅读