## 前言
> 本文已经收录到我的Github个人博客，欢迎大佬们光临寒舍：
>
> [我的GIthub博客](https://lovelifeeveryday.github.io/)
## 需要已经具备的知识：
- `Handler`的基本概念及使用
## 学习导图：
## 一.为什么要学习`Handler`?
在`Android`平台上，主要用到的通信机制有两种：`Handler`和`Binder`，前者用于进程内部的通信，后者主要用于跨进程通信。
在多线程的应用场景中，`Handler`**将工作线程中需更新`UI`的操作信息 传递到 `UI`主线程**，从而实现工作线程对`UI`的更新处理，最终实现异步消息的处理。
作为一个`Android`程序猿，**知其然而必须知其所以然**，理解其源码能更好地了解`Handler`机制的原理。下面，我就从消息机制入手，带大家畅游在`Handler`的世界中，体会`Google`工程师的智慧之光。
## 二.核心知识点归纳
### 2.1 消息机制概述
A.作用：**跨线程通信**
B.常用场景：当子线程中进行耗时操作后需要更新`UI`时，通过`Handler`将有关`UI`的操作切换到主线程中执行
> - 系统不建议在子线程访问`UI`的原因：`UI`控件**非线程安全**，在多线程中**并发**访问可能会导致`UI`控件处于不可预期的状态
>
> - 而不对`UI`控件的访问加上**锁**机制的原因有：
>
> 1.上锁会让UI控件变得复杂和低效
>
> 2.上锁后会阻塞某些进程的执行
C.四要素:
- `Message`：需要被传递的消息，其中包含了消息`ID`，消息处理对象以及处理的数据等，由`MessageQueue`统一列队，最终由`Handler`处理
- `MessageQueue`：用来存放`Handler`发送过来的消息，内部通过**单链表**的数据结构来维护消息列表，等待`Looper`的抽取。
- `Handler`:负责`Message`的发送及处理
> - `Handler.sendMessage()`：向消息队列**发送**各种消息事件
> - `Handler.handleMessage() `：**处理**相应的消息事件
- `Looper`：通过`Looper.loop()`不断地从`MessageQueue`中抽取`Message`，按分发机制将消息分发给目标处理者，可以看成是**消息泵**
>`Thread`：负责调度整个消息循环，即消息循环的执行场所
>
>存在关系：
>
>- 一个`Thread`只能有**一**个`Looper`，可以有**多**个`Handler`
>- `Looper`有**一**个`MessageQueue`，可以处理来自**多**个`Handler`的`Message`
>- `MessageQueue`有一组待处理的`Message`，这些`Message`可来自不同的`Handler`
>- `Message`中记录了负责发送和处理消息的`Handler`
>- `Handler`中有`Looper`和`MessageQueue`
D.使用方法：
- 在`ActivityThread`主线程实例化一个全局的`Handler`对象
- 在需要执行`UI`操作的子线程里实例化一个`Message`并填充必要数据，调用`Handler.sendMessage(Message)`方法发送出去
- 重写`handleMessage()`方法，对不同`Message`执行相关操作
E.总体工作流程：
> 这里先总体地说明一下`Android`消息机制的工作流程，具体的`ThreadLocal`,`MessageQueue`,`Looper`,`Handler`的工作原理会在下文详细解析
- `Handler.sendMessage()`发送消息时，会通过`MessageQueue.enqueueMessage()`向`MessageQueue`中添加一条消息
- 通过`Looper.loop()`开启循环后，不断轮询调用`MessageQueue.next()`
- 调用目标`Handler.dispatchMessage()`去传递消息，目标`Handler`收到消息后调用`Handler.handleMessage()`处理消息
>简单来看，即`Handler`将`Message`发送到`Looper`的成员变量`MessageQueue`中，之后`Looper`不断循环遍历`MessageQueue`从中读取`Message`，最终回调给`Handler`处理。如图：
### 2.2 消息机制分析
#### 2.2.1 `ThreadLocal`
> 了解`ThreadLocal`,有助于我们后面对`Looper`的探究
Q1：`ThreadLocal`**是什么**
首先我们来看一下官方源码（`Android 9.0`）
> This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its {@code get} or {@code set} method) has its own, independently initialized copy of the variable. {@code ThreadLocal} instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).
大致意思：
>`ThreadLocal`是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，只有在**指定线程**中才能获取到存储的数据（也就是说，每个线程的一个变量，有自己的值）
Q2：`ThreadLocal`的**使用场景**：
- 当某些数据是以线程为作用域且每个**线程**有**特有**的**数据副本**
> - `Android`中具体的使用场景：`Looper`,`ActivityThread`,`AMS`
>
> - 如果不采用`ThreadLocal`的话，需要采取的措施：提供一个全局哈希表
- 复杂逻辑下的对象传递，比如：监听器的传递
> - 采用`ThreadLocal`让监听器作为线程中的全局对象，线程内部只有通过`get`方法即可得到监听器
>
> - 如果不采用`ThreadLocal`的方案：
>
> a.将监听器作为参数传递
>
> 缺点：当调用栈很深的时候，程序设计看起来不美观
>
> b.将监听器作为静态变量
>
> 缺点：状态不具有可扩充性
Q3：**`ThreadLocal`和`synchronized`的区别：**
>- 对于多线程资源共享的问题，`synchronized`机制采用了“**以时间换空间**”的方式
>- 而`ThreadLocal`采用了**“以空间换时间”**的方式
>- 前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响，所以`ThreadLocal`和`synchronized`都能保证线程安全，但是应用场景却大不一样。
Q4:原理
> `ThreadLocal`主要操作为`set`,`get`操作，下面分别介绍流程
A1：`set`的原理
A2：`get`的原理
综上所述，`ThreadLocal`之所以有这么奇妙的效果，是因为：
- 不同线程访问同一个`ThreadLocal.get()`，其内部会从各种线程中取出`table`数组，然后根据当前`ThreadLocal`的索引查找出对应的`values`值
> 想要了解`ThreadLocal`源码的读者，推荐一篇文章：[ThreadLocal详解](https://www.jianshu.com/p/411c40b09a81)
#### 2.2.2 `MessageQueue`
- 数据结构：`MessageQueue`的数据结构是单链表
- 操作：
A.`enqueueMessage`
主要操作是单链表的插入操作
B.`next`
是一个无限循环的方法，如果没有消息，会一直阻塞；当有消息的时候，`next`会返回消息并将其从单链表中移出
#### 2.2.3 `Looper`
Q1：**`Looper`的作用**
> - 作为消息循环的角色
> - 它会不停地从`MessageQueue`中查看是否有新消息，若有新消息则立即处理，否则一直阻塞（不是`ANR`）
> - `Handler`需要`Looper`，否则将报错
Q2：**`Looper`的使用**
a1：开启：
> `UI`线程会自动创建`Looper`，子线程需自行创建
```java
//子线程中需要自己创建一个Looper
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();//为子线程创建Looper
Handler handler = new Handler();
Looper.loop(); //开启消息轮询
}
}).start();
```
> - 除了`prepare()`,还提供`prepareMainLooper()`，本质也是通过`prepare()`
> - `getMainLooper()` 作用：获取主线程的`Looper`
a2：关闭:
- `quit`：直接退出
- `quitSafely`:设定退出标记，待`MessageQueue`中处理完所有消息再退出
> 退出`Looper`的话，子线程会立刻终止；因此：建议在不需要的时候终止`Looper`
Q3：原理：
#### 2.2.4 `Handler`
Q1:**`Handler`的两种使用方式：**
> **注意**：创建`Handler`实例之前必须先创建`Looper`实例，否则会抛`RuntimeException`(`UI`线程自动创建`Looper`)
- `send`方式
```java
//第一种:send方式的Handler创建
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
//如UI操作
}
};
//send
mHandler.sendEmptyMessage(0);
```
- `post`方式
> 最终是通过一系列`send`方法来实现
```java
//实例化Handler
private Handler mHandler = new Handler();
//这里调用了post方法，和sendMessage一样达到了更新UI的目的
mHandler.post(new Runnable() {
@Override
public void run() {
mTextView.setText(new_str);
}
});
```
Q2：**`Handler`处理消息过程**
### 2.3 `Handler` 的延伸
#### 2.3.1 内存泄露
> 在初学`Handler`的时候，往往会发现`AS`亮起一大块黄色，以警告可能会发生内存泄漏
- 发生场景：`Handler` 允许我们发送**延时消息**，如果在延时期间用户关闭了`Activity`，那么该`Activity`会泄露
- 原因：这个泄露是因为因为 **`Java` 的特性，内部类会持有外部类**， `Handler` 持有 `Activity` 的引用，`Message`持有`Handler`的引用，而`MessageQueue`会持有`Message`的引用，而`MessageQueue`是属于`TLS（ThreadLocalStorage）`线程，是与Activity不同的生命周期。所以当`Activity`的生命周期结束后，而`MessageQueue`中还存在未处理的消息，那么上面一连串的引用链就不允许`Activity`的对象被回收，就造成了内存泄漏
- 解决方式：
A.`Activity`销毁时，清空`Handler`中未执行或正在执行的`Callback`以及`Message`
```java
// 清空消息队列，移除对外部类的引用
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}
```
B.**静态内部类+弱引用**
```java
private static class AppHandler extends Handler {
//弱引用，在垃圾回收时，被回收
WeakReference mActivityReference;
AppHandler(Activity activity){
mActivityReference=new WeakReference(activity);
}
public void handleMessage(Message message){
switch (message.what){
HandlerActivity activity=mActivityReference.get();
super.handleMessage(message);
if(activity!=null){
//执行业务逻辑
}
}
}
}
```
#### 2.3.2 `Handler`里藏着的`Callback`
首先看下`Handler.dispatchMessage(msg)`
```java
public void dispatchMessage(Message msg) {
//这里的 callback 是 Runnable
if (msg.callback != null) {
handleCallback(msg);
} else {
//如果 callback 处理了该 msg 并且返回 true， 就不会再回调 handleMessage
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
```
可以看到 `Handler.Callback` 有**优先处理消息的权利**
- 当一条消息被 `Callback` 处理**并拦截（返回 `true`）**，那么 `Handler.handleMessage(Msg)` 方法就不会被调用了
- 如果`Callback`处理了消息，但是并没有拦截，那么就意味着**一个消息可以同时被`Callback`以及 `Handler` 处理**
这个就很有意思了，这有什么作用呢？
**我们可以利用 `Callback` 这个拦截机制来拦截 `Handler` 的消息！**
场景：`Hook` [ActivityThread.mH](http://activitythread.mh/) ，笔者在[进阶之路 | 奇妙的四大组件之旅](https://juejin.im/post/5e5c74c1e51d4526dc7be184)介绍过`ActivityThread`，在 `ActivityThread`中有个成员变量 `mH` ，它是个 `Handler`，又是个极其重要的类，几乎所有的**插件化**框架都使用了这个方法
> 限于当前知识水平，笔者尚未研究过插件化的知识，以后有机会的话希望能给大家介绍！
#### 2.3.3 创建 `Message` 的最佳方式
> 为了节省开销,尽量复用 `Message` ，减少内存消耗
法一：`Message msg=Message.obtain();`
法二：`Message msg=handler.obtainMessage();`
#### 2.3.4 妙用 `Looper` 机制
我们可以利用`Looper`的机制来帮助我们做一些事情：
- 将 `Runnable` `post` 到主线程执行
- 利用 `Looper` 判断当前线程是否是主线程
```java
public final class MainThread {
private MainThread() {
}
private static final Handler HANDLER = new Handler(Looper.getMainLooper());
//将 Runnable post 到主线程执行
public static void run(@NonNull Runnable runnable) {
if (isMainThread()) {
runnable.run();
}else{
HANDLER.post(runnable);
}
}
//判断当前线程是否是主线程
public static boolean isMainThread() {
return Looper.myLooper() == Looper.getMainLooper();
}
}
```
#### 2.3.5 `Android`中为什么主线程不会因`Looper.loop()`的死循环卡死？
> 这个是老生常谈的问题了，记得当初被学长问到这个问题的时候，一脸懵逼，然后胡说一通，实属羞愧
>
> 要弄清这个问题，我们可以通过几个问题来逐层深入剖析
Q1：**什么是线程？**
线程是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出
Q2：**进入死循环是不是说明一定会阻塞**？
前面也说到了线程既然是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？**简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出**
想到这就理解，主线程也是一个线程，它也要维持自己的周期，所以也是需要一个死循环的。所以死循环并不是那么让人担心。
Q3:**什么是`Looper`的阻塞？**
- `Looper`的阻塞，前提是没有输入事件，此时`MessageQueue`是空的，`Looper`进入空闲，线程进入阻塞，释放`CPU`，等待输入事件的唤醒
- `Looper`阻塞的时候，主线程大多数时候都是处于休眠状态，并不会消耗大量`CPU`资源
> `Looper`的阻塞涉及到`Linux pipe/epoll`机制，想了解的读者可自行`Google`
Q4：**聊聊`ANR`**
- 其实初学者很容易将`ANR`和`Looper的阻塞`二者相混淆
- `UI`耗时导致卡死，前提是要有输入事件，此时`MessageQueue`不是空的，`Looper`正常轮询，线程并没有阻塞，但是该事件执行时间过长（一般5秒），而且与此期间其他的事件（按键按下，屏幕点击..也是通过`Looper`处理的）都没办法处理（卡死），然后就`ANR`异常了
Q5：**卡死的真正原因：**
- 真正卡死的原因是：在回调方法`onCreate`/`onStart`/`onResume`等操作时间过长
## 三.课堂小测试
> 恭喜你！已经看完了前面的文章，相信你对`Handler`已经有一定深度的了解，下面，进行一下课堂小测试，验证一下自己的学习成果吧！PS：限于篇幅，笔者就不提供答案了，不过答案一搜就有了
Q1：如何将一个`Thread`线程变成`Looper`线程？`Looper`线程有哪些特点
Q2：简述下`Handler`、`Message`、`Looper`的作用，以及他们之间的关系
Q3: 简述消息机制的回调处理过程，怎么保证消息处理机制的唯一性
Q4：为什么发送消息在子线程，而处理消息就变成主线程了，在哪儿跳转的
------
如果文章对您有一点帮助的话，希望您能点一下赞，您的点赞，是我前进的动力
本文参考链接：
- 《Android 开发艺术探索》
- [ThreadLocal详解](https://www.jianshu.com/p/411c40b09a81)
- [进阶之路 | 奇妙的四大组件之旅](https://juejin.im/post/5e5c74c1e51d4526dc7be184)
- [Handler运行机制中必须明白的几个问题](https://blog.csdn.net/fightingXia/articlehttps://img.qb5200.com/download-x/details/70494818)
- [Handler 都没搞懂，拿什么去跳槽啊？](https://juejin.im/post/5c74b64a6fb9a049be5e22fc#heading-18)
- [Android中为什么主线程不会因为Looper.loop()里的死循环卡死？](https://www.zhihu.com/question/34652589/answer/90344494)
- [为什么主线程不会因为Looper.loop()方法造成阻塞](http://wossoneri.github.io/2019/05/10/[Android]why-Looper-loop-will-not-block-main-thread/)
- [要点提炼|开发艺术之消息机制](https://www.jianshu.com/p/1c79fb5296b6)
- [Android消息机制浅析——面试总结](https://blog.csdn.net/Mr_dsw/articlehttps://img.qb5200.com/download-x/details/51074329)
- [Handler的sendMessage和post的区别](https://www.jianshu.com/p/43d6cd7b06f1)
