内存使用是程序开发无法回避的一个问题。如果我们毫不在意肆意使用，总有一天会为此还账，且痛不欲生...所以应当防患于未然，把内存使用细化到平时的每一行代码中。
内存使用概念较大，本篇先讲对已有app如何检测并发现内存泄露的点，从而进行下一步的修复处理。
之后会写关于内存的理论篇。
内存检测的思路依次是：
静态检测-->工具检测--->修复
内存并非只有OutOfMemory的Crash影响，当可用内存较小时，频繁的gc会导致应用变“卡”
下面我们来讲解下定位内存泄露我们利用的一些工具
0x1.静态代码扫描工具
1.God Eye
Godeyes是一款专注于无线App代码Crash隐患静态扫描的工具，同时提供了固定规则的内存泄露检测。比如我们老生常谈的游标关闭问题，流关闭问题，都可以通过静态代码扫描排查。
涵盖Android和IOS双平台。
官网：http://godeyes.duapp.com/
Android下Studio的使用方式官网介绍的比较清晰，按照步骤来即可
http://godeyes.duapp.com/readme.jsp
0x2 工具检测
1.Android Studio
Studio比Eclipse强大太多了。自带的许多小工具可以辅助我们做许多事情。
自带的Memory Monitors可以进行初步的内存分析。
我们使用它进行
a.发现大内存对象分配的场景
b.发现内存不断增长的场景:
重复操作一个动作，内存一直增加不会减少
c.确定卡顿问题是否因为执行了GC操作造成内存抖动
Java进行GC时，会“stop the world”，也就是jvm会因为执行gc而停止应用程序的执行。单次GC不会占用很多时间，但是显著大量不停的GC必然会占用帧间隔时间段(16ms)，使正常计算，渲染时间变少，从而产生页面卡顿。2.3之后GC改为并发，但仍在开始和结束的时候回阻塞
举一个网上找到的修复内存抖动的例子
定位代码之后，修复了String拼接的问题
2.Java Heap
经过上述简单的了解内存使用情况后，我们可以更进一步分析内存的使用。
点击Initate GC之后 Dump Java Heap，通过Analyzer Task可以分析泄露的Activitys和重复的String
3.Start Allocation tracing ---->Stop Allocation tracing
studio会记录这段时间内的内存分配。
举个简单的例子
如果，我们进入应用后使用一段时间，按照内存占用从大到小依次排列
占用1.25%的是一个NetworkStringHttpResponseHandler的261行 printlog
我们打开代码查看，果然是
4.MAT
如果我们怀念以前Eclipse的mat分析方式，我们也是可以的。Captures后右键选择转成标准的hprof格式
可以通过Eclipse MAT查看内存。
官网：http://www.eclipse.org/mat/downloads.php
0x3 LeakCanary
中文说明：http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/
有个略不好的地方是，LeakCanary一次只能检测一个内存泄露
在Android6.0之上的手机，还是有输入法的内存泄露会被检测出来。之前版本已经被LeakCanary屏蔽。
0x4. 结尾
这大概就是常用的一些用法了，当然这里还要提醒一句，工具是死的，人是活的，工具也没有办法保证一定可以将内存泄漏的原因找出来，还是需要我们对程序的代码有足够多的了解，知道有哪些对象是存活的，以及它们存活的原因，然后再结合工具给出的数据来进行具体的分析，这样才有可能把一些隐藏得很深的问题原因给找出来。