Android Handler内存泄露

概述前言由于Android采取了单线程UI模型，开发者无法在子线程中更新UI，为此Android为我们提供了Handler这个工具，帮助开发者切换到主线程更新UI。在我们开发Android应用程序进行异步 *** 作时，我们经常会使用到Handler类。通常会写出如下代码privateHandlermHandler=newHandler() 前言由于AndroID采取了单线程UI模型，开发者无法在子线程中更新UI，为此AndroID为我们提供了Handler这个工具，帮助开发者切换到主线程更新UI。在我们开发AndroID应用程序进行异步 *** 作时，我们经常会使用到Handler类。通常会写出如下代码
private Handler mHandler = new Handler(){ @OverrIDe public voID handleMessage(Message msg){ //do something } }其实上面的代码是会产生内存泄漏的，如果你有使用AndroID lint工具的话，它会给我们提示一个警告
In AndroID, Handler classes should be static or leaks might occur。
翻译过来就是：在androID中，Handler这个类应该被定义成静态的，否则可能出现内存泄漏的情况
先说下什么是内存泄漏：
内存泄漏(Memory Leak)：是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

发生内存泄漏的原因 说是内存泄漏，那到底如何发生内存泄漏的呢？又在哪里发生的内存泄漏？接下来我们探究一下到底是如何发生内存泄漏的。
1.当一个AndroID应用程序启动的时候，frameworks会自动为这个应用程序在主线程创建一个Looper对象。这个被创建的Looper对象它的主要的工作就是不断地处理消息队列中的消息对象。在AndroID应用程序中，所有主要的框架事件（例如Activity的生命周期方法，按钮的点击事件等等）都包含在消息对象里面，然后被添加到Looper要处理的消息队列中，主线程的Looper一直存在于整个应用程序的生命周期中。
2.当一个Handler在主线程中被初始化。那它就一直都和Looper的消息队列相关联着。当消息被发送到Looper关联的消息队列的时候，会持有一个Handler的引用，以便于当Looper处理消息的时候，框架可以调用Handler的handleMessage（Message msg）。
3.在java中，非静态的内部类和匿名内部类都会隐式的持有一个外部类的引用。静态内部类则不会持有外部类的引用。
上面的代码确实是很难以发现内存泄漏的问题的。那我们来看看下面的代码，会更加容易发现问题。
 public class MainActivity extends AppCompatActivity {   private Handler mLeakHandler = new Handler(){ @OverrIDe public voID handleMessage(Message msg) {  } };   @OverrIDe protected voID onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentVIEw(R.layout.activity_main); //发送延时消息 mLeakHandler.postDelayed(new Runnable() { @OverrIDe public voID run() {  } }, 1000 *60 *10); finish(); } }
解决办法要解决这样的一个问题，有如下两种方式：
方法一：通过程序
1.在关闭Activity的时候停掉你的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。

2.如果你的Handler是被delay的Message持有了引用，那么使用相应的Handler方法：removeCallbacks(Runnable r)和removeMessages(int what)，在页面销毁时把消息对象从消息队列移除就行了

代码如下：

 @OverrIDe public voID onDestroy() { // 移除所有消息 handler.removeCallbacksAndMessages(null); // 或者移除单条消息 handler.removeMessages(what); }方法二：将Handler声明为静态类
静态类不持有外部类的对象，所以你的Activity可以随意被GC回收。代码如下： static class NoleakHander extends Handler { @OverrIDe public voID handleMessage(Message msg) {   } }以上代码中Handler不再持有外部类对象的引用，导致程序不允许你在Handler中 *** 作Activity中的对象了。所以就没法在Hander中 *** 作UI了，你需要在Handler中增加一个对Activity的弱引用（WeakReference）：
首先理解一下相关概念： 强引用(Strong Reference)：默认引用。如果一个对象具有强引用，垃圾回收器绝不会回收它。在内存空 间不足时， Java虚拟机宁愿 抛出OutOfMemory的错误，使程序异常终止，也不会强引用的对象来解决内存不足问题。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。弱引用(WeakReference)：在垃圾回收器一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。虚引用(Phantomreference)：如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。

加入弱引用后的代码：
 public class MainActivity extends AppCompatActivity { private NoleakHandler mHandler; @OverrIDe protected voID onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mHandler = new NoleakHandler(this); Message message = Message.obtain(); mHandler.sendMessageDelayed(message, 10 * 60 * 1000); }   private static class NoleakHandler extends Handler { //持有弱引用MainActivity,GC回收时会被回收掉. private WeakReference<MainActivity> mActivity; public NoleakHandler(MainActivity activity) { mActivity = new WeakReference<>(activity); }   @OverrIDe public voID handleMessage(Message msg) { super.handleMessage(msg); } } }

 

 

阅读目录

一、什么是内存泄露？二、内存泄露的危害三、解决方案@L_301_11@回到顶部@L_419_13@一、什么是内存泄露？

　　Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一组对象中只包含互相的引用，而没有来自它们外部的引用（例如有两个对象A和B互相持有引用，但没有任何外部对象持有指向A或B的引用），这仍然属于不可到达，同样会被GC回收。

　　AndroID中使用Handler造成内存泄露的原因

private Handler handler = new Handler() {      public voID handleMessage(androID.os.Message msg)
　　　　 {            if (msg.what == 1) 
　　　　　　　　{                noteBookAdapter.notifyDataSetChanged();             }        } };    

　　上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用（不然你怎么可能通过Handler来 *** 作Activity中的VIEw？）。而Handler通常会伴随着一个耗时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后Handler把图片更新到界面。然而，如果用户在网络请求过程中关闭了Activity，正常情况下，Activity不再被使用，它就有可能在GC检查时被回收掉，但由于这时线程尚未执行完，而该线程持有Handler的引用（不然它怎么发消息给Handler？），这个Handler又持有Activity的引用，就导致该Activity无法被回收（即内存泄露），直到网络请求结束（例如图片下载完毕）。另外，如果你执行了Handler的postDelayed()方法，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，那么在你设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致你的Activity被持有引用而无法被回收。

回到顶部二、内存泄露的危害

　　内存泄露的危害就是会使虚拟机占用内存过高，导致OOM（内存溢出），程序出错。

　　对于AndroID应用来说，就是你的用户打开一个Activity，使用完之后关闭它，内存泄露；又打开，又关闭，又泄露；几次之后，程序占用内存超过系统限制，FC。

回到顶部三、解决方案

使用Handler导致内存泄露的解决方法

方法一：通过程序逻辑来进行保护。
1.在关闭Activity的时候停掉你的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。
2.如果你的Handler是被delay的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行了。

方法二：将Handler声明为静态类。
PS:在Java 中，非静态的内部类和匿名内部类都会隐式地持有其外部类的引用，静态的内部类不会持有外部类的引用。
静态类不持有外部类的对象，所以你的Activity可以随意被回收。由于Handler不再持有外部类对象的引用，导致程序不允许你在Handler中 *** 作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用（WeakReference）。

代码如下：

static class MyHandler extends Handler    {        WeakReference<Activity> mWeakReference;        public MyHandler(Activity activity)         {            mWeakReference=new WeakReference<Activity>(activity);        }        @OverrIDe        public voID handleMessage(Message msg)        {            final Activity activity=mWeakReference.get();            if(activity!=null)            {                if (msg.what == 1)                {                    noteBookAdapter.notifyDataSetChanged();                }            }        }    }

　　PS：什么是WeakReference？
　　WeakReference弱引用，与强引用（即我们常说的引用）相对，它的特点是，GC在回收时会忽略掉弱引用，即就算有弱引用指向某对象，但只要该对象没有被强引用指向（实际上多数时候还要求没有软引用，但此处软引用的概念可以忽略），该对象就会在被GC检查到时回收掉。对于上面的代码，用户在关闭Activity之后，就算后台线程还没结束，但由于仅有一条来自Handler的弱引用指向Activity，所以GC仍然会在检查的时候把Activity回收掉。这样，内存泄露的问题就不会出现了。

回到顶部四、总结　

　androID中的很多内存泄露都是由于在Activity中使用了非静态内部类导致的，我们在使用非静态内部类一定要格外注意，如果该静态内部类的实例对象的生命周期大于外部对象，那么就有可能导致内存泄露，推荐使用上面介绍的静态类和弱引用的方法解决这种问题。

   总结

以上是内存溢出为你收集整理的Android Handler内存泄露全部内容，希望文章能够帮你解决Android Handler内存泄露所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。