Android中Service与Thread的关系

Service和Thread到底有什么关系呢？什么时候应该用Service，什么时候又应该用Thread？答案可能会有点让你吃惊，因为Service和Thread之间没有任何关系！

之所以有不少人会把它们联系起来，主要就是因为Service的后台概念。Thread我们大家都知道，是用于开启一个子线程，在这里去执行一些耗时操作就不会阻塞主线程的运行。而Service我们最初理解的时候，总会觉得它是用来处理一些后台任务的，一些比较耗时的操作也可以放在这里运行，这就会让人产生混淆了。但是，如果我告诉你Service其实是运行在主线程里的，你还会觉得它和Thread有什么关系吗？让我们看一下这个残酷的事实吧。
在MainActivity的onCreate()方法里加入一行打印当前线程id的语句：

Log.d("MyService", "MainActivity thread id is " + Thread.currentThread().getId());  

然后在MyService的onCreate()方法里也加入一行打印当前线程id的语句：

Log.d("MyService", "MyService thread id is " + Thread.currentThread().getId()); 

结果如下：

可以看到，它们的线程 id 完全是一样的，由此证实了 Service 确实是运行在主线程里的，也就是说如果你在 Service 里编写了非常耗时的代码，程序必定会出现 ANR 的。
你可能会惊呼，这不是坑爹么！？那我要 Service 又有何用呢？其实大家不要把后台和子线程联系在一起就行了，这是两个完全不同的概念。 Android 的后台就是指，它的运行是完全不依赖 UI 的。即使 Activity 被销毁，或者程序被关闭，只要进程还在， Service 就可以继续运行。比如说一些应用程序，始终需要与服务器之间始终保持着心跳连接，就可以使用 Service 来实现。你可能又会问，前面不是刚刚验证过 Service 是运行在主线程里的么？在这里一直执行着心跳连接，难道就不会阻塞主线程的运行吗？当然会，但是我们可以在 Service 中再创建一个子线程，然后在这里去处理耗时逻辑就没问题了。

既然在Service里也要创建一个子线程，那为什么不直接在Activity里创建呢？这是因为Activity很难对Thread进行控制，当Activity被销毁之后，就没有任何其它的办法可以再重新获取到之前创建的子线程的实例。而且在一个Activity中创建的子线程，另一个Activity无法对其进行操作。但是Service就不同了，所有的Activity都可以与Service进行关联，然后可以很方便地操作其中的方法，即使Activity被销毁了，之后只要重新与Service建立关联，就又能够获取到原有的Service中Binder的实例。因此，使用Service来处理后台任务，Activity就可以放心地finish，完全不需要担心无法对后台任务进行控制的情况。