Android Weak Handler：可以避免内存泄漏的Handler库

Brigida8433 9年前

android使用java作为其开发环境。java的跨平台和垃圾回收机制已经帮助我们解决了底层的一些问题。但是尽管有了垃圾回收机制，在开发android的时候仍然时不时的遇到out of memory的问题，这个时候我们不禁要问，垃圾回收机器去哪儿了？

我们主要讲的是handler引起的泄漏，并给出三种解决办法，其中最后一种方法就是我们想介绍的WeakHandler 库。

可能导致泄漏问题的handler一般会被提示 Lint警告：

This Handler class should be static or leaks might occur 意思：class使用静态声明否者可能出现内存泄露。

这是一个基本的activity。在handler的post方法中我们加入了一个匿名的runnable，同时我将其执行延迟了整整80秒。我们运行这个程序，并且旋转几次手机，然后分析内存。

现在内存中有7个activity了，这太不靠谱了，所以我们来研究下为什么GC没有清理它。（上图中我查询内存中activity列表时用的是oql(对象查询语言)，简单强大的工具，ps 怎么用的，谁能告诉我？）

从上图中我们可以看到其中一个对mainactivity的引用是来自this$0，this$0是什么呢？以下是关于this$0的解释：

-------什么是this$0---------

非static的inner class里面都会有一个this$0的字段保存它的父对象。在Java中，非静态(匿名)内部类会默认隐性引用外部类对象。而静态内部类不会引用外部类对象。一个编译后的inner class 很可能是这样的：

class parent$inner  {  synthetic parent this$0;  parent$inner(parent this$0)  {  this.this$0 = this$0;  this$0.foo();  }  }

-------什么是this$0结束---------

在我们的代码中，匿名的runnable是一个非静态的内部类，因此他会使用this$0来保存MainActivity，然后runnable会继续被它的callback引用，而callback又接着被接下来一连串的message引用，这样主线程的引用就太他妈多了。当Activity finish后，延时消息会继续存在主线程消息队列中80秒，然后处理消息，因此handler在继续存在于内存中，而handler引用了Activity，在我们旋转手机的时候，Activity 不停的重建和finish，导致多个activity的引用出现。

一旦将Runnable或者是Message 发送进handler，将保存一连串的引用了主线程（这里是MainActivity吧）的Message命令，直到message执行完。如果发送Runnable设置了延迟时间，那么至少在这段延迟时间内内存泄漏是肯定的，如果是直接发送，在Message比较大的情况下，也是有可能发生暂时的泄漏的。

解决办法一：使用Static