Android内存泄漏总结

学而不思则罔，思而不学则殆

Java中内存泄漏new出来的Object 放在Heap上无法被GC回收

内存分配

分区	说明
静态储存区	编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量
栈区	当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存
堆区	通常存放 new 出来的对象。由 Java 垃圾回收器回收（内存泄露的区域）

四种引用

类型	说明
强引用(StrongReference)	直接new 出来的对象；JVM 宁可抛出 OOM ，也不会让 GC 回收具有强引用的对象；
软引用(SoftReference)	只有在内存空间不足时，才会被回的对象
弱引用(WeakReference)	在 GC 时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存
虚引用(PhantomReference)	任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志

常见内存泄漏

泄漏场景	原理	解决方案
单例造成的内存泄露	单例的静态特性导致其生命周期同应用一样长	将该属性的引用方式改为弱引用;如果传入Context，使用ApplicationContext;
InnerClass匿名内部类	在Java中，非静态内部类 和 匿名类 都会潜在的引用它们所属的外部类，但是，静态内部类却不会。如果这个非静态内部类实例做了一些耗时的操作，就会造成外围对象不会被回收，从而导致内存泄漏	将内部类变成静态内部类;如果有强引用Activity中的属性，则将该属性的引用方式改为弱引用;在业务允许的情况下，当Activity执行onDestory时，结束这些耗时任务;
Activity Context 的不正确使用	被长周期引用	使用ApplicationContext代替ActivityContext，因为ApplicationContext会随着应用程序的存在而存在，而不依赖于activity的生命周期；对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字。Context里如果有线程，一定要在onDestroy()里及时停掉。
Handler引起的内存泄漏	当Handler中有延迟的的任务或是等待执行的任务队列过长，由于消息持有对Handler的引用，而Handler又持有对其外部类的潜在引用，这条引用关系会一直保持到消息得到处理，而导致了Activity无法被垃圾回收器回收，而导致了内存泄露。	可以把Handler类放在单独的类文件中，或者使用静态内部类便可以避免泄露;如果想在Handler内部去调用所在的Activity,那么可以在handler内部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。
注册监听器的泄漏	监听器的周期比Activity长	使用ApplicationContext代替ActivityContext;在Activity执行onDestory时，调用反注册;
Cursor，Stream没有close，View没有recyle	资源性对象比如(Cursor，File文件等)往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏	调用onRecycled()
集合中对象没清理造成的内存泄漏	集合对象引用没有清除	在Activity退出之前，将集合里的东西clear，然后置为null，再退出程序。
WebView造成的泄露	当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。	为webView开启另外一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

建议查看参考链接