有什么区别START_STICKY and START_NOT_STICKY在android中实现服务时?谁能指出一些标准示例..?
这两个代码仅在手机内存不足并在服务完成执行之前终止服务时才相关。START_STICKY
告诉操作系统在有足够的内存并调用后重新创建服务onStartCommand()
再次毫无意图。START_NOT_STICKY
告诉操作系统不要再费心重新创建服务。还有第三个代码START_REDELIVER_INTENT
告诉操作系统重新创建服务并重新传递相同的意图onStartCommand()
.
Dianne Hackborn 的这篇文章比官方文档更好地解释了这一背景。
Source: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html
这里的关键部分是函数返回的新结果代码,
告诉系统如果服务的进程应该如何处理
运行时被杀死:
START_STICKY 与之前的行为基本相同,其中
服务保持“启动”状态,稍后将由系统重新启动。
该平台与之前版本的唯一区别是
如果由于进程被终止而重新启动,则 onStartCommand()
将在具有 null Intent 的服务的下一个实例上调用
而不是根本不被调用。使用此模式的服务应该
经常检查这种情况并适当处理。
START_NOT_STICKY 表示,从 onStartCreated() 返回后,如果
该进程被终止,没有剩余的启动命令可以传递,
那么该服务将被停止而不是重新启动。这使得
对于仅在以下情况下运行的服务更有意义
执行发送给他们的命令。例如,可以启动一个服务
从警报起每 15 分钟轮询一次网络状态。如果得到
在做这项工作时被杀,最好就让它这样
停止并在下次警报响起时开始。
START_REDELIVER_INTENT 类似于 START_NOT_STICKY,除非
服务进程在调用给定的 stopSelf() 之前被终止
意图,该意图将被重新传递给它,直到它完成
(除非经过多次尝试后它仍然无法完成,在
系统放弃的点)。这对于以下服务很有用
收到要做的工作的命令,并希望确保他们这样做
最终完成发送的每个命令的工作。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)