What can I expect when onCreate() calls startService()

问题

I am trying to understand the Service Life Cycle while working through some Android Open Source Code.

I was looking at a Service implementation which I distilled down to something like the following...

public class MyService extends Service {
    public MyService() { super(); }

    @Override
    public void onCreate() {
       super.onCreate();
       init();

       //==this seems odd to me
       //comment in AOSP says startService() is called to make
       //sure Service stays around long enough for the async call
       //to complete.
       startService(new Intent(this, myservice.class()));
       doSomeMoreInitAsync();
    }

    @Override
    public int onStartCommand(final Intent intent, final int flags, final int startId) {
        if(actionableIntent(intent,flags,startId)) {
            //do something
            //NOTE: the Intent passed to startService() in onCreate()
            //above will go around this block of code, doing nothing
            //except returning START_STICKY
        }
        return START_STICKY;
    }

    public void onDestroy() {
        //destroy stuff
    }

    @Override
    public IBinder onBind(final Intent intent) {
        return mBinder; //an instance of android.os.Binder derivative
                        // created when this service was instantiated
    }

    //other stuff
}

Why would someone want to have onCreate() call startService() on itself like above, doing nothing? The comment in code sheds some light, but it's like assumptions are being made about the Life Cycle that I don't understand. I.e., is it reasonable to expect onCreate() to effectively start its own service?

I know that if a service has already been started then onCreate() will only be called once (unless destroyed and restarted, then a new instance of the service is created and onCreate() is called once on it). My first concern with this example would be that there is an expectation placed upon the underlying Service API implementation that the Service is already in the initialized state before onCreate() is called (else there be an infinite recursion, but there is not).

But isn't onCreate() supposed to be part of the initialization (albeit an optional part for the subclass)?

Is this coding logic a reasonable way of making sure the Service is forced to be an Unbounded Service? Or am I looking at a bad example in the AOSP which may have undefined behavior in the future?

回答1:

You are correct in that a Service will call onCreate and onStartCommand if it is started via Context.startService. So in this sense, when you return START_STICKY, the Service will continually run until an explicit call to stopService() is called. It will also be destroyed and restarted during this lifecycle.

Another way to create a Service, is by binding to it. As per the docs:

Clients can also use Context.bindService() to obtain a persistent connection to a service. This likewise creates the service if it is not already running (calling onCreate() while doing so), but does not call onStartCommand().

So, it's possible for a Service to be created by simply binding to it. However, the lifecycle of a Service indicates that it will remain if it is started or a client is still bound to it. Meaning, that if it was created by a bind command, it will immediately be destroyed as soon as the client unbinds.

So, if a Service starts itself in the onCreate(), it will ensure that it puts itself in the started state regardless of whether it was created by binding or by an explicit call to startService. Since there's no actionable intent, the onStartCommand will just pass straight through. An clients that call startSevice will, presumably, have actionable Intents in which case the Service will perform its duties.

来源：https://stackoverflow.com/questions/42678297/what-can-i-expect-when-oncreate-calls-startservice

标签

android

service

android-lifecycle

oncreate