service onStartCommand()注意点

2.0 API level之后，实现onStart等同于重写onStartCommand并返回START_STICKY  

@Override  

public void onStart(Intent intent, int startId) {  

handleCommand(intent);  

}  

// 2.0 API level之后，onStart()方法被onStartCommand()取代了  

@Override  

public int onStartCommand(Intent intent, int flags, int startId) {  

handleCommand(intent);  

// We want this service to continue running until it is explicitly  

// stopped, so return sticky.  

return START_STICKY;  

}   

启动服务时依次执行onCreate，onStartCommand，onStart；如果在系统显示调用stopService和stopSelf之前终止服务，service再次重启，onStartCommand会被调用，重启服务时依次执行onStartCommand，onStart。无论何时，都会先调用onStartCommand()，在调用onStart()。  

onStartCommand返回值  

onStartComand使用时，返回的是一个(int)整形。  

这个整形可以有四个返回值：START_STICKY、START_NO_STUCKY、START_REDELIVER_INTENT、START_STICKY_COMPATIBILITY。  

它们的含义分别是：  

1):START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。  

2):START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务  

3):START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。   

4):START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。  

onStartComand参数flags含义  

flags表示启动服务的方式：  

Additional data about this start request. Currently either 0, START_FLAG_REDELIVERY, or START_FLAG_RETRY.  

START_FLAG_REDELIVERY：如果你实现onStartCommand()来安排异步工作或者在另一个线程中工作, 那么你可能需要使用START_FLAG_REDELIVERY来让系统重新发送一个intent。这样如果你的服务在处理它的时候被Kill掉, Intent不会丢失.  

START_FLAG_RETRY：表示服务之前被设为START_STICKY，则会被传入这个标记。