---
layout: post
title: 工具篇-MAT（Memory Analyzer Tool）
description: 让内存泄漏无所遁形 2015-10-08
category: blog
---
## 让内存泄漏无所遁形##
----------
### 一、android 垃圾回收机制的理解 ###
**1、堆和栈** - 至少我们需要知道，我们写的一句代码，它的所需要的内存是放到哪里的。
至于如何释放堆和栈这些细节，此次略过一万字，请大家自行google.
堆heap：内存数据区；简单来说，保存了对象的实例：对象的属性值；对象从堆申请完内存之后会生成一个地址存在stack里边。heap的释放是有jvm回收器来负责的。
栈stack：内存指令区；简单来说，保存了对象的实例里边的属性类型，方法地址，基本类型，如int,float，常量，静态变量都是存在栈里边的。栈里边内存的释放是FILO（first in ,last out）会自动释放。
简单来说,new 创建的一个对象，大部分内存都是放在heap里的。
native 内存 和 ashmem 是不属于jvm gc范围的；
**2、拉贾回收器**
垃圾收集算法的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。
触发条件：
- 手动调用System.gc()，只是建议触发GC,并不保证每次都能GC
- app空闲时，gc的线程优先级是极低的，此时可能会调用GC
- heap内存申请不足时，会强制触发gc，若GC一次还不够，则会进行第二次GC，若内存还不够，则会引发OOM；
**GC引发的直观问题，频繁的GC会导致app的用户体验：UI卡顿，耗电；**
由GC想起的一些编码细节：
(1)能用int就不要用Integer
(2)大对象不用时最好设置为null
(3)尽量避免产出大量的临时对象
(4)使用StringBuffer代替String拼接字符串，String拼接会产生多个垃圾对象
(5)尽量少使用静态变量，静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(6)activity切记不要被全局单例类引用。
----------
###二、MAT-Memory Analyzer tool ###
此工具可以帮我们分析出当前使用的app存留在内存里对象有哪些，并能跟踪到具体的引用对象，从而找出内存泄漏的原因。
1、MAT下载地址：[点击进入](http://www.eclipse.org/mat/downloads.php)
2、了解几个参数的含义：
DDMS参数：
a、Heap Size 系统为此进程所分配堆的大小，当资源增加，
当前堆的空余空间不够时，系统会增加堆的大小，
若超过上限 (例如64M，视平台和具体机型而定)则会被杀掉
b、Allocated 堆中已分配的大小，这是应用程序实际占用的内存大小，资源回收后，此项数据会变小
MAT工具参数：
Histogram:列出当前存留对象和数量
Dominator Tree:由大到小列举出对象以及他们含有什么。
Path to GC Root：显示GC路径的path
###二、MAT-Memory Analyzer tool 使用步骤 ###
1、dump内存文件：
使用DDMS的dump工具dump出你所选中进程的文件；
步骤：
1、选择进程，点击update heap;
2、再手机上打开你想要检测的页面
3、狂戳GC直到Allocated的值不再下降为止；
4、再点击一下update heap带有红色向下箭头的按钮，稍等片刻，会自动弹出文件保存框；
5、保存dump文件到本地；
注意：
1、eclipse自带的mat插件可自动转换dump文件格式，可直接用mat工具打开；
2、IDEA或者android studio dump的出的hprof文件是需要转换的
转换命令是：hprof-conv src.hprof dest.hprof，完了之后再用mat工具打开；
打开dump文件后如下图：
2、Dominator Tree如下图：
点击之后如图，此时右键图选中行-》List Objects->with outgoing refrences找到外部应用的对象，如下图：
此处找到了Bitmap的引用对象，然后右键-》GC ROOT PATHS-》exclude weak/soft....排除软弱引用找到强引的对象，如下图：
到这里就能知道是哪里的业务代码导致了内存泄漏，从图中可看出
mBitmap来源于ImageView
ImageView来源-ll_mengban的child
ll_mengban来源-TopicDetailActivity的控件
TopicDetailActivity context被 mmsdk引用了；
从而导致mBitmap无法释放；
然后我们来看看TopicDetailActivity是如何被强引用的：
在TopicDetailActivity的onCreate里执行了
shareController = new ShareController(this);
然而ShareController执行了这个：
public ShareController(Activity activity) {
mActivity = activity;
ShareLoginController.getInstance(mActivity).addLoginListener(this);
}
然而ShareLoginController执行了这个：
public ShareController(Activity activity) {
mActivity = activity;
ShareLoginController.getInstance(mActivity).addLoginListener(this);
}
然而ShareLoginController构造方法执行了这个：
public ShareLoginController(Activity activity) {
if (mController == null) {
try {
mController =(UMSocialService) BeanManager.getSocialService(activity);
} catch (Exception e) {
e.printStackTrace();
}
}
if(loginListeners==null){
loginListeners = new ArrayList<IShareLoginListener>();
}
}
然而UMSocialService里把context传递给了QQsdk，导致了一直被强引用无法GC的原因；
找到了问题，解决办法就是去除这个强引用即可；
-----------------------
博客：http://iceAnson.github.io
http://iceanson.github.io/tool-mat/