简介

首先我们先来了解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类的介绍，帮助大家理解。