常见内存泄漏场景

本文据《Android应用性能最佳实践优化（罗彧成）》总结而成。

1. 资源性对象未关闭
   资源性对象（如Cursor、File等）往往都用到缓存，在不使用时，应及时关闭它们，以便它们的内存数据能够及时回收。有些资源性对象，如SQLite Cursor，如果没有手动关闭它，在系统回收它时也会关闭之，但这样的效率太低，还是建议不使用时立即手动调用close()函数，将其关闭，然后再置为null。在程序退出时，一定要确保资源性对象已经关闭。

2. 注册对象未注销
   如果事件注册后未注销，会导致观察者列表中维持着对对象的引用，阻止垃圾回收，这一般发生在注册广播接收器、注册观察者等。

3. 类的静态变量持有大数据对象
   静态变量长期维持对对象的引用，阻止垃圾回收，如果静态变量持有大的数据对象，如Bitmap等，就很容易引起内存不足等问题。

4. 非静态内部类的静态实例
   非静态内部类会维持一个对外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期持有对外部类的引用，阻止外部类被系统回收。
   为避免这种情况发生，可以将内部类设置为静态内部类或将内部类抽取出来并封装为一个单例，如果需要使用Context，在没有特殊要求的情况下使用Application的Context，如果需要使用Activity的Context，就在用完之后置空让GC可以回收，否则还是会内存泄漏。

5. Handler临时性内存泄漏
   Handler对象通过发送Message实现线程之间的交互，Message发出之后存储在MessageQueue中，有些Message也不是马上就被处理。在Message中存在一个target，它是Handler的一个引用，Message在Queue中存在的时间过长，就会导致Handler无法被回收。如果Handler是非静态的，则会导致Activity或Service不会被回收。
   未避免这种内存泄漏，需要做到以下两个地方：

1. 使用一个静态Handler内部类，然后对Handler持有的对象使用弱引用，这样在回收时，也可以回收Handler持有的对象。
2. 在Activity的Destroy或者Stop时，应移除消息队列中的消息，避免Looper线程的消息队列中有待处理的消息需要处理。

6. 容器中的对象没清理造成的内存泄漏
   有时会将一些对象的引用加入集合中，在不需要该对象时，如果没有把它的引用从集合中清理出去，这个集合就会越来越大。如果这个集合是static的，情况就更严重。

7. WebView
   Android的WebView不仅存在很大的兼容性问题，不同Android系统版本中的WebView也有较大差异。WebView都存在内存泄漏的问题，在应用中只要使用一次WebView，内存就不会被释放掉。通常解决这个问题的方法是为WebView开启独立的一个进程，使用AIDL与应用的主线程进行通信，WebView所在的进程可以根据业务的需要选择适合的时机进行销毁，达到正常释放内存的目的。