Android10.0 Service启动源码解析

本文出自门心叼龙的博客，属于原创类容，转载请注明出处。

Service的启动流程的还是比较简单的，不像Activity那么复杂，相关联的类和方法都少了很多，不像Activity启动流程里面走着走着就会迷失方向，源码分析这是加强Android内功修炼的必修课，分析了几个流程之后，你就会觉得也不过如此，因为他们的套路都是一样的，大体的实现思想都是相通的，只是具体的代码实现不同罢了。

在上一篇文章我们主要分析了Android10.0 Activity的启动过程，今天我们主要来探索Service的启动过程，本来打算先从5.0开始，然后在分析最新版10.0的启动过程，结果让我失望了，10.0的启动过程和5.0的是方法调用链是一样的，只是有些方法的代码逻辑有些小的改动，它不像Activity的启动流程变化那么大，这说明当时Service启动这块的代码逻辑写的还是非常不错的，Android已经迭代到10了经历了那么版本，这块的代码还是那么的完美稳定，没有什么需要大的改造的地方，10.0中有些小变化会在下面的详解过程会提到，既然5.0和10.0差别不大，索性就以5.0作为研究版本写了这篇文章。

Service是Android四大组件中排行老二，地位仅次于Activity，Activity位于前台向用户展示界面；Service位于后台不可见，但是它承担了大部分的的数据处理工作，主要为其他组件提供后台服务，监控其他组件的运行状态。

Activity中的流程

Service的启动是从Activity的startService方法开始的，这个方法是从他的父类ContextWrapper继承而来的，下面这是Activity的继承关系图：

从上图我们很清晰的看到，Activity继承了ContextThemeWraper，而ContextThemeWraper又继承了ContextWrawper,startService方法正是ContextWraper所提供的，如下所示：

ContextWrapter不但提供了开启服务的startService的方法，而且还提供了停止服务的stopService方法、绑定服务的bindService方法、Activity启动的startActivity方法、广播注册的registerReceiver方法、广播发送的sendBroadcast方法等，Context从英文翻译过来是环境，上下文的意思，它在整个Android操作系统中有着举足轻重的作用，在我们平时的应用开发过程中无处不在的Context，几乎随处可见，因为他是维持各大组件正常工作的核心功能类，它提供了一些系统级别的最基本的操作。

从上面代码的515行，我们看到ContextWraper的startService方法内部调用了mBase的startService方法，mBase的类型是ContextImpl, Activity在创建的时候通过attach方法给mBase变量赋值的，具体代码如下：

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
       ...

        Activity activity = null;
        try {
            java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
            //注释1
            activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);
            StrictMode.incrementExpectedActivityCount(activity.getClass());
            r.intent.setExtrasClassLoader(cl);
            r.intent.prepareToEnterProcess();
            if (r.state != null) {
                r.state.setClassLoader(cl);
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(activity, e)) {
                throw new RuntimeException(
                    "Unable to instantiate activity " + component
                    + ": " + e.toString(), e);
            }
        }

        try {
            Application app = r.packageInfo.makeApplication(false, mInstrumentation);

            if (localLOGV) Slog.v(TAG, "Performing launch of " + r);
            if (localLOGV) Slog.v(
                    TAG, r + ": app=" + app
                    + ", appName=" + app.getPackageName()
                    + ", pkg=" + r.packageInfo.getPackageName()
                    + ", comp=" + r.intent.getComponent().toShortString()
                    + ", dir=" + r.packageInfo.getAppDir());

            if (activity != null) {
             	//注释2
                Context appContext = createBaseContextForActivity(r, activity);
                CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
                Configuration config = new Configuration(mCompatConfiguration);
                if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity "
                        + r.activityInfo.name + " with config " + config);
                //注释3
                activity.attach(appContext, this, getInstrumentation(), r.token,
                        r.ident, app, r.intent, r.activityInfo, title, r.parent,
                        r.embeddedID, r.lastNonConfigurationInstances, config,
                        r.voiceInteractor);

                if (customIntent != null) {
                    activity.mIntent = customIntent;c
                }
              ...
			

ActivityThread的performLaunchActivity方法是不是很熟悉，这是前面文章Activity启动流程中所讲到最重要的一个方法，Activity的创建，Application的创建都是有它来完成的，注释1处通过反射创建了一个activity，注释2处是上下文appContext的创建，注释3 activity调用了attach方法给mBase变量赋值。

注释2处appContext对象是由createBaseContextForActivity创建的，具体代码实现如下：

private Context createBaseContextForActivity(ActivityClientRecord r,
            final Activity activity) {
        //注释1    
        ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);
        appContext.setOuterContext(activity);
        Context baseContext = appContext;

        final DisplayManagerGlobal dm = DisplayManagerGlobal.getInstance();
        try {
            IActivityContainer container =
                    ActivityManagerNative.getDefault().getEnclosingActivityContainer(r.token);
            final int displayId =
                    container == null ? Display.DEFAULT_DISPLAY : container.getDisplayId();
            if (displayId > Display.DEFAULT_DISPLAY) {
                Display display = dm.getRealDisplay(displayId, r.token);
                baseContext = appContext.createDisplayContext(display);
            }
        } catch (RemoteException e) {
        }
        ...
        return baseContext;

在以上代码的注释1处很清楚的看到 appContext 的类型就是ContextImpl，并且是由它的静态方法 createActivityContext创建的，创建完毕通过activity的attach方法给mBase赋值了。通过这些探索就是为了证实mBase的实现就是ContextImpl，现在我回到之前的启动流程mBase.startServcie(service)这一行，其实就是调用了ContextImpl的startService方法，我们继续看该方法的具体实现：

@Override
    public ComponentName startService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, mUser);
    }
    private ComponentName startServiceCommon(Intent service, UserHandle user) {
        try {
            validateServiceIntent(service);
            service.prepareToLeaveProcess();
            //注释1
            ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()), user.getIdentifier());
            if (cn != null) {
                if (cn.getPackageName().equals("!")) {
                    throw new SecurityException(
                            "Not allowed to start service " + service
                            + " without permission " + cn.getClassName());
                } else if (cn.getPackageName().equals("!!")) {
                    throw new SecurityException(
                            "Unable to start service " + service
                            + ": " + cn.getClassName());
                }
            }
            return cn;
        } catch (RemoteException e) {
            return null;
        }
    }

ContextImpl中startService方法会调用startServiceCommon方法，而startServiceCommon方法又会在注释1处调用ActivityManagerNative.getDefault()对象来启动一个服务，注意了这块的逻辑在Android10.0中是这式样的：

  ComponentName cn = ActivityManager.getService().startService(
                mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
                            getContentResolver()), requireForeground,
                            getOpPackageName(), user.getIdentifier());

很显然获取服务这块有所变化，在5.0中是由ActivityManagerNative来完成的，在10.0中这个工作交给ActivityManager了，5.0和10.0最主要的变化就在这里，但是他们最终的逻辑都是一样的，最后都走ActivityManagerService的startService方法，此外，其他的逻辑基本没有什么大的改变，我们还是以5.0为研究版本，继续往下走。

在前面的分析Activity启动的时候我们知道ActivityManagerNative.getDefault()对象其实就是ActivityManagerService，此时Service的启动流程直接就走到了ActivityManagerService中，想必很多人还是不很清楚方法的调用流程怎么就过渡到了ActivityManagerService，其实这里用到了Android跨进程通信技术Binder，下面我们看看他的工作原理，搞清楚是怎么由ActivityManagerNative.getDefault()对象的startService方法过渡到ActivityManagerService的startService方法，ActivityManagerNative的getDefault方法的代码实现如下：

static public IActivityManager getDefault() {
	   return gDefault.get();
}
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
		//注释1
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            //注释2
            IActivityManager am = asInterface(b);
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }
    };   
static public IActivityManager asInterface(IBinder obj) {
        if (obj == null) {
            return null;
        }
        IActivityManager in =
            (IActivityManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
        	//注释3
            return in;
        }
		//注释4
        return new ActivityManagerProxy(obj);
    }     

ActivityManagerNative中的getDefault方法很简单只有一行gDefault.get，而gDefault就是Singleton，他是一个单例对象，当调用它的get方法的时候就会执行注释1处onCreate方法，首先通过ServiceManager的getService方法获取了一个Binder，然后在注释2处把这个binder交给了asInterface方法、该方法的主要作用是将服务端binder对象转换为客户端所需要的IActivityManager 接口对象，如果在客户端和服务端在同一进程就会返回本地接口IActivityManager的实现对象，否则就会返回一个ActivityManagerProxy类型的代理对象，很显然该方法最后直接返回的就是一个代理对象ActivityManagerProxy，因为此时需要进行跨进程调用。因此ActivityManagerNative.getDefault()最终获取的是一个代理对象ActivityManagerProxy，紧着会调用这个对象ActivityManagerProxy的startService方法，方法实现如下：

 public ComponentName startService(IApplicationThread caller, Intent service,
            String resolvedType, int userId) throws RemoteException
    {
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IActivityManager.descriptor);
        data.writeStrongBinder(caller != null ? caller.asBinder() : null);
        service.writeToParcel(data, 0);
        data.writeString(resolvedType);
        data.writeInt(userId);
        //注释1
        mRemote.transact(START_SERVICE_TRANSACTION, data, reply, 0);
        reply.readException();
        ComponentName res = ComponentName.readFromParcel(reply);
        data.recycle();
        reply.recycle();
        return res;
    }

startService方法会把传递过来的参数进行用Parcel 进行封装，然后在注释1处会调用mRemote的transact方法进行远程方法调用，mRemote对象就是我们前面代码注释4处实例化ActivityManagerProxy对象的时候通过构造方法传递给它的服务端Binder对象。此时客户端会处于挂起状态，ActivityManagerNative的实现类ActivityManagerService的onTransact方法响应，该方法的具体实现如下：

    @Override
    public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
            throws RemoteException {
        switch (code) {
  		 case START_SERVICE_TRANSACTION: {
            data.enforceInterface(IActivityManager.descriptor);
            IBinder b = data.readStrongBinder();
            IApplicationThread app = ApplicationThreadNative.asInterface(b);
            Intent service = Intent.CREATOR.createFromParcel(data);
            String resolvedType = data.readString();
            int userId = data.readInt();
            //注释1
            ComponentName cn = startService(app, service, resolvedType, userId);
            reply.writeNoException();
            ComponentName.writeToParcel(cn, reply);
            return true;
        }

onTransact方法响应后会从参数data中解析startService方法所需要的参数，然后在注释1处会调用它的startService方法进行启动服务的操作，至此启动服务的操作由客户端进程切换到了服务端进程，实现了方法的跨进行调用，接下来的我们看ActivityManagerService的startService的方法实现，方法实现如下：

ActivityManagerService的流程

 @Override
    public ComponentName startService(IApplicationThread caller, Intent service,
            String resolvedType, int userId) {
        enforceNotIsolatedCaller("startService");
        // Refuse possible leaked file descriptors
        if (service != null && service.hasFileDescriptors() == true) {
            throw new IllegalArgumentException("File descriptors passed in Intent");
        }

        if (DEBUG_SERVICE)
            Slog.v(TAG, "startService: " + service + " type=" + resolvedType);
        synchronized(this) {
            final int callingPid = Binder.getCallingPid();
            final int callingUid = Binder.getCallingUid();
            final long origId = Binder.clearCallingIdentity();
            //注释1
            ComponentName res = mServices.startServiceLocked(caller, service,
                    resolvedType, callingPid, callingUid, userId);
            Binder.restoreCallingIdentity(origId);
            return res;
        }
    }

该方法也不长，在最后ActivityManagerService会通过mServices来完成后续的启动操作，mServices的类型是ActiveServices，他是辅助ActivityManagerService进行Service管理的辅助类，包括Service的启动，绑定，停止等。在startService方法的尾部会调用ActiveServices的startServiceLocked方法，该方法的实现如下：

ActiveServices的流程

ComponentName startServiceLocked(IApplicationThread caller,
            Intent service, String resolvedType,
            int callingPid, int callingUid, int userId) {
		....
        ServiceRecord r = res.record;

        if (!mAm.getUserManagerLocked().exists(r.userId)) {
            Slog.d(TAG, "Trying to start service with non-existent user! " + r.userId);
            return null;
        }

        NeededUriGrants neededGrants = mAm.checkGrantUriPermissionFromIntentLocked(
                callingUid, r.packageName, service, service.getFlags(), null, r.userId);
        if (unscheduleServiceRestartLocked(r, callingUid, false)) {
            if (DEBUG_SERVICE) Slog.v(TAG, "START SERVICE WHILE RESTART PENDING: " + r);
        }
        r.lastActivity = SystemClock.uptimeMillis();
        r.startRequested = true;
        r.delayedStop = false;
        r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                service, neededGrants));

        final ServiceMap smap = getServiceMap(r.userId);
        boolean addToStarting = false;
		...
        return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    }

在 ActiveServices的startServiceLocked方法的最后会把后续的启动工作交给startServiceInnerLocked方法来处理，它的代码实现如下所示：

ComponentName startServiceInnerLocked(ServiceMap smap, Intent service,
            ServiceRecord r, boolean callerFg, boolean addToStarting) {
        ProcessStats.ServiceState stracker = r.getTracker();
        if (stracker != null) {
            stracker.setStarted(true, mAm.mProcessStats.getMemFactorLocked(), r.lastActivity);
        }
        r.callStart = false;
        synchronized (r.stats.getBatteryStats()) {
            r.stats.startRunningLocked();
        }
        //注释1
        String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false);
        if (error != null) {
            return new ComponentName("!!", error);
        }

        if (r.startRequested && addToStarting) {
            boolean first = smap.mStartingBackground.size() == 0;
            smap.mStartingBackground.add(r);
            r.startingBgTimeout = SystemClock.uptimeMillis() + BG_START_TIMEOUT;
            if (DEBUG_DELAYED_SERVICE) {
                RuntimeException here = new RuntimeException("here");
                here.fillInStackTrace();
                Slog.v(TAG, "Starting background (first=" + first + "): " + r, here);
            } else if (DEBUG_DELAYED_STARTS) {
                Slog.v(TAG, "Starting background (first=" + first + "): " + r);
            }
            if (first) {
                smap.rescheduleDelayedStarts();
            }
        } else if (callerFg) {
            smap.ensureNotStartingBackground(r);
        }

        return r.name;
    }   

在上述代码的注释1处会继续调用bringUpServiceLocked方法，它的源码如下：

private final String bringUpServiceLocked(ServiceRecord r,
            int intentFlags, boolean execInFg, boolean whileRestarting) {
   
        final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
        final String procName = r.processName;
        ProcessRecord app;

        if (!isolated) {
            app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
            if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
                        + " app=" + app);
            if (app != null && app.thread != null) {
                try {
                    app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                    //注释1
                    realStartServiceLocked(r, app, execInFg);
                    return null;
                } catch (RemoteException e) {
                    Slog.w(TAG, "Exception when starting service " + r.shortName, e);
                }

                // If a dead object exception was thrown -- fall through to
                // restart the application.
            }
        } else {
            // If this service runs in an isolated process, then each time
            // we call startProcessLocked() we will get a new isolated
            // process, starting another process if we are currently waiting
            // for a previous process to come up.  To deal with this, we store
            // in the service any current isolated process it is running in or
            // waiting to have come up.
            app = r.isolatedProc;
        }
	...
        return null;
    }

在bringUpServiceLocked方法的注释1处会调用realStartServiceLocked方法，从名字上看来该方法应该会最终完成服务的启动工作，它的具体实现如下：

 private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
    	...
        boolean created = false;
        try {
            String nameTerm;
            int lastPeriod = r.shortName.lastIndexOf('.');
            nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;
            if (LOG_SERVICE_START_STOP) {
                EventLogTags.writeAmCreateService(
                        r.userId, System.identityHashCode(r), nameTerm, r.app.uid, r.app.pid);
            }
            synchronized (r.stats.getBatteryStats()) {
                r.stats.startLaunchedLocked();
            }
            mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
            app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
            //注释1
            app.thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
            r.postNotification();
            created = true;
        } catch (DeadObjectException e) {
            Slog.w(TAG, "Application dead when creating service " + r);
            mAm.appDiedLocked(app);
        } finally {
            if (!created) {
                app.services.remove(r);
                r.app = null;
                scheduleServiceRestartLocked(r, false);
                return;
            }
        }
        requestServiceBindingsLocked(r, execInFg);

        updateServiceClientActivitiesLocked(app, null, true);

        // If the service is in the started state, and there are no
        // pending arguments, then fake up one so its onStartCommand() will
        // be called.
        if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
            r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                    null, null));
        }
		//注释2
        sendServiceArgsLocked(r, execInFg, true);
    	...
    }

在realStartServiceLocked方法中首先会调用注释1处app.thread对象的scheduleCreateService方法来完成Servic的创建和onCreate方法的调用，然后在注释2处会调用sendServiceArgsLocked方法完成后续的处理工作，如onStartCommand方法的执行，在分析Activity启动流程的时候我们知道app.thread对象就是ApplicationThread，他是ActivityThread的一个内部类，其本质也是一个Bidner，因此scheduleCreateService方法调用后，启动Service的流程就由服务端进程切换到了客户端进程，接下来我们看ApplicationThread的scheduleCreateService方法实现：

ActivityThread的流程

 public final void scheduleCreateService(IBinder token,
                ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
            updateProcessState(processState, false);
            CreateServiceData s = new CreateServiceData();
            s.token = token;
            s.info = info;
            s.compatInfo = compatInfo;
            sendMessage(H.CREATE_SERVICE, s);
        }

ApplicationThread的scheduleCreateService方法的内部实现很简单，就发送了一个CREATE_SERVICE类型的消息，这个消息会被ActivityThread的mH消息处理器所接收，之后会调用ActivityThread的方法handleCreateService进行处理，该方法的实现如下：

 private void handleCreateService(CreateServiceData data) {
        // If we are getting ready to gc after going to the background, well
        // we are back active so skip it.
        unscheduleGcIdler();

        LoadedApk packageInfo = getPackageInfoNoCheck(
                data.info.applicationInfo, data.compatInfo);
        Service service = null;
        try {
            java.lang.ClassLoader cl = packageInfo.getClassLoader();
            //注释1
            service = (Service) cl.loadClass(data.info.name).newInstance();
        } catch (Exception e) {
            if (!mInstrumentation.onException(service, e)) {
                throw new RuntimeException(
                    "Unable to instantiate service " + data.info.name
                    + ": " + e.toString(), e);
            }
        }

        try {
            if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
			//注释2
            ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
            context.setOuterContext(service);
			//注释3
            Application app = packageInfo.makeApplication(false, mInstrumentation);
            //注释4
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManagerNative.getDefault());
            //注释5
            service.onCreate();
            mServices.put(data.token, service);
            try {
                ActivityManagerNative.getDefault().serviceDoneExecuting(
                        data.token, 0, 0, 0);
            } catch (RemoteException e) {
                // nothing to do.
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(service, e)) {
                throw new RuntimeException(
                    "Unable to create service " + data.info.name
                    + ": " + e.toString(), e);
            }
        }
    }

在handleCreateService方法中代码还是很精炼的，主要完成了以下几个工作：

• 1.在注释1处通过反射完成了Service的创建
• 2.在注释2处创建了上下文对象Context
• 3.在注释3处创建了Application对象，当然该对象只有一个，如果没有的话会创建，否则就直接返回一个已创建的Application
• 4.在注释4处完成了Service的挂载操作，初始化了一些变量，如context等
• 5.在注释5处完成了Service的onCreate方法的回调
  Service的onCreate方法的执行也就意味着Service已经被启动了，启动完成之后还要调用ActiveServcie的sendServiceArgsLocked方法来完成Service的onStartCommand方法的回调,该方法的代码实现如下：

private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
            boolean oomAdjusted) {
        final int N = r.pendingStarts.size();
        if (N == 0) {
            return;
        }

        while (r.pendingStarts.size() > 0) {
            try {
                ServiceRecord.StartItem si = r.pendingStarts.remove(0);
                if (DEBUG_SERVICE) Slog.v(TAG, "Sending arguments to: "
                        + r + " " + r.intent + " args=" + si.intent);
                if (si.intent == null && N > 1) {
                    // If somehow we got a dummy null intent in the middle,
                    // then skip it.  DO NOT skip a null intent when it is
                    // the only one in the list -- this is to support the
                    // onStartCommand(null) case.
                    continue;
                }
                si.deliveredTime = SystemClock.uptimeMillis();
                r.deliveredStarts.add(si);
                si.deliveryCount++;
                if (si.neededGrants != null) {
                    mAm.grantUriPermissionUncheckedFromIntentLocked(si.neededGrants,
                            si.getUriPermissionsLocked());
                }
                bumpServiceExecutingLocked(r, execInFg, "start");
                if (!oomAdjusted) {
                    oomAdjusted = true;
                    mAm.updateOomAdjLocked(r.app);
                }
                int flags = 0;
                if (si.deliveryCount > 1) {
                    flags |= Service.START_FLAG_RETRY;
                }
                if (si.doneExecutingCount > 0) {
                    flags |= Service.START_FLAG_REDELIVERY;
                }
                //注释1
                r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
            } catch (RemoteException e) {
                // Remote process gone...  we'll let the normal cleanup take
                // care of this.
                if (DEBUG_SERVICE) Slog.v(TAG, "Crashed while scheduling start: " + r);
                break;
            } catch (Exception e) {
                Slog.w(TAG, "Unexpected exception", e);
                break;
            }
        }
    }

在注释1处会调用r.app.thread对象的scheduleServiceArgs方法，从此调用流程再次切换到ActivityThrad的内部类对象ApplicationThread的scheduleServiceArgs方法,下面我们看该方法的具体实现：

 public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
            int flags ,Intent args) {
            ServiceArgsData s = new ServiceArgsData();
            s.token = token;
            s.taskRemoved = taskRemoved;
            s.startId = startId;
            s.flags = flags;
            s.args = args;

            sendMessage(H.SERVICE_ARGS, s);
        }

其实不用贴代码我们也能猜到必然是发了一个消息，这和Service的onCreate方法的执行是一个套路，ActivityThread的消息处理器收到消息后会调用handleServiceArgs来完成onStartCommand的回调

private void handleServiceArgs(ServiceArgsData data) {
       Service s = mServices.get(data.token);
       if (s != null) {
           try {
               if (data.args != null) {
                   data.args.setExtrasClassLoader(s.getClassLoader());
                   data.args.prepareToEnterProcess();
               }
               int res;
               if (!data.taskRemoved) {
               	//注释1
                   res = s.onStartCommand(data.args, data.flags, data.startId);
               } else {
                   s.onTaskRemoved(data.args);
                   res = Service.START_TASK_REMOVED_COMPLETE;
               }

               QueuedWork.waitToFinish();

               try {
                   ActivityManagerNative.getDefault().serviceDoneExecuting(
                           data.token, 1, data.startId, res);
               } catch (RemoteException e) {
                   // nothing to do.
               }
               ensureJitEnabled();
           } catch (Exception e) {
               if (!mInstrumentation.onException(s, e)) {
                   throw new RuntimeException(
                           "Unable to start service " + s
                           + " with " + data.args + ": " + e.toString(), e);
               }
           }
       }
   }

在handleServiceArgs方法的注释1处我们清楚的看到了 s.onStartCommand，这时候Service的onStartCommand方法也被回调了，至此Service的启动流程就全部走完了。

总结

Service的启动流程的还是比较简单的，不像Activity那么复杂，相关联的类和方法都少了很多，不像Activity启动流程里面走着走着就会迷失方向，源码分析这是加强Android内功修炼的必修课，分析了几个流程之后，你就会觉得也不过如此，因为他们的套路都是一样的，大体的实现思想都相通的，只是具体的代码实现不同罢了。最后方便大家对Service启动的理解，我画了一张方法调用时序图，如下：

Activity.startService
ContextWraper.startService
ContextImpl.startService
ContextImpl.startServiceCommon
ActivityManagerService.startService
ActiveService.startServiceLocked
ActiveService.startServiceInnerLocked
ActiveService.bringUpServiceLocked
ActiveService.realStartServiceLocked
ApplicationThread.scheduleCreateService
ActivityThread.handleCreateService
Service.onCreate
ActiveService.sendServiceArgsLocked
ApplicationThread.scheduleServiceArgs
ActivityThread.handleServiceArgs
Service.onStartCommand

问题反馈

在使用学习中有任何问题，请留言，或加入Android、Java开发技术交流群

• QQ群：810970432
• email：[email protected]