如何避免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()。