android service杀死后又起来了

今天搞了一下午，每次service杀死了，结果又重启了，疼死了。

在网上找了半天，基本所有的回答都是围绕 onStartCommand方法返回值Service.START_NOT_STICKY，Service.START_STICKY，Service.START_REDELIVER_INTENT来回答的,然后我一个一个的试，还是不行。

我愤怒了，到底啥原因啊。

于是我想难道是其他关联的问题，反正该想的都想了，都没有用。

我想一定是我没有stop service，然后我很猥琐的在好多地方都加了stopself，结果很无耻的是，还是没有用。

就在我最后精疲力竭的时候，我冒出了一个方法，把所有的onDestroy 打log 看看到底走没有走这个方法，让我很意外的是居然没有走。然来在Process.killProcess(Process.myPid());后，不再走任何回调方法，吼吼，懂了。

于是我很窃喜的在kill方法之前stop了service，靠，解决了。

--------------   附  （摘自“android开发精要”） ---------------------------

• START_NOT_STICKY，如果onStartCommand()函数返回Service.START_NOT_STICKY,则说明系统可以无条件的回收该组件，而无需关注服务是否完成，也无需复杂服务的重新启动。通常，返回START_NOT_STICKY的服务，都是需要长时间运行服务组件，服务的时效性相对较低。为了在合适的时机重新启动服务，服务组建可以注册定时事件来保持长时间的运行。
• START_STICKY ，如果onStartCommand()函数返回Service.START_STICKY，那么系统会对该组件负责到底，在强行回收该组件后，在资源宽裕的时间还会调用Service.onStartCommand函数去重新启动该服务，直到该服务执行完成所有操作后主动调用stopSelf函数，才能最终关闭服务。
• START_REDELIVER_INTENT，如果onStartCommand()函数返回Service.START_REDELIVER_INTENT，则意味着需要保证系统该服务组件能够完整地处理每个Intent对象。如果在服务的后台处理过程中，系统强行终止了该服务，则要求系统在资源允许的情况下重新传入该Intent对象，直到服务组件处理完成，显性地调用stopSelf来关闭服务为止。