上一篇只是简单的介绍内存泄漏和工具简单介绍，那么在实际项目中是非常复杂的我们并不知道是否存在泄漏，哪里存在泄漏。接下来就来分析，其实工具只是辅助，还是拼的经验。
1.怎么知道是否存在泄漏？
1)Android Monitors的内存分析
最直观的看内存增长情况，知道该动作是否发生内存泄露。
比如：该动作发生之前，GC完后内存为1.2M。而动作发生之后，GC完后内存1.5M。（A得Activity进入B得Activity，之后再返回A,看内存情况）
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中的对象信息。
如下图对比之后开始过滤
可以看到泄漏的对象
2.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发生泄露了，
那谁导致他泄露的呢？原来是我们的MyUtils类持有了旋转之前的那个MainActivity他，
那是否合理？结合逻辑判断当然不合理，由此找到内存泄露根源是MyUtils类持有了该MainActivity实例造成的。
怎么解决？罪魁祸首找到了，怎么解决应该不难了，不同情况解决办法不一样，要靠你的智慧了。）
1.判断一个应用里面内存泄露避免得很好，怎么看？
当app退出的时候，这个进程里面所有的对象应该就都被回收了，尤其是很容易被泄露的（View，Activity）是否还内存当中。可以让app退出以后，查看系统该进程里面的所有的View、Activity对象是否为0。
退出之后多次gc,点击搜索 样式按钮
会生成一个文件，里面如下内容
说明存在泄漏
2.内存溢出（OOM）
当应用占用的heap资源超过了Dalvik虚拟机分配的内存就会内存溢出。
