简介

首先我们先来了解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并创建Handler
    mThreadHandler = 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()方法的注释如下：

image.png

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

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

image.png
就是这2个方法对Loop进行了绑定。那这个sThreadLocal又是什么鬼？它到底有什么用？别急，我们去看下它创建的地方：
image.png
它其实就是一个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方法

@Override
    public 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的几个成员变量，如下图所示：

image.png

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

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

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

image.png

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

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

image.png

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

image.png

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

总结

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

image.png