Service原理这里不介绍，只介绍onStartCommand的返回和Android Reference中的问题。
onStartCommand方法必须具有一个整形的返回值，这个整形的返回值是一个描述性质的数值，用来告诉系统在服务启动完毕后，一旦遇到服务被系统销毁（System kill），系统将如何继续（操作），这些返回值必须是以下一个：
START_NOT_STICKY
如果系统在onStartCommand返回后被销毁，系统将不会重新创建服务，除非收到一个未处理（pending悬而未决地）的Intent，当不是必须（necessary）并且Android应用能够自行简单地（simply）重启未完成业务（不通过服务），那么这样的设定是最安全的（safest）。
如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以 下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），重新创建的操作将会作为事件日程序列 （schedule）加入到系统事件日程列表中，在延迟一个计算时间（如：5000ms）后重新启动。但是不会重新将之前的传入的Intent创新传递 给、
onStartCommand，除非重新收到一个未处理（pending悬 而未决地）的Intent，在这种情况下（inwhich case），未处理的心得Intent仍然按照流程被传入和处理，但是前一次操作的Intent将会变null（等同于一次带null intent的启动）。对于不需要立刻执行命令的服务，如多媒体播放器（或者其他类似（similar）的服务）那么这样的设定是非常适合的，但是服务会 无限期的运行，并等待一个适合的工作（个人理解：就是服务等于又重新启动恢复到之前的状态了）。
同START_STICKY，在重新调用onStartCommand的时候，之前的Intent将会被保留，并重新传递给该方法，除非此时出现了一次新的启动服务请求，那么Intent将会被替换成新的，否则仍然使用旧的Intent。经过测试Android2.3.3对于该操作同样有效。
注意：以上行为只有在System kill event的情况下有效，stopSelf和stopService都不会过问onStartCommand的返回状态。
名词解释：
System kill:系统杀死服务，以释放内存，在低内存的情况下系统会自行操作,System kill之后的操作有onStartCommand的返回值决定，注意，正常结束服务是不会发生重启的，因为服务结束并不代表服务实例被释放，一个服务实例可以被多次启动，但是这并不表示产生了多个服务实例，从DDMS可以看到他们和hosting process使用同一个PID，服务实例是绑定在hosting process 主线程消息队列的（Message Queue）。