如何提高Service的优先级避免被杀死或者杀死后如何再次重启Service？

如何避免Service被系统杀死，随便在网上搜一下，都能搜到好几种方法，但是每一种方法都有不同的适用环境。

1. 添加android:persistent="true"

添加android:persistent="true"到AndroidManifest.xml，Google文档描述如下：

Whether or not the application should remain running at all times-true" if it should, and "false"if not. The default value is "false".Applications should not normally set this flag; persistence mode is intended only for certain system applications.可见这个属性不能随便用，到目前为止，我所发现使用该属性的应用只有Phone，而且使用是要求权限的，所以这个属性对第三方应用来说意义不是很大；

2. 设置onStartCommand（）的返回值

这个思路比较有用，我们着重分析一下，该方法有四种返回值：

START_STICKY


START_NOT_STICKY


START_REDELIVER_INTENT


START_STICKY_COMPATIBILITY

那么简单的说，四种模式的区别如下：

START_STICKY：kill后会被重启，但是重启后调用onStarfCommand（）传进来的Intent参数为null，说明被kill的时候没有保存Intent；

START_STICKY_COMPATIBILITY：START_STICKY的兼容版，但是不能保证onStartCommand()方法被调用，如果应用程序的targetSdkVersion 小于 2.0版本，就会返回该值，否则返回START_STICKY，同时再次启动时只会调用onCreate（），不保证能调用onStartCommand()方法

START_NOT_STICKY：kill之后不会被重启；

START_REDELIVER_INTENT：kill后会被重启，同时重启调用onStartCommand（）时再次传入保存的Intent。

启动一个service，然后在recent app里面杀死该进程，使用不同返回值时的log如下：

START_REDELIVER_INTENT

同上，不过传入的Intent为null，同时startId发生了变化，startId的官方解释是“A unique integer representing this specific request to start. Use with stopSelfResult(int)”，也就是说重启和第一次启动不是同一个request，也可以认为这是一个全新的request；

START_STICKY_COMPATIBILITY

这次重启根本就没有调用onStartCommand()方法；

START_NOT_STICKY

没有再次启动被杀掉的service。

测试的代码很简单，大家可以自己尝试。现在有一个问题：我们该如何判断启动的service是正常启动还是杀死后被重启的，因为有时候我们需要知道这些信息

原理：service所在的activity和running task栈顶的activity做比较，因为一旦service所在的activity被杀死，那么系统会跳转到其他应用，如比桌面，或者SystemUI，或者用户可以打开的task栈中的其他TOP activity，此时的running task栈顶的activity肯定不是被杀死的activity了。

可以发现，虽然安排了启动，但是很快就被Force Stop了，这样也就失去了被重启的机会，至于在Settings中杀死进程的原理，有机会咱们展开讲。

3. startForeground（）提高service的进程等级

我们知道Android进程分为5个等级：foreground process， visible process， Service process， background process， empty process，当系统资源吃紧的时候，会按照进程等级从低到高的顺序，同时根据进程消耗的资源从多到少的原则来kill一些进程，而service正处于第三个等级，如果能够提高service所在进程的等级，那么它被杀死的概率就会小一些。

可以利用Service的startForeground（）方法将Service的进程等级从第三级提升到第一级foreground process。

至于使用嘛，可以在在onCreate（）或者onStartComman()方法中调用，然后可以在onDestroy（）或者其他地方调用stopForeground(boolean removeNotification)方法来stop。

关于进程等级可访问：http://blog.csdn.net/llbupt/article/details/7358360

当然啦，网上还有一些其他的避免Service被杀死或者kill后重启的方法，比如监听android.intent.action.USER_PRESENT，来启动service，或者提高service IntentFilter的priority等，都能算是一些在某些特殊情况下可以其作用的方法，倒也不妨尝试一下。

还有人说用AlarmManager

监听系统启动的broadcast，然后每10秒一个周期，不停的发广播，这就是说应用一旦启动，就会不断的发广播，个人觉得这种方式不靠谱，原因如下：

1. 这样做无谓的操作，会消耗系统资源；

2. 一旦APP进程被杀死，怎么保证你的receiver不被杀死？

3. 不停的启动service，加入service中启动了其他的线程在做耗时的操作，这样做会产生大量的线程做重复的操作，即便service中没有启动其他线程，不断的调用onStartCommand()方法都不算是一个好办法。

当然了，如果实在没办法，必须得使用这种solution的话，我们可以判断service是否是alive，至于方法百度一下就有了。

至于有人说在onDestroy（）中重启service，上面打出来的log大家也看到了，被kill的时候都没机会去调用onDestroy（）。