前言
- 关于 Android 中内存的处理也算是老生常谈了，虽然 Java 有自己的 GC 机制，但是如果我们自己没有良好的编写代码习惯，在项目逐渐变大的时候，就容易出现内存上的问题。
正文
一、关于内存的一些概念
静态存储区：程序编译时就分配好,在程序整个运行期间都存在,主要存放静态数据和常量。
栈内存：存放基本类型的变量数据，局部变量，和对象的引用，但对象本身不存放在栈中，而是存放在堆（new 出来的对象）或者常量池中（字符串常量对象存放在常量池中。）
堆内存：用来存放动态产生的数据，比如new产生的对象，数组。
方法区：用来存放已被加载的类的信息、常量、静态变量、编译器编译后的代码。
二、四种引用类型
强引用：JVM 宁可抛出 OOM ，也不会让 GC 回收具有强引用的对象，也是我们用的最多的引用类型
软引用：只有在内存空间不足时，才会被回的对象；
弱引用：在 GC 时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存；
虚引用：任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。
怎么用：
- 个人认为，如果只是想避免 OutOfMemory 异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。
- 还有就是可以根据对象是否经常使用来判断。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。
三、关于内存泄露需要注意的地方
内存泄露偶尔有一个倒是无伤大雅，关键是多了就会造成内存溢出，进而导致程序崩溃
创建单例模式的时候 context 对象的引用,使用 application 的 contex
handler：其生命周期与activity不一致，容易导致内存无法正确释放，解决：创建一个 静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息 handler.removeMessage(int what);
非静态内部类和匿名内部类：非静态内部类和匿名内部类会持有外部类的引用，导致外部类的资源无法被正常释放，正确做法是:将此类抽取出来为单例模式,按照单例模式的设计思路处理
集合对象及时清除,在 activity 的 onDestory() 方法中,将集合里面的东西 clear ,然后置为 null。
bitmap 对象不再使用的时候,调用 recycle() 释放内存。
对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
四、内存泄露检测工具
实际上就算我们再怎么仔细，还是会出现内存泄露的可能，所以要借助工具来帮我们检测
MAT (memory analyzer tool)，下载地址： http://www.eclipse.org/mat/downloads.php
LeakCanary，这是一个开源项目，官方文档： https://github.com/square/leakcanary
