由 Handler 源码引发的思考

• 前言
  从最开始学习使用 Handler 的时候，其实里面的使用就有很多我不太明白。这几天就索性看了Handler 的源码，也看了网上一些大神的博客，我的一些疑惑才解开。借此分享给大家！ ε≡٩(๑>₃<)۶

Handler 切换线程的时机

对于 Handler 的源码解析，网上有好多很好的博客，在此推荐几篇大神的博客：
http://blog.csdn.net/iispring/article/details/47180325
http://blog.csdn.net/guolin_blog/article/details/9991569
http://blog.csdn.net/lmj623565791/article/details/38377229
里面的解析就都很详细啦，今天我只是分享一下我之前的一些疑惑的答案。

对于整个 Handler 源码我结合着博客看完源代码之后。在当时我的理解下，Handler
的模式有类似于回调函数，，我觉得回调函数也能做到啊。（原谅我第一次看完有些不是很懂，哈哈）
于是我便自己写了个回调函数，看能不能达到同样效果。

image.png

结果是报了一个大家都很清楚的错误：不能在 非 ui 线程里面使用 ui 控件。
也就是说是在子线程里面调用了回调函数。当时我就很纳闷，在当时我的理解下，Handler 的模式有类似于回调函数，但此时是在子线程里面进行的。但是在 Handler 里面我没看到有线程的切换。在子线程中使用 Handler 是怎么切换到主线程的？我觉得 Handler 比 回调函数好的就是有一个消息队列，还有一个轮询机制，可以频繁发送信息并立即处理。我又在一次去看了一下源码，突然就明白了。
当你在子线程使用 Handler 时

new Thread(new Runable){
     void run（）
            handler.sendEmptyMessage();
      }
}

这个时候 handler 是在子线程运行的，但是在子线程运行之后中，handler 调用的 sendEmptyMessage() 或者是其他发送消息的方法的最后面都是调用到 enqueueMessage() 方法，在这个方法中将消息发送消息队列。而 looper 则会通过轮询来查看是否有消息，重点看一下 Looper 中的 loop 方法

image.png

从这里可以看出，loop 开启了无限循环机制，如果没有消息就进行阻塞，有消息就取出消息并传递给 Handler,除非消息队列退出了才有可能跳出循环。其中有一个语句需要特别注意：

msg.target.dispatchMessage(msg) 

这个语句中，msg.target 就是之前的 Handler ，至于 Handler 什么时候赋值给 msg 呢？

image.png

没错，是在 Handler 调用 enqueueMessage() 时赋值的。
重新回到 Looper ，我们知道，每一个线程只能有一个 Looper ,而主线程的 Looper 是在 ActivityThread 中创建，所以我们不用再去使用 Looper.prepare（） 来创建 looper。也就是说，此时 looper 一直是在主线程中运行的。所以，整个 Handler 的消息机制就进行了线程的切换。通过由 Looer 调用 Handler.dispatchMessage() 此时重新在主线程运行。线程的切换就体现在了这里。

关于 Looper ,相信大家还有一个疑问，既然 Looper 是在主线程中运行的，那调用 loop 方法进行轮询难道不会使程序 ANR 吗？其实， Android 也是基于 JVM 运行的，假如你执行完一个程序之后，那么 JVM 便会自动退出。那为了不使程序退出，我们会写一个无限循环，来让 JVM 不会退出。那么 Android 也是一样的。其实 android 程序所说的无响应原因主要是 :UI 线程中事件 5s 内事件还没有被执行完就会 ANR ，而不是说在线程中进行耗时操作就会 ANR ；主线程在没有事件需要处理的时候就是处于阻塞的状态。想让主线程活动起来一般有两种方式：一种是系统唤醒主线程，并且将点击事件传递给主线程；第二种是其他线程使用Handler向MessageQueue中存放了一条消息，导致loop被唤醒继续执行。
详细原因参考：
http://blog.csdn.net/qq_32583189/article/details/52253147

RunOnUIThread() 和 Handler.post(Runable runable ) 方法原理

相信大多数刚开始学会使用 Handler 的学习者都会对这个有点疑惑，因为参数里面是传入 Runable ，那我是不是可以在这里面进行耗时操作？
对于 post() 方法里面的源码：

image.png

其中调用的是 sendMessageDelayed() 方法，其实，postDelayed() 也是调用了这个方法，只不过参数是 Runable 而不是 Message； 在这个方法中有 getPostMessage() 方法，这个是做什么的呢？

image.png

原来是将 Runable 包装成 message；

在 dispatchMessage () 方法中可以看出，假如首先会判断 msg.callback 是否为空，一次来判断是否调用 post() 方法，如果是的话，就执行 handleCallback();

image.png

那么我们来看一下 handleCallback() 的源码：

image.png

可以看出，就是调用了 Run() 方法。由此可见，Runable 相当于只是一个 message 而已，此时的 Runable 是在主线程中执行的，所以一般不要有耗时操作。同理， RunOnUIThread() 也是差不多同样的道理。

但是，不要以为 Handler 就只是可以用来进行主线程控件的更新而已。这样子的话根本就不能称为 “异步消息处理机制”。 至于 Handler 还可以用来做什么呢？
可以参考一下这一篇文章：
http://blog.csdn.net/lmj623565791/article/details/38476887
对于一般的线程来说的话，假如我们要判断一下某个队列里面是否有消息，我们只能每隔一段时间去查询是否有消息。而对于 Handler 异步消息机制，只有在发送消息时才会去执行，当然更准确；当长时间没有任务到达时，也不会去查询，会一直阻塞。

关于 Handler 的内存泄漏问题

内存泄漏指的是本应该释放发的空间因为被某个对象错误引用导致不能够释放内存，导致内存泄漏。对于使用 Handler 来说，Handler 一般做为内部类来使用，那么内部类持有外部类的引用就很有可能导致内存泄漏。

image.png

例如上面代码， Runable 准备在五秒后执行，但是假设 activity 在创建后便立即销毁，那么由于 handler 仍然持有 activity 的引用，将导致 activity 无法销毁。
所以一般对于处理 Handler 内存泄漏有两种方式：

• 第一
  将 Handler 声明为 static ，因为静态内部类将不再持有外部类的引用，但是由于不持有外部类的引用，那么也就意味着无法引用控件。所以，此时我们需要一个软引用来指向 Activity，以便能够引用控件，又能在 activity 准备释放时，断开引用。
  实例：

 private static  class MyHandler extends Handler{
        WeakReference weakReference ;
        public MyHandler(UpdateViewActivity updateViewActivity){
            weakReference = new WeakReference(updateViewActivity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            UpdateViewActivity updateViewActivity = (UpdateViewActivity) weakReference.get();
            updateViewActivity.textView.setText("我想成为技术大牛！！");
        }
    }

• 第二
  由于会造成内存泄漏的根本原因就是 Handler 中的任务还没执行完成，那么可以在销毁的时候清空任务，这样就不会内存泄漏了。

   protected void onDestroy() {
    super.onDestroy();
    handler.removeCallbacksAndMessages(null);
}

下面这篇文章有更详细介绍：
https://juejin.im/entry/57d22a6c2e958a005452b7ea