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

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

这是一个针对技术开发者的一个应用，你可以在掘金上获取最新最优质的技术干货，不仅仅是Android知识、前端、后端以至于产品和设计都有涉猎，想成为全栈工程师的朋友不要错过！

.runtimead{ text-align:center }

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