Android Service之onStartCommand方法研究

最近在看Service，发现对于Service的两种启动方式，一种startService(Intent service)，一种是bindService(Intent service, ServiceConnection conn, int flags)；使用第一种方式的时候每次都会调用int  onStartCommand(Intent intent, int flags, int startId)方法，而第二种则不会，我不禁想这是为什么呢？要理解这个问题，可能要需要从onStartCommand方法的返回值来说起。

Google的文档上说明，onStartCommand主要有如下几个返回值：

public static final int START_CONTINUATION_MASK

这个返回值代表的意思是：如果服务被杀死了之后要如何进行后续工作，它可能是 START_STICKY ,  START_NOT_STICKY ,  START_REDELIVER_INTENT , or  START_STICKY_COMPATIBILITY中的一个




Constant Value: 15 (0x0000000f) 

public static final int START_NOT_STICKY

这个返回值代表的意思是：非粘性的启动服务，如果这个服务在启动之后被杀死，那么除非另一个intent要重新启动它，否则不会重启它

Constant Value: 2 (0x00000002) 

public static final int START_REDELIVER_INTENT

这个返回值代表的意思是：如果这个服务启动之后被杀死，那么会安排一个计划对其进行重启，会将上一次发送的intent通过onStartCommand再次发送给它，这个intent对象会被保留着，直到这个服务调用了 stopSelf(int)方法，这个int参数就是之前onStartCommand方法中的参数启动ID。该服务不会收到值为null的intent，因为它只会在进程任务还没有完成，还有没有发送的intent时才会自动重启。

这种模式适用于需要立即恢复的工作，比如说下载等

Constant Value: 3 (0x00000003) 

public static final int START_STICKY

这个返回值代表的意思是：如果一个服务在启动之后被杀死，那么让这个服务回到刚刚start（启动）的状态，但是不保留为启动这个服务而发出的intent，随后系统会试着重新创建这个服务。由于是刚刚回到启动状态，所以在创建了新的服务对象时会再次调用onStartCommand方法。如果没有命令传给这个服务，那么可能会传给它一个null的intent，需要在程序里对这个值进行检查。

该模式应用于对开始和结束时间都很明确的服务，比如后台音乐回放等.

Constant Value: 1 (0x00000001) 

public static final int START_STICKY_COMPATIBILITY

这个返回值代表的意思是：它是START_STICKY的兼容性模式，但是它无法保证服务被杀死之后一定会调用onStartCommand方法重启。

Constant Value: 0 (0x00000000) 

通过上面几个返回值我们可以看出，conStartCommand方法主要用途在于决定当服务被杀死之后，要如何处理的问题。而实际上使用bind方式启动则不存在这个需求，他可以通过调用服务内部方法来创建 绑定 解绑 和销毁服务，自由度更高。