先给出一个内存泄漏的栗子
我们在项目中经常会创建一些工具类，例如获取屏幕信息的、SharePreference、图片压缩等工具类，而且我们往往写成单利，例如下面的CommonUtils所示。（防止内存泄漏就应该使用Application Context）
/**
* 测试内存泄漏
*/
public class CommonUtils {
private static CommonUtils sInstance;
private Context mContext;
private CommonUtils(Context context) {
mContext = context;
}
public static CommonUtils getInstance(Context context) {
if (sInstance == null) {
sInstance = new CommonUtils(context);
}
return sInstance;
}
}
在Activity中，我们经常这样使用：
public class LeakActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_leak);
CommonUtils.getInstance(this);
}
}
这就是很典型的单例模式导致内存对象无法释放而导致Activity内存泄露，因为CommonUtils持有Activity的引用，导致Activity不能被正常回收。即Destroy之后还存在。
我们先通过这一个简单的栗子来演示一遍工具的使用，然后总结一下：在不知道哪里发生内存泄漏的时候，我们应该如何利用工具提供的线索去分析。
Android Studio Android Monitor的使用
首先运行我们的项目，然后打开Android Monitor。如下图所示：
Android Monitor可以看到手机的一些信息，我们目前最关心的是Memory这一板块。这里可以看到我们APP进程的空闲内存和已经分配的内存，如图右边所示。在图的前面部分我们可以看到分配内存突然减少，这就是GC在回收垃圾了。
内存抖动：当内存发生很频繁地起伏的时候，这就是内存抖动，这时候就要注意是不是内存泄漏引起的了。
左上角有三个小工具，这里先介绍前面两个，第一个是手动触发GC，第二个是拍堆内存快照。
我们手动触发GC多几次，等到内存稳定下来的时候，然后拍快照，这时候AS会自动拉去hprf文件并且打开。然后我们旋转屏幕，触发内存泄漏，然后再重复这样的操作。
我们可以通过选择查看APP、Image、Zygote的内存信息，也可以选择按照包名来展示。这里需要解释的参数有：单位是byte
Total Count：对象的总个数。
Heap Count：对象在堆内存中的个数。
Sizeof:对象本身的大小。
Shallow Size：所有该类的对象的大小总和。
Retained Size：所有该类的对象释放的时候（包括引用了该类的对象的释放）释放的总内存之和。
Depth：对象被引用的深度，如果没有被引用，则深度为0；直接引用，深度为1，如此类推。
Dominating Size：对象管辖的内存大小。
下面我们进行分析，按照包名分类展示，找到我们的LeakActivity，可以在右边看到有几个LeakActivity实例。在下面我们可以看到LeakActivity的引用树。在蓝色的部分就要注意了，可以看大我们的CommonUtils通过mContext直接引用了LeakActivity，蓝色高亮部分一般代表内存泄漏。我们也可以通过点击右边的Analyzer Tasks右上角的绿色三角形来进行自动分析。
其实我们可以直接看Activity的数量（2）就可以推测出来是否有内存泄漏了。
延伸
我们多旋转几次，内存里面是会有多个Activity实例的，但是一旦内存比较紧张的时候，只会保留第0个和最后创建的那个。
中间的几个Activity会被回收，因为并没有被CommonUtil引用。
CommonUtil与Activity的生命周期不一致，不一致的时候有可能造成泄漏。
实际项目比较复杂，需要引用树一个一个分析，引用是否合理，然后看代码。工具只是提供线索。
MAT的使用
MAT是Memory Analyzer Tools的简称，是专门用于Java内存分析的工具，是Eclipse的插件，也可以单独使用，可以从官网下载。
首先我们要把AS生成的hprof文件转为为标准的文件，当然，如果是ADT的话，可以直接拿来用。如下图示：
然后在MAT中打开：我们一般选择内存泄漏分析报告。
这里可以看到一些有问题的报告，例如Resources类被系统的类加载器加载进来了，并且占用了很大内存空间。但是一般这个界面没有什么卵用。
下面这个界面比较重要：
Histogram：Lists number of instances per class
内存中对象个数和大小，最主要看这个，其余都是看大概。
Dominator Tree: List the biggest objects and what they keep alive.
列举大对象，同时它们依赖什么，是否还存在。
这个界面可以看到跟AS差不多的东西，这里不详细介绍。
我们先回顾一下GC回收的算法：
以”GC Roots”的对象作为起始点向下搜索，搜索形成的路径称为引用链，当一个对象到GC Roots没有任何引用链相连（即不可达的），则该对象被判定为可以被回收的对象，反之不能被回收。也写出了内存泄露的原因：对象无用了，但仍然可达（未释放），垃圾回收器无法回收。那些相互引用而不能被回收的就是内存泄漏的对象。
我们搜索LeakActivity，然后点击右键，选择Merge Shortest Path to GC Roots，选择exclude all phantom/weak/soft etc.references, 意思是查看排除虚引用/弱引用/软引用等的引用链 （这些引用最终都能够被GC干掉，所以排除）。最后可以看到还有两个对象引用了LeakActivity，其中输入法是系统的BUG。
这里也可以看到该对象被谁引用了，或者引用了谁，incmming outcomming
快照的对比
当我们怀疑执行了某一个动作导致APP卡慢的时候，可以在这个动作之前先拍一个快照，执行动作之后再拍一个，然后利用MAT进行对比。
在Navigation History界面中，选中 History add to compare basket，点击右上角的红色叹号执行对比分析，通过对比分析，看看执行动作前后对象的内存分配、数量差异也可以发现问题。
最后，其实我们也可以直接通过Android Monitor的内存报告，看View以及Activity的数量来进行预判：
当app退出的时候，这个进程里面所有的对象应该就都被回收了，尤其是很容易被泄露的（View，Activity）是否还内存当中。
可以让app退出以后，查看系统该进程里面的所有的View、Activity对象是否为0.
工具：使用AndroidStudio--AndroidMonitor--System Information--Memory Usage查看Objects里面的views和Activity的数量是否为0.
总结
往往做项目的时候情况非常复杂，或者项目做得差不多了想起来要性能优化检查下内存泄露。
如何找到项目中存在的内存泄露的这些地方呢？
1.确定是否存在内存泄露
1)Android Monitors的内存分析
最直观的看内存增长情况，知道该动作是否发生内存泄露。（内存抖动）
动作发生之前：GC完后内存1.4M; 动作发生之后：GC完后内存1.6M
2)使用MAT内存分析工具
MAT分析heap的总内存占用大小来初步判断是否存在泄露
Heap视图中有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。
在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，
一般情况下，这个值的大小决定了是否会有内存泄漏。
我们反复执行某一个操作并同时执行GC排除可以回收掉的内存，注意观察data object的Total Size值，
正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
反之如果代码中存在没有释放对象引用的情况，随着操作次数的增多Total Size的值会越来越大。
那么这里就已经初步判断这个操作导致了内存泄露的情况。
2.先找怀疑对象(哪些对象属于泄露的)
MAT对比操作前后的hprof来定位内存泄露是泄露了什么数据对象。（这样做可以排除一些对象，不用后面去查看所有被引用的对象是否是嫌疑）
快速定位到操作前后所持有的对象哪些是增加了(GC后还是比之前多出来的对象就可能是泄露对象嫌疑犯)
技巧：Histogram中还可以对对象进行Group，比如选择Group By Package更方便查看自己Package中的对象信息。
3.MAT分析hprof来定位内存泄露的原因所在。(哪个对象持有了上面怀疑出来的发生泄露的对象)
1）Dump出内存泄露“当时”的内存镜像hprof，分析怀疑泄露的类；
2）把上面2得出的这些嫌疑犯一个一个排查个遍。步骤：
(1)进入Histogram，过滤出某一个嫌疑对象类
(2)然后分析持有此类对象引用的外部对象（在该类上面点击右键List Objects--->with incoming references）
(3)再过滤掉一些弱引用、软引用、虚引用，因为它们迟早可以被GC干掉不属于内存泄露
(在类上面点击右键Merge Shortest Paths to GC Roots--->exclude all phantom/weak/soft etc.references)
(4)逐个分析每个对象的GC路径是否正常
此时就要进入代码分析此时这个对象的引用持有是否合理，这就要考经验和体力了！
（比如上课的例子中：旋转屏幕后MainActivity有两个，肯定MainActivity发生泄露了，
那谁导致他泄露的呢？原来是我们的CommonUtils类持有了旋转之前的那个MainActivity他，
那是否合理？结合逻辑判断当然不合理，由此找到内存泄露根源是CommonUtils类持有了该MainActivity实例造成的。
怎么解决？罪魁祸首找到了，怎么解决应该不难了，不同情况解决办法不一样，要靠你的智慧了。）
