Servie是系统的组件，它由系统进程托管（servicemanager）；它们之间的通信类似于client（客户端）和server（服务端），是一种轻量级的IPC（Inter-Process Communication，进程间通信）通信，这种通信的载体是binder，它是在linux层交换信息的一种IPC。而Thread是由本应用程序托管。
1）Thread
Thread 是程序执行的最小单元，它是分配CPU的基本单位。可以用 Thread 来执行一些异步的操作。在java中可以通过直接继承Thread或实现Runnable来实现。如下：
// 继承Thread类实现线程
public MyThread extends Thread {
@Override
public void run() {
// 业务代码
}
}
// 使用实现Runnable来实现线程
class MyThreadInner2 implements Runnable{
@Override
public void run() {
// 业务代码
}
}2）Service
Service 是android的一种机制，当它运行的时候如果是Local Service，那么对应的 Service 是运行在主进程的 main 线程上的。如：onCreate，onStart 这些函数在被系统调用的时候都是在主进程的 main 线程上运行的。如果是Remote Service，那么对应的 Service 则是运行在独立进程的 main 线程上。
既然这样，那么我们为什么要用 Service 呢？
其实这跟 android 的系统机制有关，我们先拿 Thread 来说。Thread 的运行是独立于 Activity 的，也就是说当一个 Activity 被 finish 之后，如果你没有主动停止 Thread 或者 Thread 里的 run 方法没有执行完毕的话，Thread 也会一直执行。因此这里会出现一个问题：当 Activity 被 finish 之后，你不再持有该 Thread 的引用。另一方面，你没有办法在不同的 Activity 中对同一 Thread 进行控制。
如果你的 Thread 需要不停地隔一段时间就要连接服务器做某种同步的话，该 Thread 需要在 Activity 没有start的时候也在运行。这个时候当你 start 一个 Activity 就没有办法在该 Activity 里面控制之前创建的 Thread。因此你便需要创建并启动一个 Service ，在 Service 里面创建、运行并控制该 Thread，这样便解决了该问题（因为任何 Activity 都可以控制同一 Service，而系统也只会创建一个对应 Service 的实例）。
因此你可以把 Service 想象成一种消息服务，而你可以在任何有 Context 的地方调用 Context.startService、Context.stopService、Context.bindService，Context.unbindService，来控制它，你也可以在 Service 里注册 BroadcastReceiver，在其他地方通过发送 broadcast 来控制它，当然这些都是 Thread 做不到的。
根据进程优先级，Thread在后台运行（Activty stop）的优先级低于后台运行的Service，如果执行系统资源紧张，会优先杀死前一种，后台运行的Service一般情况下不会被杀死，如果被杀死，系统空闲时会重新启动service。
