Android-Service(onStartCommand详解)

2,609 阅读2分钟

在上一篇我们总结了Android中的Service,接下来这篇就围绕着其中的一个生命周期方法onStartCommand()进行总结。

之前Service中的onStart()方法已经被废弃了,取而代之的是onStartCommand()方法,该方法有三个参数

public int onStartCommand(Intent intent, int flags, int startId)
  • 第一个参数是启动过来的Intent信息,也就是调用者的Intent信息
  • 第二个参数flags代表着启动请求的附加参数,由系统传入
    • 通过startService()启动,flags传入0
    • onStartCommand()返回值为START_STICKY_COMPATIBILITY或者START_STICKY并且服务被强制杀死时重启后,flags传入START_FLAG_REDELIVERY(1)
    • onStartCommand()返回值为START_REDELIVER_INTENT并且服务被强制杀死重启后,flags传入START_FLAG_REDELIVERY(2)
  • 第三个参数为启动的ID,每次启动都对应不同的ID,与stopSelf()连同停止Service

执行时机

当通过startService()启动时,多次执行startService(),但是生命周期函数onCreate()只会执行一次,而onStartCommand()会执行多次,当通过bindService()启动Service时,不会执行onStartCommand()方法。

返回值与自启动机制

当Service被强行停止的时候,例如使用kill命令强行关闭,通过配置参数可以让Service重新启动

onStartCommand()不同的返回值又对Service重启有不同的影响(上述的参数配置)

  • START_STICKY

    • onStartCommand默认的返回值,表示Service被杀掉后会重新启动,但是不会携带之前的Intent信息
    • 例如我们的系统可以接受在任意时刻被杀死,并且重启的时候不需要Intent信息,就可以用此返回值,例如播放音乐
  • START_NOT_STICKY

    • Service被kill后,不会进行重启
    • 适用于在Service中执行一些无关紧要的工作,被杀掉了也无需关心
  • START_REDELIVER_INTENT

    • Service被杀掉后,会进行重新启动,并且还会携带之前的Intent信息
    • 适用于对Intent有强依赖性的Service,重启后必须获得之前的Intent信息

在小米手机上,必须为app手动开始自启动权限,否则被杀掉的Service不管在onStartCommand中设置什么返回值都不会重启

参考链接