Android中Service和Thread区别

在工作中，有时会被人问到，Android中的Service和Thread有什么区别，为什么有时放着方便的Thread不用，而去使用Service呢？
首先，要说明的是，进程是系统中最小的资源分配单位，而线程是最小的执行单位，线程需要的资源通过它所在的进程获取。
区别：
Thread：Thread是程序执行的最小单元，可以用Thread来执行一些异步的操作。
Service：是Android的四大组件之一，被用来执行长时间的后台任务。这里的后台指的是，它的运行是完全不依赖UI的。但是还是运行在主进程的main线程上的。也就是说如果你在Service里执行了非常耗时的代码，程序同样会出现ANR的。总之，Service和Thread之间没有任何关系！

Thread的运行是独立的，也就是说当一个Activity被finish之后，如果没有主动停止Thread或者Thread里面的run方法没有执行完毕的话，Thread会一直执行。因此会出现一个问题：当Activity被finish之后，不再持有该Thread的引用，也就是不能在控制该thread，另外，我们无法在不同的Activity中对同一个Thread进行控制。
这时，如果创建并启动一个 Service ，在 Service 里面创建、运行并控制该 Thread，这样便解决了该问题(因为任何 Activity 都可以控制同一个Service，而系统也只会创建一个对应 Service 的实例)。
因此可以把 Service 想象成一种消息服务，可以在任何有 Context 的地方调用 Context.startService、Context.stopService、Context.bindService、Context.unbindService来控制它，也可以在 Service 里注册 BroadcastReceiver，通过发送 broadcast 来达到控制的目的，这些都是 Thread 做不到的。

所以，其实我们不要把后台和子线程联系在一起，这是两个完全不同的概念。Android的后台就是指，它的运行是完全不依赖UI的。即使Activity被销毁，或者程序被关闭，只要程序进程还在，Service就可以继续运行。你可能又会问，前面不是说过Service是运行在主线程里的么？在这里一直执行着耗时连接，难道就不会阻塞主线程的运行吗？当然会，但是我们可以在Service中再创建一个子线程，然后在这里去处理耗时逻辑就没问题了。

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