Android Handler内存泄漏详解及其解决方案

关联篇:深入Android的消息机制源码详解-Handler,MessageQueue与Looper关系

关联篇:HandlerThread 使用及其源码完全解析

在android开发过程中,我们可能会遇到过令人奔溃的OOM异常,面对这样的异常我们是既熟悉又深恶痛绝的,因为造成OOM的原因有很多种情况,如加载图片过大,某已不再使用的类未被GC及时回收等等......本篇我们就来分析其中一种造成OOM的场景,它就是罪恶的内存泄漏。对于这样的称呼,我们并不陌生,甚至屡次与之"并肩作战",只不过它就是一个猪队友,只会不断送塔.......

本篇分为3部分:

1.Handler内存泄漏例子说明以及原理阐明

2.问题验证(如果感觉繁琐请直接跳过)

3.Handler内存泄漏解决方法

1.Handler内存泄漏例子说明以及原理阐明

Handler,我们已经相当熟悉了,而且经常用得不亦乐乎,但就是因为太熟悉了,才会偶尔被它反捅一刀,血流不止......还记得我们曾经满怀信心地使用着如下的优美而又简洁的代码不?

不怕你吓着,实话告诉你,这个代码已经造成内存泄漏了!!!不相信?我们使用Android lint工具检测一下该类的代码:

面对现实吧,那为什么会这样呢?在java中非静态内部类和匿名内部类都会隐式持有当前类的外部引用,由于Handler是非静态内部类所以其持有当前Activity的隐式引用,如果Handler没有被释放,其所持有的外部引用也就是Activity也不可能被释放,当一个对象一句不需要再使用了,本来该被回收时,而有另外一个正在使用的对象持有它的引用从而导致它不能被回收,这导致本该被回收的对象不能被回收而停留在堆内存中,这就产生了内存泄漏(上面的例子就是这个原因)。最终也就造成了OOM.......我们再来段清晰的代码,我们来使用mHandler发送一个延迟消息:

分析:当我们执行了HandlerActivity的界面时,被延迟的消息会在被处理之前存在于主线程消息队列中5分钟,而这个消息中又包含了Handler的引用,而我们创建的Handler又是一个匿名内部类的实例,其持有外部HandlerActivity的引用,这将导致了HandlerActivity无法回收,进行导致HandlerActivity持有的很多资源都无法回收,从而就造成了传说中的内存泄露问题!

2.问题验证(如果感觉繁琐请直接跳过)

为了进一步验证内存泄漏问题,我们在该类中创建一个int数组,该数组分配的内存大小为2m,然后我们用DDMS来查看heap内存,然后使用GC回收,看看内存会不会有变化:

第一次启动app时,head内存为12.5M,已经分配内容(Allocated):8.5M,空闲内存:4M,我们频繁点击GC按钮,内存并没有发生明显变化,现在我们点击手机返回健,推出应用,然后再重新进入,同样检测一下head内存:

我们发现head内存:20.5M,Allocated:16.5M,Free:4M,堆内存和已经分配内存近乎翻倍,我们继续频繁点击GC, 看看能否被回收?结果内存并没有明显变化,现在我们继续点击手机返回健,推出应用,然后再重新进入,同样再次检测一下head内存:

我们发现head内存:28.5M,Allocated:24.5M,Free:4M,堆内存和已经分配内存又增加了,而且无论我们如何点击GC回收内存,内存都没有明显变化,而且每启动一次该页面,内存就增加一倍!这也就说存在在某个类只创建而没销毁的情况,其实就是存在内存泄漏问题。我们使用MAT工具进一步验证这个问题,我们来看一组Histogram的数据和dominator tree数据,首先是Histogram的数据:

dominator tree数据:

同时存在三个一样的HandlerActivity和内部类,这就足以说明HandlerActvity只有创建没被销毁了吧,也就是说Handler造成的内存泄漏真的存在。

3.Handler内存泄漏解决方法

解决这个问题思路就是使用静态内部类并继承Handler时(或者也可以单独存放成一个类文件)。因为静态的内部类不会持有外部类的引用,所以不会导致外部类实例的内存泄露。当你需要在静态内部类中调用外部的Activity时,我们可以使用弱引用来处理。另外关于同样也需要将Runnable设置为静态的成员属性。修改后不会导致内存泄露的代码如下:

package com.zejian.handlerlooper;
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import java.lang.ref.WeakReference;
/**
 * Created by zejian on 16/3/6.
 */
public class HandlerActivity extends Activity {
 //创建一个2M大小的int数组
 int[] datas=new int[1024*1024*2];
// Handler mHandler = new Handler(){
//  @Override
//  public void handleMessage(Message msg) {
//   super.handleMessage(msg);
//  }
// };
 /**
  * 创建静态内部类
  */
 private static class MyHandler extends Handler{
  //持有弱引用HandlerActivity,GC回收时会被回收掉.
  private final WeakReference<HandlerActivity> mActivty;
  public MyHandler(HandlerActivity activity){
   mActivty =new WeakReference<HandlerActivity>(activity);
  }
  @Override
  public void handleMessage(Message msg) {
   HandlerActivity activity=mActivty.get();
   super.handleMessage(msg);
   if(activity!=null){
    //执行业务逻辑
   }
  }
 }
 private static final Runnable myRunnable = new Runnable() {
  @Override
  public void run() {
   //执行我们的业务逻辑
  }
 };
 @Override
 protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.activity_handler_leak);
  MyHandler myHandler=new MyHandler(this);
  //解决了内存泄漏,延迟5分钟后发送
  myHandler.postDelayed(myRunnable, 1000 * 60 * 5);
 }
}

Handler的内存泄漏问题到此分析解决完成。其实产生内存泄漏的还有好几种情况,比如多线程造成的内存泄漏,静态变量造成的内存泄漏,单例模式造成的内存泄漏等等.......当然这些不在本篇的范围内,就不过多分析啦。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Android 5.1 WebView内存泄漏问题及快速解决方法

    问题背景 在排查项目内存泄漏过程中发现了一些由WebView引起的内存泄漏,经过测试发现该部分泄漏只会出现在android 5.1及以上的机型.虽然项目使用WebView的场景并不多,但秉承着一个泄漏都不放过的精神,我们肯定要把它给解决了. 遇到的问题 项目中使用WebView的页面主要在FAQ页面,问题也出现在多次进入退出时,发现内存占用大,GC频繁.使用LeakCanary观察发现有两个内存泄漏很频繁: 我们分析一下这两个泄漏: 从图一我们可以发现是WebView的ContentViewCo

  • Android中LeakCanary检测内存泄漏的方法

    最近要对产品进行内存泄漏的检查,最后选择了使用Square公司开源的一个检测内存泄漏的函数库LeakCanary,在github上面搜索了一下竟然有1.6w个star,并且Android大神JakeWharton也是这个开源库的贡献者.那么就赶快拿来用吧. 先说一下我遇到的坑,我当时是直接google的,然后就直接搜索到稀土掘金的一篇关于LeakCanary的介绍,我就按照他们的文章一步步的操作,到最后才发现,他们那个build.gradle中导入的库太老了,会报这样的错误Closed Fail

  • Android Studio+MAT实战内存泄漏

    对于内存泄漏,在Android中如果不注意的话,还是很容易出现的,尤其是在Activity中,比较容易出现,下面我就说下自己是如何查找内存泄露的. 首先什么是内存泄漏? 内存泄漏就是一些已经不使用的对象还存在于内存之中且垃圾回收机制无法回收它们,导致它们常驻内存,会使内存消耗越来越大,最终导致程序性能变差. 其中在Android虚拟机中采用的是根节点搜索算法枚举根节点判断是否是垃圾,虚拟机会从GC Roots开始遍历,如果一个节点找不到一条到达GC Roots的路线,也就是没和GC Roots

  • Android中内存泄漏需要的注意点

    内存泄漏对每一位 Android 开发一定是司空见惯,大家或多或少都肯定有些许接触.大家都知道,每一个手机都有一定的承载上限,多处的内存泄漏堆积一定会堆积如山,最终出现内存爆炸 OOM. 而这,也是极有可能在 Android 面试中一道常见的开放题. 内存泄漏的根本原因是一个长生命周期的对象持有了一个短生命周期的对象.如果你对垃圾回收机制有所了解,我想这个问题基本难不住你,因为知道了原理,自然不会去触碰这些极易导致内存泄漏的雷区. 该题重在积累,不需要死记硬背,自己多总结即可. 1. 长生命周期

  • Android Studio 3.0上分析内存泄漏的原因

    以前用eclipse的时候,我们采用的是DDMS和MAT,不仅使用步骤复杂繁琐,而且要手动排查内存泄漏的位置,操作起来比较麻烦.后来随着Android studio的潮流,我也抛弃了eclipse加入了AS. Android Studio也开始支持自动进行内存泄漏检查,并且操作起来也比较方便. 封面 戳我下载 Android Studio 3.0 这个不用梯子我会告诉你吗 1.写在前面 Google在上周发布了Android Studio 3.0的正式版本,周四早晨在上班的地铁上就看到群里在沸沸

  • Android内存泄漏的轻松解决方法

    前言 内存管理的目的就是让我们在开发过程中有效避免我们的应用程序出现内存泄露的问题.内存泄露相信大家都不陌生,我们可以这样理解:「没有用的对象无法回收的现象就是内存泄露」. 如果程序发生了内存泄露,则会带来以下这些问题 应用可用的内存减少,增加了堆内存的压力 降低了应用的性能,比如会触发更频繁的 GC 严重的时候可能会导致内存溢出错误,即 OOM Error 下面我们从基础说起 基础知识 Java 的内存分配简述 方法区(non-heap):编译时就分配好,在程序整个运行期间都存在.它主要存放静

  • Android内存泄漏排查利器LeakCanary

    本文为大家分享了Android内存泄漏排查利器,供大家参考,具体内容如下 开源地址:https://github.com/square/leakcanary 在 build.gralde 里加上依赖, 然后sync 一下, 添加内容如下 dependencies { .... debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanar

  • Android Handler内存泄漏详解及其解决方案

    关联篇:深入Android的消息机制源码详解-Handler,MessageQueue与Looper关系 关联篇:HandlerThread 使用及其源码完全解析 在android开发过程中,我们可能会遇到过令人奔溃的OOM异常,面对这样的异常我们是既熟悉又深恶痛绝的,因为造成OOM的原因有很多种情况,如加载图片过大,某已不再使用的类未被GC及时回收等等......本篇我们就来分析其中一种造成OOM的场景,它就是罪恶的内存泄漏.对于这样的称呼,我们并不陌生,甚至屡次与之"并肩作战",

  • Android Handler内存泄漏原因及解决方案

    目录: 1.须知: 主线程Looper生命周期和Activity的生命周期一致. 非静态内部类,或者匿名内部类.默认持有外部类引用. 2.原因: Handler造成内存泄露的原因.非静态内部类,或者匿名内部类.使得Handler默认持有外部类的引用.在Activity销毁时,由于Handler可能有未执行完/正在执行的Message.导致Handler持有Activity的引用.进而导致GC无法回收Activity. 3.可能造成内存泄漏 匿名内部类: //匿名内部类 Handler handl

  • Android Handler的使用详解

    在Android开发中,我们经常会遇到这样一种情况:在UI界面上进行某项操作后要执行一段很耗时的代码,比如我们在界面上点击了一个"下载"按钮,那么我们需要执行网络请求,这是一个耗时操作,因为不知道什么时候才能完成.为了保证不影响UI线程,所以我们会创建一个新的线程去执行我们的耗时的代码.当我们的耗时操作完成时,我们需要更新UI界面以告知用户操作完成了.所以我们可能会写出如下的代码: package ispring.com.testhandler; import android.app.

  • Java中由substring方法引发的内存泄漏详解

    内存溢出(out of memory ) :通俗的说就是内存不够用了,比如在一个无限循环中不断创建一个大的对象,很快就会引发内存溢出. 内存泄漏(leak of memory) :是指为一个对象分配内存之后,在对象已经不在使用时未及时的释放,导致一直占据内存单元,使实际可用内存减少,就好像内存泄漏了一样. 由substring方法引发的内存泄漏 substring(int beginIndex, int endndex )是String类的一个方法,但是这个方法在JDK6和JDK7中的实现是完全

  • Android Handler使用案例详解

    什么是Handler? Handler可以发送和处理消息对象或Runnable对象,这些消息对象和Runnable对象与一个线程相关联.每个Handler的实例都关联了一个线程和线程的消息队列.当创建了一个Handler对象时,一个线程或消息队列同时也被创建,该Handler对象将发送和处理这些消息或Runnable对象. handler类有两种主要用途: 执行Runnable对象,还可以设置延迟. 两个线程之间发送消息,主要用来给主线程发送消息更新UI. 为什么要用Handler 解决多线程并

  • Kotlin中的handler如何避免内存泄漏详解

    前言: 哲学老师说,看待事物无非是了解它是什么,为什么,怎么做 所以,首先,我们先了解一下什么是"内存泄漏" 摘自百度的一段话:用动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元.直到程序结束. 是不是有点拗口,换一种说法,有天你去一家饭店吃饭,有个胖子吃完饭了,却霸占着一张桌子不走,然而现在一堆人等着吃饭,结果那死胖子等到饭店打烊了才离开. 在这个例子中,饭店的桌子就好比内存空间,那个胖子就是一个函数,吃饭就是所执行的事件. 这么说是不是好理解多了,现在

  • Android性能优化之利用Rxlifecycle解决RxJava内存泄漏详解

    前言: 其实RxJava引起的内存泄漏是我无意中发现了,本来是想了解Retrofit与RxJava相结合中是如何通过适配器模式解决的,结果却发现了RxJava是会引起内存泄漏的,所有想着查找一下资料学习一下如何解决RxJava引起的内存泄漏,就查到了利用Rxlifecycle开源框架可以解决,今天周末就来学习一下如何使用Rxlifecycle. 引用泄漏的背景: RxJava作为一种响应式编程框架,是目前编程界网红,可谓是家喻户晓,其简洁的编码风格.易用易读的链式方法调用.强大的异步支持等使得R

  • Android线程间通信Handler源码详解

    目录 前言 01. 用法 02.源码 03.结语 前言 在[Android]线程间通信 - Handler之使用篇主要讲了 Handler 的创建,发送消息,处理消息 三个步骤.那么接下来,我们也按照这三个步骤,从源码中去探析一下它们具体是如何实现的.本篇是关于创建源码的分析. 01. 用法 先回顾一下,在主线程和非主线程是如何创建 Handler 的. //主线程 private val mHandler: Handler = object : Handler(Looper.getMainLo

  • Android Jetpack- Paging的使用详解

    Google 推出 Jetpack 组件化已经有相当一段时间了.各种组件也层出不穷. Jetpack 的东西也不少, 今天就搞一下这个  Paging Paging 的出现,就是用作列表的分页加载.其实现在已经有非常多成熟高效的开源列表加载控件了,比如:Smartrefreshlayout等.但Google推出的,必然有它的有点,当然也有它的局限性. 先说优点吧,Paging 的使用,需要配合ViewModle,LiveData等控件,数据的请求感知并绑定页面的生命周期,避免了内存泄漏.还需要绑

  • Android中CountDownTimer类详解

    一.概述 项目中经常用到倒计时的功能,比如说限时抢购,手机获取验证码等等.而google官方也帮我们封装好了一个类:CountDownTimer,使我们的开发更加方便: 二.API CountDownTimer是一个抽象类,有两个抽象方法,它的API很简单 public abstract void onTick(long millisUntilFinished);//这个是每次间隔指定时间的回调,millisUntilFinished:剩余的时间,单位毫秒 public abstract voi

随机推荐