Service onStartCommand各种返回详解，解决问题：只调用onCreate不调用onStartCommand

service原理这里不介绍，只介绍onstartcommand的返回和android reference中的问题。

onstartcommand方法必须具有一个整形的返回值，这个整形的返回值是一个描述性质的数值，用来告诉系统在服务启动完毕后，一旦遇到服务被系统销毁（system kill），系统将如何继续（操作），这些返回值必须是以下一个：

start_not_sticky

       如果系统在onstartcommand返回后被销毁，系统将不会重新创建服务，除非收到一个未处理（pending悬而未决地）的intent，当不是必须（necessary）并且android应用能够自行简单地（simply）重启未完成业务（不通过服务），那么这样的设定是最安全的（safest）。

start_sticky

如果系统在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_redeliver_intent

同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）。