Android中使用Handler形成内存泄露的分析和解决，Handler机制原理(SDK源码设计)

本文引用：http://www.linuxidc.com/Linux/2013-12/94065.htm

一、什么是内存泄露？

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

Android中使用Handler形成内存泄露的缘由

Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        mImageView.setImageBitmap(mBitmap);
    }
}

上面是一段简单的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被持有引用而没法被回收。

 

处理方式一：

在Activity中的部分代码：

/** 实现验证码按钮倒计时 */
private void messageCountDown(){
　　handler = new Handler();
　　seconds = 60;
　　handler.post(run);
}

Runnable run = new Runnable() {
　　@Override
　　public void run() {
　　　　if(seconds >= 0){
　　　　　　textMessageCode.setEnabled(false);
　　　　　　textMessageCode.setText(seconds+"");
　　　　　　seconds --;
　　　　　　handler.postDelayed(this,1000);
　　　　}else{
　　　　　　textMessageCode.setEnabled(true);
　　　　　　textMessageCode.setText(R.string.get_message_code_again);
　　　　}
　　}
};

@Override
protected void onDestroy() {
　　//activity销毁时移除handler防止内存泄漏
　　if(handler != null){
　　　　handler.removeCallbacks(run);
　　}
　　super.onDestroy();
}

方法二：将Handler声明为静态类。

静态类不持有外部类的对象，因此你的Activity能够随意被回收。代码以下：

static class MyHandler extends Handler {
    @Override
    public void handleMessage(Message msg) {
        mImageView.setImageBitmap(mBitmap);
    }
}

但其实没这么简单。使用了以上代码以后，你会发现，因为Handler再也不持有外部类对象的引用，致使程序不容许你在Handler中操做Activity中的对象了。因此你须要在Handler中增长一个对Activity的弱引用（WeakReference）：

static class MyHandler extends Handler {
    WeakReference<Activity > mActivityReference;

    MyHandler(Activity activity) {
        mActivityReference= new WeakReference<Activity>(activity);
    }

    @Override
    public void handleMessage(Message msg) {
        final Activity activity = mActivityReference.get();
        if (activity != null) {
            mImageView.setImageBitmap(mBitmap);
        }
    }
}

 

延伸：什么是WeakReference？

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

 

我的体会：

经过对sdk源码的学习，我所理解的handler实现原理：
Android是消息驱动的，实现消息驱动有几个要素：
一、消息的表示：Message
二、消息队列：MessageQueue
三、消息循环，用于循环取出消息进行处理：Looper
四、消息处理，消息循环从消息队列中取出消息后要对消息进行处理：Handler

 

一、在实例化handler的时候当前会获取Looper的实例，同时获取消息队列：

二、在handler.post()后，会把你所要执行的线程Runable封装到Mssage中    

三、再通过MessageQueue.enqueueMessage(Message msg, long when)将Message放入消息队列中；

四、当子线程完成操做后调用Looper.loop(),并调用dispatchMessage()，并在改方法中回调callback.handleMessage(msg);

【ps：loop方法怎么启用的为找出关联源码，我的分析应该是在子线程完以后触发改方法，loop是startc声明的静态方法】

public static void loop() {
　　final Looper me = myLooper();
　　if (me == null) {
　　　　throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
　　}
　　final MessageQueue queue = me.mQueue;

　　// Make sure the identity of this thread is that of the local process,
　　// and keep track of what that identity token actually is.
　　Binder.clearCallingIdentity();
　　final long ident = Binder.clearCallingIdentity();

　　for (;;) {
　　　　Message msg = queue.next(); // might block
　　　　if (msg == null) {
　　　　　　// No message indicates that the message queue is quitting.
　　　　　　return;
　　　　}

　　// This must be in a local variable, in case a UI event sets the logger
　　Printer logging = me.mLogging;
　　if (logging != null) {
　　　　logging.println(">>>>> Dispatching to " + msg.target + " " +
　　　　msg.callback + ": " + msg.what);
　　}

　　msg.target.dispatchMessage(msg);

　　if (logging != null) {
　　　　logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
　　}

　　// Make sure that during the course of dispatching the
　　// identity of the thread wasn't corrupted.
　　final long newIdent = Binder.clearCallingIdentity();
　　if (ident != newIdent) {
　　　　Log.wtf(TAG, "Thread identity changed from 0x"
　　　　+ Long.toHexString(ident) + " to 0x"
　　　　+ Long.toHexString(newIdent) + " while dispatching to "
　　　　+ msg.target.getClass().getName() + " "
　　　　+ msg.callback + " what=" + msg.what);
　　}

　　msg.recycleUnchecked();
　　}
}

五、回调callback