什么是内存泄露？
内存泄漏就是一些已经不使用的对象还存在于内存之中且垃圾回收机制无法回收它们，导致它们常驻内存，会使内存消耗越来越大，最终导致程序性能变差。
举例一个典型的内存泄漏的现象：
- 查看当前堆大小为 23.00M
- 添加一个页后堆大小变为 23.40M
- 将添加的一个页删除，堆大小为 23.40M
- 多次操作，结果仍相似，说明添加/删除页存在内存泄漏 (也应注意排除其它因素的影响)
定位内存泄露的方案
- Leakcanary
GitHub地址（https://github.com/square/leakcanary）
使用方法（http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/） - Leakcanary + StrictMode + monkey （推荐）
使用阶段：功能测试完成后，稳定性测试开始时
使用方法：安装集成了Leakcanary的包，跑monkey
收获阶段：一段时间后，会发现出现N个泄露
实战分析：逐条分析每个泄露并改善/修复
StrictMode：查看日志搜索StrictMode关键字 - Adb命令
手动触发GC
通过adb shell dumpsys meminfo packagename -d查看
查看Activity以及View的数量
越接近0越好
对比进入Activity以及View前的数量和退出Activity以及View后的数量判断 - Android Monitor
使用介绍（http://wetest.qq.com/lab/view/?id=99） - MAT
工具的准备
- DDMS（位于 sdk/tools 下）
- hprof-conv (位于 sdk/platform-tools 下)
- MAT（http://www.eclipse.org/mat/downloads.php）
使用MAT定位内存泄露
- 使用DDMS检测内存泄露
-
打开DDMS,选择我们需要分析的应用程序进程，点击Updata Heap按钮DDMS检测内存泄漏
- 选择Heap标签，然后点击Cause GC按钮，点击Cause GC是手动触发JAVA垃圾回收器，如果你发现反复操作某一功能会导致应用程序内存持续增高而不会下降的话，那么就说明这里很有可能发生内存泄漏了。如下图GC按钮点击
主要关注两项数据- Heap Size 堆的大小，当资源增加，当前堆的空余空间不够时，系统会增加堆的大小，若超过上限 (例如64M，视平台和具体机型而定)则会被杀掉
- Allocated 堆中已分配的大小，这是应用程序实际占用的内存大小，资源回收后，此项数据会变小
- 查看操作前后的堆数据，看是否有内存泄漏 对单一操作(比如添加页，删除页)进行反复操作，如果堆的大小一直增加，则有内存泄漏的隐患。
- 利用MAT分析内存堆
-
获取 hprof文件 点击工具栏上的 导出hprof文件
按钮，将内存信息保存成文件。
- 转换 hprof文件，运行hprof-conv xxx-a.hprof xxx-b.hprof
-
用 MAT打开转换后的 hprof文件打开prof文件
- 使用 Histogram 分析内存泄漏
-
点击打开Histograms视图Histograms视图
-
点击对比按钮对比prof文件
点击上图中任意一个文件中用红框标注的按钮, 选择将要与该文件进行对比的另一个文件, 然后就会显示出同一对象在当前文件和另一文件中的数量差了. 如果增加了, 就显示正数, 减少了就显示负数. 结果如下图所示:新增的量
经过对比, 可以发现, 2.hprof 文件中使用红框标注的3个对象 (ImageAdapter$ViewHolder, ImageAdapter 和 StaticLeakActivity), 在数量上都比各自相应在 1.hprof 文件中的数量要多, 说明这3个变量都发生了泄漏. 而且我们还能看到他们各自被泄漏出去的具体数量.
鼠标选中实例右键 选择with incoming references：直接引用的量获取
得到直接引用到该 Activity 的对象列表：直接引用的对象列表
间接引用查看可以在上图的基础上, 对着该对象点右键 —>Path To GC Roots —> exclude weak references, 即可查看到是哪些 GC root 对象间接引用着该对象了.间接引用
查询结果如下结果一
结果二
结果三
由上述3张图可知, 被泄漏的这三种对象都是由于被 sContext 引用而导致泄漏的
