发布于 2012-12-27 12:35:17
这些都与服务有关。我们都知道,服务在后台继续运行,它们也消耗了一些内存来执行。
因此,随着越来越多的应用程序在android设备上运行,设备内存不断降低,当设备内存变得非常低时,android系统开始终止进程,从而释放进程占用的内存。
但是您可能正在对服务执行一些重要的任务,这也可能在服务停止时终止。因此,这些概念是告诉android系统,当设备内存稳定时,以及当它准备重新启动服务时,您想要执行什么操作。
最简单的解释就是,
START_STICKY-告诉系统,在服务从低内存恢复后,当有足够的内存可用时,创建服务的新副本。在这里,您将失去以前计算过的结果。
START_NOT_STICKY-告诉系统,即使它有足够的内存,也不要麻烦地重新启动服务。
START_REDELIVER_INTENT-告诉系统在崩溃后重新启动服务,并重新传递崩溃时存在的意图。
发布于 2012-12-27 12:35:33
嗯,我在你的链接里读了那条线,上面写的都是。
如果您的服务由于内存不足而被Android杀死,而Android清除了一些内存,那么.
onStartCommand()重新传递相同的意图,因为再次使用标志。发布于 2013-11-12 16:10:30
这两种代码只有在手机耗尽内存并在服务完成执行之前终止服务时才有意义。START_STICKY告诉操作系统在拥有足够的内存后重新创建服务,并再次调用onStartCommand(),结果为null。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(),而不是完全不调用它。使用此模式的服务应该始终检查这种情况,并对其进行适当处理。 START_NOT_STICKY说,在从onStartCreated()返回之后,如果进程被终止,没有剩余的启动命令要交付,那么服务将停止而不是重新启动。对于那些只在执行发送给它们的命令时才能运行的服务来说,这更有意义。例如,可能每15分钟启动一次服务,从警报开始轮询某个网络状态。如果它在做这件事时被杀死了,最好让它停下来,下次警报响的时候就开始。 START_REDELIVER_INTENT类似于START_NOT_STICKY,除非该服务的进程在调用stopSelf()之前被终止,否则该意图将被重新传递到它,直到它完成为止(除非经过多次尝试,它仍然无法完成,此时系统就放弃了)。这对于接收要执行的工作命令的服务非常有用,并且希望确保它们最终完成发送的每个命令的工作。
https://stackoverflow.com/questions/14054588
复制相似问题