内存泄漏我们戏称为霸气侧漏、 如何分析定位霸气侧漏呢，这里有一套 “还我漂漂拳”
内功心法口诀如下
- why
为什么内存泄漏分析？- what
内存泄漏是什么？
有哪些工具？- how
分析内存泄漏的切入点
工具的使用- ** 一些个人观点**
非静态内部类不是内存泄漏
有不对的或者不到位的地方，请指出来。
1. Why
不忘初心、方得始终。
1.1. 为什么内存泄漏分析？
1.1.1. 开发者？测试？
开发者亲自做测试，这不是抢测试工程师的饭碗么？这本来就是测试工程师干的事情，而且花这么多时间干测试的工作还不如多写几行代码，实现几个功能来的实在。 有人肯定会嗤之以鼻的说，包括以前的我年少无知也都有过这种想法... 那么开发者做内存泄漏分析测试有什么好处呢？
1、减少被测试怼的机会；
2、在发现以及解决bug的同时能帮助我们思考bug产生的原因,再次写代码时能提高我们代码的健壮性减少bug产生率。
3、对代码更加负责。
2. what
分析她、了解她
2.1. 内存泄漏是什么？
是什么？
有个巡抚（省长）犯了大罪，皇帝要将他斩首，没想到这个大臣投靠了敌方国家，出逃走了。皇帝没有杀死巡抚，而这个巡抚管理的省城也还是被巡抚霸占着，皇帝干不掉巡抚，也没有办法回收省城。
以上的 例子中： 巡抚（产生内存泄漏的对象） ，敌方国家（持久对象/） 巡抚霸占的省城（对象占用的内存），皇帝（GC回收机制）
小结 1：
业务上需要被销毁的对象，却被持久对象非法持有了引用，导致内存不再被控制，这就是我们定义的内存泄漏。
2.2. 产生的一些总结
为什么产生？ 嘿嘿嘿， 当然是先百度呀，我们要站在前人的经验上更上一层楼。
以下是我归纳的一些常见的内存泄漏场景：
小结2：
- 非静态内部类 和 匿名内部类 持有外部对象的引用
- 单例模式下 context 的引用
- 资源未及时关闭（BroadCassReceviver、Cursor、Bitmap、IO流、自定义属性未回收、等等）
- 监听类为及时关闭
- 无线循环动画（轮播等）
2.3. 有哪些工具帮助我们定位内存泄漏
- Android Monitors
- MAT内存分析工具
- Allaction Tracing 追踪内存分配
- Leak Lancary 内存泄漏检测
- Lint 检查
3. how
用行动征服她
3.1. 分析内存泄漏的切入点
波动法
查看内存实时占用情况，根据内存波动大概定位内存泄漏分析的地方
比较法
比较动作发生前节点、以及动作发生后回到动作发生前节点 内存的占用情况。
侧重大内存法
这个就不用怎么解释了，重点关注大内存，因为大内存的内存泄漏更容易导致程序OOM
无脑法
就完全看工具的检测分析，比如lint；
3.2. 工具使用
4. 一些个人观点
关于非静态内部类内存泄漏
个人感觉并非严格意义上的内存泄漏, 因为它的内存泄漏是暂时的， 比如内部handler 大家都知道handler的运行机制是：MessageQueue -> message -> 操作 -> UI; 当我们再“操作”这步的时候，我们退出界面，实际上 UI还是被我们handler所引用着，但当我们的操作完成以后，UI还是可以被系统回收掉的。
大家可以去实验一下。
希望我的文章不会误导在观看的你，如果有异议的地方欢迎讨论和指正。
如果能给观看的你带来收获，那就是最好不过了。
