Android memory leak analysis

• 类的静态变量持有大数据对象

静态变量长期维持到大数据对象的引用，阻止垃圾回收。

• 非静态内部类的静态实例

非静态内部类会维持一个到外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期维持着外部类的引用，阻止被回收掉。

• 资源对象未关闭

资源性对象如 Cursor、File、Socket，应该在使用后及时关闭。未在 finally 中关闭，会导致异常情况下资源对象未被释放的隐患。

• 注册对象未反注册

未反注册会导致观察者列表里维持着对象的引用，阻止垃圾回收。

• Handler临时性内存泄露

Handler 通过发送 Message 与主线程交互，Message 发出之后是存储在 MessageQueue 中的，有些 Message 也不是马上就被处理的。在 Message 中存在一个 target，是 Handler 的一个引用，如果 Message 在 Queue 中存在的时间越长，就会导致 Handler 无法被回收。如果 Handler 是非静态的，则会导致 Activity 或者 Service 不会被回收。  

由于 AsyncTask 内部也是 Handler 机制，同样存在内存泄漏的风险。  

此种内存泄露，一般是临时性的。

预防

• 不要维持到 Activity 的长久引用，对 activity 的引用应该和 activity 本身有相同的生命周期。尽量使用context-application代替context-activity，以避免 Activity 被外部长生命周期的对象引用而泄露

• Activity 中尽量不要使用非静态内部类，可以使用静态内部类和WeakReference代替。

• 正确关闭资源，对于使用了BraodcastReceiver，ContentObserver，File，游标 Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销。

• 保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。

• 在 Java 的实现过程中，也要考虑其对象释放，最好的方法是在不使用某对象时，显式地将此对象赋值为 null，比如使用完Bitmap 后先调用 recycle()，再赋为null,清空对图片等资源有直接引用或者间接引用的数组（使用 array.clear() ; array = null）等，最好遵循谁创建谁释放的原则。

• Handler 的持有的引用对象最好使用弱引用，资源释放时也可以清空 Handler 里面的消息。比如在 Activity onStop 或者 onDestroy 的时候，取消掉该 Handler 对象的 Message和 Runnable.

• 对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏：

• • 将内部类改为静态内部类

• • 静态内部类中使用弱引用来引用外部类的成员变量

检测

• 静态检测

静态检测主要是检测资源未关闭的情况，Eclipse 和 Android Studio 都可以检测出 IO 或者 Socket 未关闭的情况，然后在 finally 中关闭即可。

• 动态监测：使用MAT(Memory Analysis Tools)检测。
  打开 DDMS 工具，在左边 Devices 视图页面选中“Update Heap”图标，然后在右边切换到 Heap 视图，点击 Heap 视图中的“Cause GC”按钮，到此为止需检测的进程就可以被监视。
  　　Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在
  data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：
  　　进入某应用，不断的操作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
  　　所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。