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中的一个
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方式启动则不存在这个需求，他可以通过调用服务内部方法来创建 绑定 解绑 和销毁服务，自由度更高。
更多相关文章
- No.11 使用firewall配置的防火墙策略的生效模式
- [已解决] MediaPlayer.setVolume设置声音大小失效问题
- android AppWidgetProvider 使用方法
- Android(安卓)7.1.1 Toast引起的Crash
- Bundle源码解析
- Android剪切板设置和读取字符串String 关键代码
- Android改变手机屏幕朝向的方法
- android Fragment 常用api方法
- 深入浅出 - Android系统移植与平台开发（十三） - Sensor HAL框架分