onStartCommand方法返回有4种
- START_STICKY
- START_NOT_STICKY
- START_REDELIVER_INTENT
- START_STICKY_COMPATIBILITY
以下的情况都是在服务启动后,onStartCommand()返回值之后,服务被系统KILL了之后的情况描述。
START_STICKY 指系统会重新创建service,然后呢由于重新创建了service,那么onstartCommand方法就一定会被重新调用,如果这个时候,没有其他启动service的命令传过来,那么这个时候的Intent就是null,这里需要注意一下。
START_STICKY_COMPATIBILITY: 这个其实是用来兼容api5 一下的,这个的作用和START_STICK一样,但是这个返回值不能保证系统一定会重新创建service
START_REDELIVER_INTENT: 这个是指服务被重新创建后,直接将之前Intent的值传入,和上面START_STICK不同,这里的Intent不会为null。
START_NOT_STICKY: 这个就是系统被kill了,服务不会重新启动。
接下来看看我们的service源码
public @StartResult int onStartCommand(Intent intent, @StartArgFlags int flags, int startId) {
onStart(intent, startId);
return mStartCompatibility ? START_STICKY_COMPATIBILITY : START_STICKY;
}
发现 service里面是默认自动重新创建的,其中mStartCompatibility的值是通过下面的带来赋值的
mStartCompatibility = getApplicationInfo().targetSdkVersion
< Build.VERSION_CODES.ECLAIR;
在看看IntentService源码
@Override
public int onStartCommand(@Nullable Intent intent, int flags, int startId) {
onStart(intent, startId);
return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
}
这里的mRedelivery是通过这个set方法设置的。
public void setIntentRedelivery(boolean enabled) {
mRedelivery = enabled;
}
在使用IntentService的时候,我们一般是不重写onStartCommand()方法的,而是使用onHandleIntent方法,然后通过之前的set方法去设置那个返回值。
接下来看看JobIntentService
@Override
public int onStartCommand(@Nullable Intent intent, int flags, int startId) {
if (mCompatQueue != null) {
mCompatWorkEnqueuer.serviceStartReceived();
if (DEBUG) Log.d(TAG, "Received compat start command #" + startId + ": " + intent);
synchronized (mCompatQueue) {
mCompatQueue.add(new CompatWorkItem(intent != null ? intent : new Intent(),
startId));
ensureProcessorRunningLocked(true);
}
return START_REDELIVER_INTENT;
} else {
if (DEBUG) Log.d(TAG, "Ignoring start command: " + intent);
return START_NOT_STICKY;
}
}
虽然没有使用过这个service(刚刚在看源码的时候发现了这个类),这里可以看到如果请求队列不是空,则重新创建,并将之前的Intent传入,如果队列是空的,则就不重新创建了。