背景

Java是垃圾回收语言的一种，其优点是开发者无需特意管理内存分配，降低了应用由于局部故障导致崩溃，同时防止未释放的内存把堆栈(heap)挤爆的可能，所以写出来的代码更为安全。

不幸的是，在Java中仍存在很多容易导致内存泄漏的逻辑可能。如果不小心，你的Android应用很容易浪费掉未释放的内存，轻则应用卡顿，重则导致内存用光抛出OOM。

泄露场景

• 临时性内存泄漏

1.context引用

context引用 况会持有外部类的引用，一旦执行耗时操作，会造成内存回收不及时，从而造成OOM。典型例子就是Handler，当Handler声明为非静态内部类时会持有外部类（例如Activity）的引用。

2.非静态内部类

这种情况会持有外部类的引用，一旦执行耗时操作，会造成内存回收不及时，从而造成OOM。典型例子就是Handler，当Handler声明为非静态内部类时会持有外部类（例如Activity）的引用。

3.匿名类

相似地，匿名类也维护了外部类的引用。所以内存泄漏很容易发生，当你在Activity中定义了匿名的AsyncTsk。当异步任务在后台执行耗时任务期间，Activity不幸被销毁了，这个被AsyncTask持有的Activity实例就不会被垃圾回收器回收，直到异步任务结束。

4.监听器

App开发中我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，一旦监听器里执行了耗时操作，对象就无法回收，从而增加了内存泄漏的机会。

5.资源对象未关闭

资源性对象比如(Cursor游标，Stream流，BroadCastReceiver等)往往都用了一些缓冲，我们在不使用的时候或者在使用完之后，应该及时关闭它们比如close()方法，以便它们的缓冲及时回收内存。Bitmap要先recyler()，在置为null。

6.不要在执行频率高的方法中创建对象

在自定义View中onDraw和onMesaure这两个方法一般执行频率很高，一旦使用不当，会创建大量对象，频繁GC,会导致应用变卡顿。

7.WebView造成的泄露

当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。

8.构造Adapter时，没有使用缓存的ConvertView

ListView在加载布局时如果不使用缓存的ConvertView，而是每次重新加载，就容易造成内存泄漏，应用卡顿。

• 永久性内存泄漏

1.全局变量

全局变量的内存永远不会被回收，一般app中都会定义一个常量类来存放这些数据，但是能少用全局变量就少用，毕竟要一直占用内存，如果使用建议只存储一些基本数据类型,切记不要持有context，activity,fragment，view的引用。这种错误一般在单例模式中比较常见。

2.属性动画

从Android3.0开始，Google提供了属性动画，属性动画中有一类无限循环的动画，如果在Activity中播放此类动画并且在onDestroy（）方法中没有停止该动画，那么动画会一直循环下去，尽管在界面上已经无法看不到动画了，但这个时候Activity的View会被动画持有，而View又持有Activity，最终Activity无法释放。

3.系统服务

当你使用系统服务的时候，可以注册监听器，会导致服务持有Context的引用，如果在Activity销毁的时候，没有注销掉监听器，就会导致内存泄漏。

解决方法

• 弱引用(耗时操作持有的context等引用可以用弱引用)
• 使用LeakCanary工具查找内存泄漏（该工具会会自动分析context是否引起内存泄漏）
• Android Studio自带分析工具Profiler(使用该工具可以实时查看内存使用状况)