瞧那顽固的Service~
項目收货：
1.如果一个service被你在任务管理器中kill了，那么这个service的onDestory（）方法是不会执行的。
如果这个service的 onStartCommand()方法的返回值startId 是用的默认的
return super.onStartCommand(intent, flags, startId);就相当于返回的是"
For backwards compatibility, the default implementation calls onStart and returns either START_STICKY or START_STICKY_COMPATIBILITY. "
这个startId是会在你的这个service被杀死后自己又重启，所谓就是就是service的默认构造函数被执行一次，onCreate()方法被执行一次，效果和第一次
context.startService(intent) 两处不一样，
1.这是如同是自己new Service()就得不到那个 intent对象。所以那个intent对象是null。
2.这个重启后的service不会再去执行他的onStartCommand()方法了。 重启的service会执行两个方法 第一是自己的默认构造函数，第二是onCreate)(）函数。
service注意：①对于一个已经存在的service对象，你多次调用context.startService(intent)只会在第一次执行service的构造函数和onCreate()函数，以后都是调用
onStartCommand(),所以你有那些一定要在后台搞鬼的程序要运行 要么写在构造函数里，要么写在 onCreate()函数里，因为如果写在onStartCommand()中一旦用户在任务管理器中
把它杀死了 你的搞鬼代码 就再也没机会被执行到了(还有设置START_STICKY在真机2.3.4和模拟器2.2上效果不一样，模拟器每次都会执行onStartCommand，但是真机却没有执行。但是onCreate()都会执行。)。
②如果对一个没有start过的service调用 context.stopService(intent);是没点动静的，对于运行的service也只对第一次调用会去调用service自己的onDestory()方法。而且调
用了之后那个new出来的别的线程还是在那里运行。好像没理你一样。实际上还是那回事，你结束的是service的生命，不是那个new 的thread啊！所以这个时候你要是还 手动把那
个运行的项目进程结束(此时进程中有你new的那个线程和主线程ui线程了，还有一些其他的线程),那么 不管你的onStartCommand()返回的startId是 START_STICKY还是START_REDELIVER_INTENT 这个service都不会再重启了，因为他的生命周期已经stop了啊!
③安卓的 service 被我手动杀死 4次后终于不再重新启动了。在第3次和第4次启动之间间隔了24秒，蛮久的，似乎意味着“这是最后的晚餐”一样时间酝酿的长点。
结果……大约是 5分19秒后 顽固地又 I'am back！！！所以我想说，START_REDELIVER_INTENT 和 START_STICKY真是个 “黏住了”总是会启动的。
不用去试了，实验再多的次数 也没用，总是会重启，我实验到了 第8次还是“涛声依旧”~。
如果你真的不想 让这个service被 手动杀死后 再次起来，你把 onStartCommand()的返回值 改成 Service.START_NOT_STICKY;被杀死后就不会在起来了。
如何打造更加 顽固地Service了？看这里。http://blog.csdn.net/joychine/article/details/10947819
欢迎各路人马 指正批评，不对之处麻烦指出来，共同修正，共同进步，为祖国的繁荣昌盛奋斗不息，为中华民族屹立于世界名族之林而鞠躬尽瘁~