进程与service被杀死一般几种情况嘛。异常、用户或安全管理软件清理、系统。
要让进程或服务常驻,异常不考虑。
剩下就是两种情况,防止被系统杀死,防止被清理。
一、背景
(1) service是进程内的组件,所以推测其生命周期应该收进程影响吧。
(2) 进程被系统清理会是系统内存不足或者长时间没有处于后台进程(没有产生交互),
现在大多数手机内存都够了,应该是后者为主吧(观察到自己的手机应用的进程运行时间基本没有超过3小时的)
二、1、service有几个特性控制service重启,达到service常住后台的目的
这里有三个变,表示在service所在的进程被kill之后,如何处理service:
1、 START_STICKY
在运行onStartCommand后service进程被kill后,那将保留在开始状态,但是不保留那些传入的intent。如果没有传递任何开始命令给service,那将获取到null的intent
2、 START_NO_STICKY
在运行onStartCommand后service进程被kill后,并且没有新的intent传递给它。Service将移出开始状态,并且直到新的明显的方法(startService)调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动,也就是期间onstartCommand不会接收到任何null的intent。
3、 START_REDELIVER_INTENT
在运行onStartCommand后service进程被kill后,系统将会再次启动service,并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent,那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。
START_STICKY和 START_STICKY:当进程被杀死后onDestroy()是不会被执行的!
START_REDELIVER_INTENT :当进程被杀死后onDestroy()会被执行!
1、 START_STICKY
在运行onStartCommand后service进程被kill后,那将保留在开始状态,但是不保留那些传入的intent。如果没有传递任何开始命令给service,那将获取到null的intent
2、 START_NO_STICKY
在运行onStartCommand后service进程被kill后,并且没有新的intent传递给它。Service将移出开始状态,并且直到新的明显的方法(startService)调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动,也就是期间onstartCommand不会接收到任何null的intent。
3、 START_REDELIVER_INTENT
在运行onStartCommand后service进程被kill后,系统将会再次启动service,并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent,那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。
START_STICKY和 START_STICKY:当进程被杀死后onDestroy()是不会被执行的!
START_REDELIVER_INTENT :当进程被杀死后onDestroy()会被执行!
代码注释里面是这样说的,但是好像没有什么实际用处,因为进程在APP管理器关闭或者被手机管家调用此功能关闭之后,服务并不能重启。
估计service只是进程内的组件,进程都不存在了,service并不能有用吧。
三、设置应用的一些属性,降低进程被清理的可能性。
(1)提高优先级
(2)android:persistent="true"
(3)让应用成为系统应用
四、就是网上的开启双进程守护。