service中onStartCommand的返回值

继承Service类来实现一个被启动类型的服务很简单，如果你需要服务执行多线程（而不是通过工作队列来处理启动请求），那么你就要继承Service类来处理每个Intent。

 

继承Service类，onStartCommand()执行后，业务代码马上同时执行，不像IntentService那样以队列排队执行。

 

但是，因为你自己处理每个onStartCommand()方法的调用，你就能够同时执行多个请求。如果你想要这么做的话，那么你就能够给每个请求创建一个新的线程，并且立即运行它们（而不是等待前一个请求完成）。

 

注意:onStartCommand()方法必须返回一个整数，这个整数是一个描述了在系统的杀死事件中，系统应该如何继续这个服务的值（虽然你能够修改这个值，但是IntentService处理还是为你提供了默认实现）。从onStartCommand()方法中返回的值必须是以下常量：

 

START_NOT_STICKY

如果系统在onStartCommand()方法返回之后杀死这个服务，那么直到接受到新的Intent对象，这个服务才会被重新创建。这是最安全的选项，用来避免在不需要的时候运行你的服务。

 

START_STICKY

如果系统在onStartCommand()返回后杀死了这个服务，系统就会重新创建这个服务并且调用onStartCommand()方法，但是它不会重新传递最后的Intent对象，系统会用一个null的Intent对象来调用onStartCommand()方法，在这个情况下，除非有一些被发送的Intent对象在等待启动服务。这适用于不执行命令的媒体播放器（或类似的服务），它只是无限期的运行着并等待工作的到来。

 

START_REDELIVER_INTENT

如果系统在onStartCommand()方法返回后，系统就会重新创建了这个服务，并且用发送给这个服务的最后的Intent对象调用了onStartCommand()方法。任意等待中的Intent对象会依次被发送。这适用于那些应该立即恢复正在执行的工作的服务，如下载文件。

注意：以上行为只有在System kill event的情况下有效，stopSelf和stopService都不会过问onStartCommand的返回状态。

名词解释：

System kill:系统杀死服务，以释放内存，在低内存的情况下系统会自行操作,System kill之后的操作有onStartCommand的返回值决定，注意，正常结束服务是不会发生重启的，因为服务结束并不代表服务实例被释放，一个服务实例可以被多次启动，但是这并不表示产生了多个服务实例，从DDMS可以看到他们和hosting process使用同一个PID，服务实例是绑定在hosting process 主线程消息队列的（Message Queue）。