Service,Activity,Thread?

Service和Activity均运行在主线程，如果在Service中执行耗时操作也必然会引起线程阻塞出现ANR，如果要在Service执行耗时操作需要创建Thread，通过Service生命周期的回调来控制Thread的生命周期。

直接StartService

Service既不能直接执行耗时操作，又不能提供界面，那么为什么还需要Service这个组件呢？

个人理解原因有二：（1）后台=/=子线程；（2）Service能办到的Activity做不到

（1）Service和Thread

如果你要下载图片，然后在当前activity上显示，就用多线程；能够从逻辑上区分开来，又或者耗时较长，就用后台服务。Thread 是程序执行的最小单元，它是分配CPU的基本单位。可以用 Thread 来执行一些异步的操作。Service 是android的一种机制，当它运行的时候如果是Local Service，那么对应的 Service 是运行在主进程的 main 线程上的。如：onCreate，onStart 这些函数在被系统调用的时候都是在主进程的 main 线程上运行的。如果是Remote Service，那么对应的 Service 则是运行在独立进程的 main 线程上。线程和Service是没有任何关系的。因此你可以把 Service 想象成一种消息服务，而你可以在任何有 Context 的地方调用 Context.startService、Context.stopService、Context.bindService，Context.unbindService，来控制它，你也可以在 Service 里注册 BroadcastReceiver，在其他地方通过发送 broadcast 来控制它，当然这些都是 Thread 做不到的。

（2）Service和Activity

既然Service里执行耗时操作也需要创建子线程，那么为什么不直接在Activity中创建呢？这是因为Service的生命周期可以和app进程的生命周期一样长（突然脑洞想到了Application，和Service均继承自ContextWrapper）。

Context，Activity，Service，Application继承关系

具体来讲如果是以bind启动，生命周期和Activity相同；如果以start启动，那么Service的生命周期和Activity就无关了。即使Activity被销毁了，只要进程还在，Service就可以继续运行。这样就导致，当我们需要做一些始终与服务器保持联系的操作（比如离线）时，如果在Activity中创建Thread，会很难控制其生命周期。比如当一个Activity被销毁后，就没有办法可以再重新获取到之前在这个Activity中创建的子线程实例。另外，在一个Activity中创建的子线程，另一个Activity也无法对其进行操作。但有了Service，所有的Activity都可以与Service关联绑定，然后可以很方便地操作其中的方法，即使Activity被销毁了，之后只要重新与Service建立关联，就又能够获取到原有的Service中Binder的实例。简言之：一个Thread通过Service可以被多个Activity调用，但Thread通过Activity只能被这一个Activity控制。

三者关系