android中Service使用startService

android中Service使用startService

两种情况得运用场景：

1、用于长期执行某些操作，并且甚至与UI（主）线程没有交互。比如启动app直接去网络下载文件

2、跨进程间通信，比如appA程序中Service被appB中程序调用

注意：Service默认时运行在它所在的宿主进程的主进程中，也就是说如果我们在Service中做耗时工作，UI（主）线程会卡死，出现ARN程序无响应现象。为了防止这种情况出现，我们一般都是在Service中创建一个新的线程来处理一些耗时工作，这样就不会阻塞主线程。从这里也侧面反映了Service不是另一个独立的进程，Service自己本身不会开辟新的进程，除非手动来设置。默认情况下，Service是运行在本运用程序所属的进程中。

Service启动模式也有两种，分别是：startService和bindService

1、通过startService方式启动

如果运行在后台的Service甚至不需要和UI（主）线程间进行交互，这种情况下，一般是调用startService来启动Service。

2、通过bindService方式启动

两个不同进程间通信或者某个应用中Service方法的暴露出去（同个进程间），一般是调用bindService来启动Service。

onCreate：如果多次执行了Context的startService方法启动Service，Service方法的onCreate方法只会在第一次创建Service的时候调用一次，以后均不会再次调用。我们可以在onCreate方法中完成一些Service初始化相关的操作

onStartCommand：如果多次执行了Context的startService方法，那么Service的onStartCommand方法也会相应的多次调用。onStartCommand方法很重要，我们在该方法中根据传入的Intent参数进行实际的操作，比如会在此处创建一个线程用于下载数据或播放音乐等

onBind：Service中的onBind方法是个抽象方法，所以Service类本身就是一个抽象类，也就是说onBind方法必须要重写，即使用不到。通过startService使用Service时，我们在重写onBind方法时，只需要将其返回值设为null即可。onBind方法主要是用于给bindService方法调用Service时才使用到。

onDestiny：Service销毁时回调函数

如果Service启动后没有去停止掉它，它会一直运行下去，停止startService启动的Service有两种方法：

1、在外部调用stopService

2、在Service内部调用stopSelf方法

值得注意的是在onStartCommand中返回值，常用的返回值有：START_NOT_STICKY、START_SICKY和START_REDELIVER_INTENT,这三个都是静态常理值。

START_NOT_STICKY：表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service，如果想重新实例化该Service，就必须重新调用startService来启动。

使用场景：表示当Service在执行工作中被中断几次无关紧要或者对Android内存紧张的情况下需要被杀掉且不会立即重新创建这种行为也可接受的话，这是可以在onStartCommand返回值中设置该值。如在Service中定时从服务器中获取最新数据

START_STICKY：表示Service运行的进程被Android系统强制杀掉之后，Android系统会将该Service依然设置为started状态（即运行状态），但是不再保存onStartCommand方法传入的intent对象，然后Android系统会尝试再次重新创建该Service，并执行onStartCommand回调方法，这时onStartCommand回调方法的Intent参数为null，也就是onStartCommand方法虽然会执行但是获取不到intent信息。

使用场景：如果你的Service可以在任意时刻运行或结束都没什么问题，而且不需要intent信息，那么就可以在onStartCommand方法中返回START_STICKY，比如一个用来播放背景音乐功能的Service就适合返回该值。

START_REDELIVER_INTENT：表示Service运行的进程被Android系统强制杀掉之后，与返回START_STICKY的情况类似，Android系统会将再次重新创建该Service，并执行onStartCommand回调方法，但是不同的是，Android系统会再次将Service在被杀掉之前最后一次传入onStartCommand方法中的Intent再次保留下来并再次传入到重新创建后的Service的onStartCommand方法中，这样我们就能读取到intent参数。

使用场景：如果我们的Service需要依赖具体的Intent才能运行（需要从Intent中读取相关数据信息等），并且在强制销毁后有必要重新创建运行，那么这样的Service就适合返回START_REDELIVER_INTENT。

接着补充一个知识点，Service进一步的封装类IntentService由于Service是运行在UI（主）线程中，会带来UI阻塞，所以在操作耗时工作时，都在onStartCommand中开启一个新的线程去执行一些耗时工作。正因为这样，创建一个带有工作线程Service是很常见的（因为工作线程不会阻塞主线程），为了简化程序员工作量，Android额外开发了一个类那就是IntentService

IntentService特点:

1. IntentService

自带一个工作线程，当我们的Service中做一些阻塞UI（主）线程工作时，可以使用IntentService。

2.将我们实际要做的工作放入到IntentService的onHandleIntent方法中处理，并且onHandleIntent运行在IntentService所持有的工作线程中，而非主线程。

3.当多次启动IntentService，产生多个job，IntentService只能一个一个处理，也就是按照先后顺序进行处理。先将intent1传入onHandleIntent，让其完成job1，然后将intent2传入onHandleIntent，让其完成job2…这样直至所有job完成，所以我们IntentService不能并行地执行多个job，只能一个一个的按照先后顺序完成，当所有job完成的时候IntentService就销毁了，会执行onDestroy回调方法