我无法理解
- START_STICKY,
- START_NOT_STICKY 和
- START_REDELIVER_INTENT
任何人都可以用例子清楚地解释。
我浏览了这个链接,但无法清楚地理解它。
这些与服务有关。我们都知道服务会在后台继续运行,它们也会消耗一些内存来执行。
所以,随着越来越多的应用程序在android设备上运行,设备内存不断变低,到时候,当设备内存严重不足时,android系统开始终止进程,以释放进程占用的内存.
但是您可能正在对服务执行一些重要任务,这些任务也可能在服务停止时终止。所以这些概念是告诉android系统当设备内存稳定以及准备好重新启动服务时你想要执行什么操作。
对这些最简单的解释可能是,
START_STICKY-
告诉系统在从低内存恢复后,在有足够内存可用时创建服务的新副本。在这里,您将丢失之前可能计算过的结果。
START_NOT_STICKY-
告诉系统不要费心重新启动服务,即使它有足够的内存。
START_REDELIVER_INTENT-
告诉系统在崩溃后重新启动服务,并重新传递崩溃时存在的意图。
好吧,我阅读了您链接中的主题,它说明了一切。
如果您的服务由于内存不足而被 Android 杀死,并且 Android 清除了一些内存,那么...
onStartCommand()
服务,因为,再次,标志。仅当手机内存不足并在服务完成执行之前终止服务时,这两个代码才相关。START_STICKY 告诉操作系统在它有足够的内存后重新创建服务,并以空意图再次调用 onStartCommand()。START_NOT_STICKY 告诉操作系统不要再费心重新创建服务。还有第三个代码 START_REDELIVER_INTENT 告诉操作系统重新创建服务并将相同的意图重新传递给 onStartCommand()。
Dianne Hackborn 的这篇文章比官方文档更好地解释了这个背景。
来源:http ://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html
这里的关键部分是函数返回的新结果代码,告诉系统如果它的进程在运行时被杀死,它应该如何处理服务:
START_STICKY 与之前的行为基本相同,服务保持“启动”状态,稍后将由系统重新启动。与平台先前版本的唯一区别是,如果它因为进程被终止而重新启动,onStartCommand() 将在服务的下一个实例上以空 Intent 调用,而不是根本不调用。使用此模式的服务应始终检查此情况并适当处理。
START_NOT_STICKY 表示,在从 onStartCreated() 返回后,如果进程被杀死且没有剩余的启动命令可交付,则服务将停止而不是重新启动。这对于仅在执行发送给它们的命令时才运行的服务更有意义。例如,一项服务可能会从警报开始每 15 分钟启动一次,以轮询某些网络状态。如果它在做这项工作时被杀死,最好让它停止并在下次警报触发时启动。
START_REDELIVER_INTENT 类似于 START_NOT_STICKY,除非服务的进程在它为给定意图调用 stopSelf() 之前被终止,否则该意图将被重新传递给它,直到它完成(除非经过多次尝试它仍然无法完成,此时系统放弃)。这对于接收工作命令的服务很有用,并希望确保它们最终完成每个发送命令的工作。