作者：jtsky
链接：https://www.jianshu.com/p/0a150ec09a32

简介

首先我们先来了解HandlerThread和IntentService是什么，以及为什么要将这两者放在一起分析。
HandlerThread：

HandlerThread 其实是Handler + Thread + Looper的组合，它本质上是一个Thread，因为它继承了Thread。相比普通的Thread，它不会堵塞，因为他内部通过Looper实现了消息循环机制，保证了多个任务的串行执行。缺点是效率比较低，因为，串行执行比起并行执行，效率肯定会比较较低。

IntentService：

IntentService是继承并处理异步请求的一个类，其本质上是一个Service，因为他继承了Service，所以开启IntentService和普通的Service一致。但是他和普通的IntentService不同之处在于，他可以处理异步任务，在任务处理完成之后会自动结束Service。另外我们可以启动IntentService多次，而每一个耗时任务会已工作队列的方式在IntentService的onHandleIntent回调方法中执行，并且是串行执行的。

好了在了解HandlerThread和IntentService分别是什么之后，我们来解决第二个问题，那就是为什么我要将2者放在一起分析？其实IntentService的内部是通过HandlerThread和Handler来实现异步操作的，当我们了解了HandlerThread的使用和原理之后，再去理解IntentService就会容易的多。好的，下面让我们开始HandlerThread的源码之旅。

HandlerThread的使用和原理

HandlerThread的使用

这里我们要实现一个每隔5s更新TextView中的值的一个demo，源码如下：

public class MainActivity extends AppCompatActivity {private static final String TAG = "MainActivity";private TextView mTv;private Button mBtn;HandlerThread mHandlerThread;Handler mThreadHandler;@Override protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);initView();mBtn.setOnClickListener(new View.OnClickListener() {@Override public void onClick(View v) {initThread();}});}private void initView() {mTv = (TextView) findViewById(R.id.tv);mBtn = (Button) findViewById(R.id.btn);}private void initThread() {//创建一个HandlerThread并开启线程mHandlerThread = new HandlerThread("update-msg");mHandlerThread.start();//从mHandlerThread中得到Looper并创建HandlermThreadHandler = new Handler(mHandlerThread.getLooper()) {@Override public void handleMessage(Message msg) {Log.v(TAG, "currentThread===>" + Thread.currentThread() + "   what====>" + msg.what);try {update();} catch (Exception e) {e.printStackTrace();}mThreadHandler.sendEmptyMessage(200);}};mThreadHandler.sendEmptyMessage(200);}private void update() throws Exception {Thread.sleep(3000);runOnUiThread(new Runnable() {@Override public void run() {String result = "每隔3s更新一次：";result += Math.random();mTv.setText(result);}});}
}

输出的日志如下：

currentThread===>Thread[update-msg,5,main] what====>200

从日志我们可以看出handleMessage运行在我们创建的HandlerThread(“update-msg”)之下。我们有理由怀疑这跟我们传入的mHandlerThread.getLooper()有关。我们的mThreadHandler 是在UI线程中创建的，按理来说handleMessage应该运行在UI线程中才对。了解Handler原理的都知道，handleMessage方法是在Handler的dispatchMessage方法中被调用的且dispatchMessage方法没有进行线程切换。所以线程切换应该发生在dispatchMessage被调用的地方，那dispatchMessage是在哪被调用的呢？我们发现Loop的loop()方法中调用了dispatchMessage()方法。(这里我就不贴Handler和Loop相关的代码，感兴趣的可以参考我以前的文章：Handler的原理)而且我们还发现了loop()方法的注释如下：

意思是loop()方法运行在Loop被绑定的线程中。

那Loop又是在什么时候被绑定的呢？

就是这2个方法对Loop进行了绑定。那这个sThreadLocal又是什么鬼？它到底有什么用？别急，我们去看下它创建的地方：

它其实就是一个ThreadLocal，关于ThreadLocal的原理，大家可以参考:ThreadLocal源码深入分析
在这里我简单的说下，其实ThreadLocal的作用，就是通过Thread中的threadLocals：ThreadLocalMap变量将我们通过ThreadLocal#set方法传进来的数据跟Thread进行绑定，从而保证了访问到的变量属于当前线程，每个线程都保存有一个变量副本，每个线程的变量都不同，而同一个线程在任何时候访问这个本地变量的结果都是一致的。当此线程结束生命周期时，所有的线程本地实例都会被GC。ThreadLocal相当于提供了一种线程隔离，将变量与线程相绑定。ThreadLocal通常定义为private static类型。

通过上面的分析，我们已经知道了Handler#handleMessage方法会运行在Loop说绑定的线程上，验证了我们一开始的猜想。这里Loop是从我们创建的HandlerThread中得到的，而HandlerThread其实就是一个线程，所以Loop绑定在了新创建的HandlerThread上。但是我们并不满足于此，我们得进一步看看HandlerThread和普通的Thread到底有什么不一样。

HandlerThread的源码解析

HandlerThread的代码量其实并不多，它继承于Thread，主要的方法其实就是run方法

@Overridepublic void run() {mTid = Process.myTid();//创建Loop并绑定当前线程Looper.prepare();//关键代码synchronized (this) {mLooper = Looper.myLooper();notifyAll();}//设置线程优先级Process.setThreadPriority(mPriority);onLooperPrepared();Looper.loop();mTid = -1;}public Looper getLooper() {if (!isAlive()) {return null;}// If the thread has been started, wait until the looper has been created.synchronized (this) {while (isAlive() && mLooper == null) {try {wait();} catch (InterruptedException e) {}}}return mLooper;}

短短的几行代码确几乎实现了我们想要的所有功能，我们来看关键代码run方法中的synchronized 代码块其实对应于getLooper方法中的synchronized代码块，这样做的目的是为了确保，我们通过getLoop（）方法得到的Loop对象一定是被初始化后的Loop。当Loop被初始化以后会调用抽象方法onLooperPrepared()，他一般被用于在开启队列循环之前做一些初始化的操作，然后执行任务队列。

总结

HandlerThread的原理已经分析完了，我们来总结一下它的特点：

1.HandlerThread它就是一个线程，和开启普通的线程得到操作一致
2.HandlerThread需要搭配Handler使用，单独使用的意义不大
3.HandlerThread会将通过handleMessage传递进来的任务进行串行执行，这是由messageQueue的特性决定的，从而也说明了HandlerThread效率相比并行操作会比较低

IntentService的使用和原理

分析完HandlerThread之后我们来分析一下IntentService的使用和原理，老规矩我们先看怎么使用。

IntentService的使用

public class MyIntentService extends IntentService {private static final String TAG = "MyIntentService";public MyIntentService() {super("MyIntentService");Log.v(TAG,"MyIntentService===>MyIntentService()" + "  currentThread==>" + Thread.currentThread());}/*** Creates an IntentService.  Invoked by your subclass's constructor.** @param name Used to name the worker thread, important only for debugging.*/public MyIntentService(String name) {super(name);Log.v(TAG,"MyIntentService===>MyIntentService(name)" + "  currentThread==>" + Thread.currentThread());}@Override public void onCreate() {super.onCreate();Log.v(TAG, "MyIntentService===>onCreate" + "  currentThread==>" + Thread.currentThread());}@Override protected void onHandleIntent(@Nullable Intent intent) {Log.v(TAG, "MyIntentService===>onHandleIntent" + "  currentThread==>" + Thread.currentThread());try {Thread.sleep(10000);} catch (InterruptedException e) {e.printStackTrace();}}@Override public int onStartCommand(@Nullable Intent intent, int flags, int startId) {Log.v(TAG, "MyIntentService===>onStartCommand" + "  currentThread==>" + Thread.currentThread());return super.onStartCommand(intent, flags, startId);}
}

调用服务和我们普通的Service一致
输出的日志如下

MyIntentService===>MyIntentService() currentThread==>Thread[main,5,main]
MyIntentService===>onCreate currentThread==>Thread[main,5,main]
MyIntentService===>onStartCommand currentThread==>Thread[main,5,main]
MyIntentService===>onHandleIntent currentThread==>Thread[IntentService[MyIntentService],5,main]

从中我们可以看出onHandleIntent方法是运行在子线程中的，更有意思的是，当我们在onHandleIntent 方法中执行延迟操作时，打印的日志如下描述：
1、当服务没执行完时又点击了开启服务的操作，此时，onStartCommand方法会立即执行，而onHandleIntent方法会在上一个任务执行完以后再去执行onHandleIntent方法。
2、当服务已经执行完被自动结束以后，再去调用service，输出的日志和第一次输出的日志一致。

可能我说的比较抽象，大家自取去操作一遍就会发现我所说的有意思的地方。从上面的日志输出，我们可以得出以下结论：
1、IntentService在任务执行完以后会自动结束
2、IntentService接收的任务是串行执行的，并且互不干扰
3、IntentService的生命周期和普通的Service一致，只不过多了一个onHandleIntent回调方法，并且它是串行回调的，等待上一个任务执行完以后才会再次被调用

但是为什么会这样呢？大家有没有想过。当然，所有的答案都隐藏在源码里，让我们一起去揭开他神秘的面纱吧。

IntentService源码解析

首先我们先来看下IntentService的几个成员变量，如下图所示：

关于Loop和Handler我们都很熟悉了，前者是遍历消息队列的消息泵后者则是处理Handler发送过来的消息的。下面我来看下他们初始化得到地方。
Loop初始化

原来他们都是在Service的onCreate回调方法中被初始化的。
通过上文HandlerThread的分析，我们知道ServiceHandler的handleMessage方法会运行在mServiceLooper绑定的指定线程上。这里这也就验证了我们上文日志的输出。

下面我们来解决另外一个问题，也就是IntentService的生命周期函数的执行情况。
请看下面的代码：

我们都知道当服务被启动以后，再次调用服务的时候都会回调onStartCommand方法，onStartCommand又调用了onStart方法，而onStart方法中只是通过Handler发送一个异步消息，然后ServiceHandler的handleMessage收到消息以后调用了onHandleIntent，这也就验证了上文的日志输出。

下面我们来重点分析一下Service的stopSelf()方法，他有两个重载方法，一个有参，一个无参，那他们之间有什么不同呢？
我们还是通过源码来看一下吧。

可以看到无参方法只是简单的调用了有参方法，并传入了一个-1的参数。所以我们只有直接分析有参的方法就可以。
由于Android sdk并没有开放ActivityManageProxy(我们知道ActivityManage在客户端得到代理是ActivityManageProxy)的代码，所以我们只能通过查找相关资料来解决我们的疑惑。
最终我在官网上得到的答案如下：

简单来说就是stopSelf中的startId对应于onStartCommand中的startId，当stopSelf（startId）中的startId等于onStartCommand中的最后一个进来的startId的时候，就代表消息队列中没有更多的消息需要处理了，所以执行完当前的消息以后，会去执行Service的stop操作。

总结

关于IntentService的分析到这就告一段落了，其实IntentService就是基于HandlerThread机制来实现的，它允许我们在onHandleIntent回调方法中执行异步操作。同时要注意他的生命周期回调函数的差异。下面贴上官网上关于IntentService类的介绍，帮助大家理解。

文末

欢迎关注我的CSDN，分享Android干货，交流Android技术。
对文章有何见解，或者有何技术问题，都可以在评论区一起留言讨论，我会虔诚为你解答。
最后，如果你想知道更多Android的知识或需要其他资料我这里均免费分享，只需你多多支持我即可哦！

——可以直接点这里可以看到全部资料内容免费打包领取。

Handler消息机制（九）：IntentService源码解析相关推荐

安卓 Handler 消息机制之Message源码
一概述 1. Message是handler机制中消息传递的载体,主要用来规范化传输数据的格式. 2. 源码内容含几个部分: 2.1 操作数据相关:一些属性和操作属性的getter和setter方法 ...
安卓 Handler 消息机制之MessageQueue源码
首先,MessageQueue是属于底层类且它依附于创建他的Looper,除Looper外其他类无法单独创建他,如果要使用他,只能从Looper出获得. 下面将从几方面分析: 1. 消息队列存储原理 ...
HandlerThread和IntentService源码解析
简介首先我们先来了解HandlerThread和IntentService是什么,以及为什么要将这两者放在一起分析. HandlerThread: HandlerThread 其实是Handler ...
Android多线程之IntentService源码解析
想要了解 IntentService 的工作原理需要先对 Android 系统中以 Handler.Looper.MessageQueue 组成的异步消息处理机制以及 HandlerThread 有所 ...
消息转发机制与Aspects源码解析
前言最近在搞重构相关的事情,遇到了不少这样的场景: 进入一个界面,在viewWillAppear:的时候做相应判断,如果满足条件则执行对应代码. 这类业务有一个特点,业务内容是对应整个App的,与对 ...
Spring5源码 - 13 Spring事件监听机制_@EventListener源码解析
文章目录 Pre 概览开天辟地的时候初始化的处理器 @EventListener EventListenerMethodProcessor afterSingletonsInstantiated 小 ...
Spring源码深度解析(郝佳)-学习-Spring消息-整合RabbitMQ及源码解析
我们经常在Spring项目中或者Spring Boot项目中使用RabbitMQ,一般使用的时候,己经由前人将配置配置好了,我们只需要写一个注解或者调用一个消息发送或者接收消息的监听器即可,但是底 ...
覆盖式理解Android 消息处理机制（带源码解析）
转载自:https://www.jianshu.com/p/02962454adf7 Android 消息处理机制估计都被写烂了,但是依然还是要写一下,因为Android应用程序是通过消息来驱动的,A ...
【kubernetes/k8s源码分析】eviction机制原理以及源码解析
kubernetes v1.12.1 What? kubelet 驱赶的是节点上的某些 Pod,驱赶哪些 Pod与 Qos 机制有关(1.8),1.9 以后的版本请看下文分解只有当节点内存和磁盘资源 ...

Handler消息机制（九）：IntentService源码解析

简介