Service onStartCommand各种返回详解,解决问题:只调用onCreate不调用onStartCommand-阿里云开发者社区

开发者社区> 安全> 正文

Service onStartCommand各种返回详解,解决问题:只调用onCreate不调用onStartCommand

简介:

Service原理这里不介绍,只介绍onStartCommand的返回和Android Reference中的问题。


onStartCommand方法必须具有一个整形的返回值,这个整形的返回值是一个描述性质的数值,用来告诉系统在服务启动完毕后,一旦遇到服务被系统销毁(System kill),系统将如何继续(操作),这些返回值必须是以下一个:

START_NOT_STICKY

       如果系统在onStartCommand返回后被销毁,系统将不会重新创建服务,除非收到一个未处理(pending悬而未决地)的Intent,当不是必须(necessary)并且Android应用能够自行简单地(simply)重启未完成业务(不通过服务),那么这样的设定是最安全的(safest)。

START_STICKY

如果系统在onStartCommand返回后被销毁,系统将会重新创建服务并依次调用onCreate和onStartCommand(注意:根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand,Android4.0可以办到),重新创建的操作将会作为事件日程序列(schedule)加入到系统事件日程列表中,在延迟一个计算时间(如:5000ms)后重新启动。但是不会重新将之前的传入的Intent创新传递给、

onStartCommand除非重新收到一个未处理(pending悬而未决地)的Intent,在这种情况下(inwhich case),未处理的心得Intent仍然按照流程被传入和处理,但是前一次操作的Intent将会变null(等同于一次带null intent的启动)。对于不需要立刻执行命令的服务,如多媒体播放器(或者其他类似(similar)的服务)那么这样的设定是非常适合的,但是服务会无限期的运行,并等待一个适合的工作(个人理解:就是服务等于又重新启动恢复到之前的状态了)。

START_REDELIVER_INTENT

START_STICKY在重新调用onStartCommand的时候,之前的Intent将会被保留,并重新传递给该方法,除非此时出现了一次新的启动服务请求,那么Intent将会被替换成新的,否则仍然使用旧的Intent。经过测试Android2.3.3对于该操作同样有效。

注意:以上行为只有在System kill event的情况下有效,stopSelf和stopService都不会过问onStartCommand的返回状态。


名词解释:

System kill:系统杀死服务,以释放内存,在低内存的情况下系统会自行操作,System kill之后的操作有onStartCommand的返回值决定,注意,正常结束服务是不会发生重启的,因为服务结束并不代表服务实例被释放,一个服务实例可以被多次启动,但是这并不表示产生了多个服务实例,从DDMS可以看到他们和hosting process使用同一个PID,服务实例是绑定在hosting process 主线程消息队列的(Message Queue)。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章