ActivityManagerService之Service启动过程解析

目录

• 缘由
• 启动 Service
• 宿主进程的启动
• 宿主进程创建 Service
• Service 接收参数
• 结束

缘由

我曾经任职于一家小公司，负责上层一切事务，而公司为了给客户(尤其是小客户)提供开发的便利，会强行去掉一些限制，其中就包括启动 Service 的限制。

本文来分析 Service 的整体启动流程，顺带也会提一提 Service 启动的一些限制。但是，读者请务必自行了解 Service 的启动方式，包括前台 Service 的启动，这些基本知识本文不会过多提及。

启动 Service

Service 的启动最终会调用如下方法

// ContextImpl.java
private ComponentName startServiceCommon(Intent service, boolean requireForeground,
        UserHandle user) {
    try {
        // 从 Android 5.0 ，必须使用显式 Intent 启动 Service
        validateServiceIntent(service);
        service.prepareToLeaveProcess(this);
        // 通过 AMS 启动 Service
        ComponentName cn = ActivityManager.getService().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()), requireForeground,
                getOpPackageName(), getAttributionTag(), user.getIdentifier());
        if (cn != null) {
            // ... 处理异常结果 ...
        }
        // 成功启动后，返回已启动的 Service 组件名
        return cn;
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

Service 最终是通过 AMS 进行启动的，一旦启动成功，会返回 Service 的组件名，通过这个返回结果，可以判断 Service 是否启动成功，这一点往往被很多开发者忽略。

AMS 最终会调用 ActiveService#startServiceLocked() 来启动 Service

ActivityManagerService 把 Service 的所有事务都交给 ActiveServices 处理。

// ActiveServices.java
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
        int callingPid, int callingUid, boolean fgRequired,
        String callingPackage, @Nullable String callingFeatureId, final int userId,
        boolean allowBackgroundActivityStarts, @Nullable IBinder backgroundActivityStartsToken)
        throws TransactionTooLargeException {
    // 调用方是否处于前台
    final boolean callerFg;
    if (caller != null) {
        final ProcessRecord callerApp = mAm.getRecordForAppLOSP(caller);
        if (callerApp == null) {
            throw new SecurityException(
                    "Unable to find app for caller " + caller
                    + " (pid=" + callingPid
                    + ") when starting service " + service);
        }
        callerFg = callerApp.mState.getSetSchedGroup() != ProcessList.SCHED_GROUP_BACKGROUND;
    } else {
        callerFg = true;
    }
    // 1. 查询 Service
    // 其实这是是从缓存获取 ServiceRecord，或者建立 ServiceRecord 并缓存
    ServiceLookupResult res =
        retrieveServiceLocked(service, null, resolvedType, callingPackage,
                callingPid, callingUid, userId, true, callerFg, false, false);
    if (res == null) {
        return null;
    }
    if (res.record == null) {
        return new ComponentName("!", res.permission != null
                ? res.permission : "private to package");
    }
    // 从查询的结果中获取 Service 记录
    ServiceRecord r = res.record;
    // 2. 对 Service 启动施加限制
    // ...
    if (forcedStandby || (!r.startRequested && !fgRequired)) {
        // Service 所在的进程处于后台，是无法启动 Service
        final int allowed = mAm.getAppStartModeLOSP(r.appInfo.uid, r.packageName,
                r.appInfo.targetSdkVersion, callingPid, false, false, forcedStandby);
        if (allowed != ActivityManager.APP_START_MODE_NORMAL) {
            Slog.w(TAG, "Background start not allowed: service "
                    + service + " to " + r.shortInstanceName
                    + " from pid=" + callingPid + " uid=" + callingUid
                    + " pkg=" + callingPackage + " startFg?=" + fgRequired);
            // ...
            UidRecord uidRec = mAm.mProcessList.getUidRecordLOSP(r.appInfo.uid);
            return new ComponentName("?", "app is in background uid " + uidRec);
        }
    }
    // ...
    // 3. 进入下一步 Service 启动过程
    return startServiceInnerLocked(r, service, callingUid, callingPid, fgRequired, callerFg,
            allowBackgroundActivityStarts, backgroundActivityStartsToken);
}

首先为 Service 在服务端建立一个记录 ServiceRecord 并缓存起来，这个过程比较简单，读者自行分析。

然后，在 Service 启动之前，施加一些限制，代码中展示了一段后台 app 无法启动 Service 的限制，但是也省略了其他限制的代码，有兴趣的读者可以自行分析。

本文旨在分析 Service 的启动流程，对于一些小细节，限于篇幅原因，就不细致分析，请读者自行研读代码。

最后进入下一步的启动的流程

Service 的启动，会调用好几个类似的函数，但是每一个函数最做了一部分功能，这样就可以把一个庞大的函数分割为几个小的函数，代码阅读性更高，我们要学习这种做法。

private ComponentName startServiceInnerLocked(ServiceRecord r, Intent service,
        int callingUid, int callingPid, boolean fgRequired, boolean callerFg,
        boolean allowBackgroundActivityStarts, @Nullable IBinder backgroundActivityStartsToken)
        throws TransactionTooLargeException {
    // ...
    // 1. 更新 ServiceRecord 数据
    r.lastActivity = SystemClock.uptimeMillis();
    r.startRequested = true;
    r.delayedStop = false;
    r.fgRequired = fgRequired;
    // 保存即将发送给 Service 的参数
    r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
            service, neededGrants, callingUid));
    // 授予 app 启动前台 Service 的 app op 权限
    if (fgRequired) {
        // ...
    }
    // 下面一段，确定 addToStarting 的值
    final ServiceMap smap = getServiceMapLocked(r.userId);
    boolean addToStarting = false;
    // 注意这里的判断条件
    // !callerFg 表示调用方不处于前台
    // !fgRequired 表示启动的是 非前台Service
    // r.app == null 表示 Service 还没有启动过
    if (!callerFg && !fgRequired && r.app == null
            && mAm.mUserController.hasStartedUserState(r.userId)) {
        ProcessRecord proc = mAm.getProcessRecordLocked(r.processName, r.appInfo.uid);
        if (proc == null || proc.mState.getCurProcState() > PROCESS_STATE_RECEIVER) {
            // app 没有创建，或者已经创建，但是在后台没有运行任何四大组件
            // ...
            // 延时Service不在这里启动，直接返回
            if (r.delayed) {
                return r.name;
            }
            // 如果目前要启动非前台Service超时过了最大数量的，那么当前这个Service，要设置为延时 Service
            // 而延时 Service 不在这里启动，因此直接返回
            if (smap.mStartingBackground.size() >= mMaxStartingBackground) {
                // Something else is starting, delay!
                Slog.i(TAG_SERVICE, "Delaying start of: " + r);
                smap.mDelayedStartList.add(r);
                r.delayed = true;
                return r.name;
            }
            addToStarting = true;
        } else if (proc.mState.getCurProcState() >= ActivityManager.PROCESS_STATE_SERVICE) {
            // app 处于后台，但是只运行了 service 和 receiver
            addToStarting = true;
        }
    }
    // allowBackgroundActivityStarts 目前为 false
    if (allowBackgroundActivityStarts) {
        r.allowBgActivityStartsOnServiceStart(backgroundActivityStartsToken);
    }
    // 2. 继续下一阶段的启动流程
    ComponentName cmp = startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    return cmp;
}

现在没有 Service 的启动限制了，是时候正式启动了，首先更新 ServiceRecord 数据，这里要注意，使用 ServiceRecord#pendingStarts 保存了要发送给 Service 的参数。

接下来有一段关于延时 Service 以及监听 后台Service 相关的代码，这是为了优化 Service 启动过多的情况，而做出的一个优化。对于系统优化的开发者，你可能要重点关注一下，本文先不管这个优化功能。

然后继续看下一步的启动流程

// ActiveServices.java
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r,
        boolean callerFg, boolean addToStarting) throws TransactionTooLargeException {
    synchronized (mAm.mProcessStats.mLock) {
        final ServiceState stracker = r.getTracker();
        if (stracker != null) {
            stracker.setStarted(true, mAm.mProcessStats.getMemFactorLocked(), r.lastActivity);
        }
    }
    // 是否调用 onStart()
    r.callStart = false;
    final int uid = r.appInfo.uid;
    final String packageName = r.name.getPackageName();
    final String serviceName = r.name.getClassName();
    FrameworkStatsLog.write(FrameworkStatsLog.SERVICE_STATE_CHANGED, uid, packageName,
            serviceName, FrameworkStatsLog.SERVICE_STATE_CHANGED__STATE__START);
    mAm.mBatteryStatsService.noteServiceStartRunning(uid, packageName, serviceName);
    // 1. 拉起 Service
    String error = bringUpServiceLocked(r, service.getFlags(), callerFg,
            false /* whileRestarting */,
            false /* permissionsReviewRequired */,
            false /* packageFrozen */,
            true /* enqueueOomAdj */);
    /* Will be a no-op if nothing pending */
    mAm.updateOomAdjPendingTargetsLocked(OomAdjuster.OOM_ADJ_REASON_START_SERVICE);
    if (error != null) {
        return new ComponentName("!!", error);
    }
    // 优化后台Service启动过多的情况
    if (r.startRequested && addToStarting) {
        boolean first = smap.mStartingBackground.size() == 0;
        smap.mStartingBackground.add(r);
        // 设置一个超时时间
        r.startingBgTimeout = SystemClock.uptimeMillis() + mAm.mConstants.BG_START_TIMEOUT;
        if (first) {
            smap.rescheduleDelayedStartsLocked();
        }
    } else if (callerFg || r.fgRequired) {
        smap.ensureNotStartingBackgroundLocked(r);
    }
    return r.name;
}

很简单，这一步主要是通过 bringUpServiceLocked() 拉起 Service

private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
        boolean whileRestarting, boolean permissionsReviewRequired, boolean packageFrozen,
        boolean enqueueOomAdj)
        throws TransactionTooLargeException {
    // 1. 如果 Service 已经启动过一次，直接发送发送参数给 Service 即可
    // 因为只有 Service 启动过，r.app 才不为 null
    if (r.app != null && r.app.getThread() != null) {
        sendServiceArgsLocked(r, execInFg, false);
        return null;
    }
    // ...
    final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
    final String procName = r.processName;
    HostingRecord hostingRecord = new HostingRecord("service", r.instanceName);
    ProcessRecord app;
    if (!isolated) {
        // 1. Service 进程存在，但是 Service 还没有启动过，那么通知宿主进程启动 Service
        // 由于前面已经判断过 r.app 不为 null 的情况，所以这里处理的就是 Service 没有启动过的情况
        app = mAm.getProcessRecordLocked(procName, r.appInfo.uid);
        if (app != null) { // 进程粗在
            final IApplicationThread thread = app.getThread();
            final int pid = app.getPid();
            final UidRecord uidRecord = app.getUidRecord();
            if (thread != null) { // attach application 已经完成
                try {
                    app.addPackage(r.appInfo.packageName, r.appInfo.longVersionCode,
                            mAm.mProcessStats);
                    realStartServiceLocked(r, app, thread, pid, uidRecord, execInFg,
                            enqueueOomAdj);
                    return null;
                }
                // ...
            }
        }
    } else {
        // ...
    }
    // 3. Service 所在的进程没有运行，那么要 fork 一个进程
    if (app == null && !permissionsReviewRequired && !packageFrozen) {
        // TODO (chriswailes): Change the Zygote policy flags based on if the launch-for-service
        //  was initiated from a notification tap or not.
        if ((app = mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                    hostingRecord, ZYGOTE_POLICY_FLAG_EMPTY, false, isolated)) == null) {
            String msg = "Unable to launch app "
                    + r.appInfo.packageName + "/"
                    + r.appInfo.uid + " for service "
                    + r.intent.getIntent() + ": process is bad";
            Slog.w(TAG, msg);
            bringDownServiceLocked(r, enqueueOomAdj);
            return msg;
        }
        if (isolated) {
            r.isolatedProc = app;
        }
    }
    // 对于前台 Service 的 app, 暂时添加到省电模式白名单中
    if (r.fgRequired) {
        mAm.tempAllowlistUidLocked(r.appInfo.uid,
                SERVICE_START_FOREGROUND_TIMEOUT, REASON_SERVICE_LAUNCH,
                "fg-service-launch",
                TEMPORARY_ALLOW_LIST_TYPE_FOREGROUND_SERVICE_ALLOWED,
                r.mRecentCallingUid);
    }
    // 3.1 mPendingServices 保存正在等待进程起来的 Service
    // 进程起来后，执行 attach application 过程时，会自动启动这个 Service
    if (!mPendingServices.contains(r)) {
        mPendingServices.add(r);
    }
    if (r.delayedStop) {
        // ...
    }
    return null;
}

拉起一个 Service 要分好几种情况

• 如果 Service 已经启动过，那么直接发送参数给 Service 去执行任务即可。这是最简单的一种情况。
• 如果 Service 没有启动过，但是 Service 的宿主进程是存在的，那么通知宿主进程创建 Service，然后发送参数给它。
• 如果 Service 的宿主进程不存在，那么得先 fork 一个进程，然后用 mPendingServices 保存这个等待进程启动的 Service。当进程起来后，在执行 attach application 的过程中，AMS 会自动完成 Service 的启动流程。

第3种情况，明显是包含前面两种情况，因此下面直接分析这个过程。

宿主进程的启动

Service 的宿主进程起来后，在执行 attach application 的过程中，AMS 会自动启动那些等待进程起来的 Service，如下

    private boolean attachApplicationLocked(@NonNull IApplicationThread thread,
            int pid, int callingUid, long startSeq) {
        // ...
        try {
            // ...
            // 进程初始化
            if (app.getIsolatedEntryPoint() != null) {
                // This is an isolated process which should just call an entry point instead of
                // being bound to an application.
                thread.runIsolatedEntryPoint(
                        app.getIsolatedEntryPoint(), app.getIsolatedEntryPointArgs());
            } else if (instr2 != null) {
                thread.bindApplication(processName, appInfo, providerList,
                        instr2.mClass,
                        profilerInfo, instr2.mArguments,
                        instr2.mWatcher,
                        instr2.mUiAutomationConnection, testMode,
                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
                        isRestrictedBackupMode || !normalMode, app.isPersistent(),
                        new Configuration(app.getWindowProcessController().getConfiguration()),
                        app.getCompat(), getCommonServicesLocked(app.isolated),
                        mCoreSettingsObserver.getCoreSettingsLocked(),
                        buildSerial, autofillOptions, contentCaptureOptions,
                        app.getDisabledCompatChanges(), serializedSystemFontMap);
            } else {
                thread.bindApplication(processName, appInfo, providerList, null, profilerInfo,
                        null, null, null, testMode,
                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
                        isRestrictedBackupMode || !normalMode, app.isPersistent(),
                        new Configuration(app.getWindowProcessController().getConfiguration()),
                        app.getCompat(), getCommonServicesLocked(app.isolated),
                        mCoreSettingsObserver.getCoreSettingsLocked(),
                        buildSerial, autofillOptions, contentCaptureOptions,
                        app.getDisabledCompatChanges(), serializedSystemFontMap);
            }
            // ...
        } catch (Exception e) {
            // ...
            return false;
        }
        // ...
        if (!badApp) {
            try {
                // 启动等待进程的 Service
                didSomething |= mServices.attachApplicationLocked(app, processName);
                checkTime(startTime, "attachApplicationLocked: after mServices.attachApplicationLocked");
            }
        }
        // ...
        return true;
    }

最终调用 ActiveServices#attachApplicationLocked() 完成 Service 的启动

// ActiveServices.java
boolean attachApplicationLocked(ProcessRecord proc, String processName)
        throws RemoteException {
    boolean didSomething = false;
    // mPendingServices 保存的就是那些等待进程起来的 Service
    if (mPendingServices.size() > 0) {
        ServiceRecord sr = null;
        try {
            // 遍历 mPendingServices ，启动属于该进程的所有 Service
            for (int i=0; i<mPendingServices.size(); i++) {
                sr = mPendingServices.get(i);
                // 过滤掉不属于这个进程的 Service
                if (proc != sr.isolatedProc && (proc.uid != sr.appInfo.uid
                        || !processName.equals(sr.processName))) {
                    continue;
                }
                final IApplicationThread thread = proc.getThread();
                final int pid = proc.getPid();
                final UidRecord uidRecord = proc.getUidRecord();
                mPendingServices.remove(i);
                i--;
                proc.addPackage(sr.appInfo.packageName, sr.appInfo.longVersionCode,
                        mAm.mProcessStats);
                // 启动 Service
                realStartServiceLocked(sr, proc, thread, pid, uidRecord, sr.createdFromFg,
                        true);
                didSomething = true;
                if (!isServiceNeededLocked(sr, false, false)) {
                    bringDownServiceLocked(sr, true);
                }
                mAm.updateOomAdjPendingTargetsLocked(OomAdjuster.OOM_ADJ_REASON_START_SERVICE);
            }
        } catch (RemoteException e) {
            // ...
        }
    }
    // 处理进程重启而需要重启的 Service
    if (mRestartingServices.size() > 0) {
        // ...
    }
    return didSomething;
}

终于，我们看到了我们想看到的东西，先从 mPendingServices 中过滤掉不属于进程的 Service，然后启动它

// ActiveServices.java
private void realStartServiceLocked(ServiceRecord r, ProcessRecord app,
        IApplicationThread thread, int pid, UidRecord uidRecord, boolean execInFg,
        boolean enqueueOomAdj) throws RemoteException {
    // ...
    // 注意，r.app 的值才不为 null，也就是 ServiceRecord#app 不为 null
    // 因此可以通过 r.app 判断 Service 是否已经启动过
    r.setProcess(app, thread, pid, uidRecord);
    r.restartTime = r.lastActivity = SystemClock.uptimeMillis();
    final ProcessServiceRecord psr = app.mServices;
    final boolean newService = psr.startService(r);
    // 注意，这里实现了 Service 超时的功能
    bumpServiceExecutingLocked(r, execInFg, "create", null /* oomAdjReason */);
    mAm.updateLruProcessLocked(app, false, null);
    updateServiceForegroundLocked(psr, /* oomAdj= */ false);
    // Force an immediate oomAdjUpdate, so the client app could be in the correct process state
    // before doing any service related transactions
    mAm.enqueueOomAdjTargetLocked(app);
    mAm.updateOomAdjLocked(app, OomAdjuster.OOM_ADJ_REASON_START_SERVICE);
    boolean created = false;
    try {
        // ...
        // 1. 通知宿主进程创建Service
        thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo),
                app.mState.getReportedProcState());
        r.postNotification();
        created = true;
        // ...
    } catch (DeadObjectException e) {
        // ...
    } finally {
        if (!created) {
            // ...
        }
    }
    // ...
    // 2. 发送参数给 Service
    sendServiceArgsLocked(r, execInFg, true);
    if (r.delayed) {
        // ...
    }
    if (r.delayedStop) {
        // ...
    }
}

现在，正式与宿主进程交互来启动 Service

• 首先通过 IApplicationThread#scheduleCreateService() 来通知宿主进程创建 Service。
• 然后通过 IApplicationThread#scheduleServiceArgs() 把参数发送给宿主进程，宿主进程会把参数发送给 Service 执行任务。

宿主进程创建 Service

宿主进程接收到创建 Service 的指令后，会通过 Handler 发送一个消息，最终调用如下方法

// ActivityThread.java
private void handleCreateService(CreateServiceData data) {
    unscheduleGcIdler();
    LoadedApk packageInfo = getPackageInfoNoCheck(
            data.info.applicationInfo, data.compatInfo);
    Service service = null;
    try {
        // 创建 Application，并调用 Application#onCreate()
        Application app = packageInfo.makeApplication(false, mInstrumentation);
        final java.lang.ClassLoader cl;
        if (data.info.splitName != null) {
            cl = packageInfo.getSplitClassLoader(data.info.splitName);
        } else {
            cl = packageInfo.getClassLoader();
        }
        // 创建 Service
        service = packageInfo.getAppFactory()
                .instantiateService(cl, data.info.name, data.intent);
        ContextImpl context = ContextImpl.getImpl(service
                .createServiceBaseContext(this, packageInfo));
        if (data.info.splitName != null) {
            context = (ContextImpl) context.createContextForSplit(data.info.splitName);
        }
        if (data.info.attributionTags != null && data.info.attributionTags.length > 0) {
            final String attributionTag = data.info.attributionTags[0];
            context = (ContextImpl) context.createAttributionContext(attributionTag);
        }
        context.getResources().addLoaders(
                app.getResources().getLoaders().toArray(new ResourcesLoader[0]));
        context.setOuterContext(service);
        service.attach(context, this, data.info.name, data.token, app,
                ActivityManager.getService());
        // 执行 Service#onCreate()
        service.onCreate();
        mServicesData.put(data.token, data);
        mServices.put(data.token, service);
        // 通知服务端Service创建成功
        try {
            ActivityManager.getService().serviceDoneExecuting(
                    data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
        } catch (RemoteException e) {
            throw e.rethrowFromSystemServer();
        }
    } catch (Exception e) {
        // ...
    }
}

宿主继承会先创建 Application，并执行 Application#onCreate()，然后创建 Service，并执行 Service#onCreate()，最后通知服务端 Service 创建成功。这一套流程，简直行云流水。

Service 接收参数

宿主进程接收到服务端发送过来的 Service 启动参数后，最终调用如下方法

// ActivityThread.java
private void handleServiceArgs(ServiceArgsData data) {
    CreateServiceData createData = mServicesData.get(data.token);
    Service s = mServices.get(data.token);
    if (s != null) {
        try {
            if (data.args != null) {
                data.args.setExtrasClassLoader(s.getClassLoader());
                data.args.prepareToEnterProcess(isProtectedComponent(createData.info),
                        s.getAttributionSource());
            }
            int res;
            if (!data.taskRemoved) {
                // 调用 Service#onStartCommand() 接收参数，并执行任务
                // 注意，这里是在主线程
                res = s.onStartCommand(data.args, data.flags, data.startId);
            } else {
                s.onTaskRemoved(data.args);
                res = Service.START_TASK_REMOVED_COMPLETE;
            }
            QueuedWork.waitToFinish();
            try {
                // 把 Service#onStartCommand() 的执行结果反馈给服务端
                // 因为这个结果影响到 Service 重启的方式
                ActivityManager.getService().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
            } catch (RemoteException e) {
                throw e.rethrowFromSystemServer();
            }
        } catch (Exception e) {
            // ...
        }
    }
}

当宿主进程收到 Service 的启动参数后，调用 Service#onStartCommand() 接收参数，并执行任务。

注意，Service#onStartCommand() 是在主线程中执行，其实四大组件的生命周期都是在主线程中执行的，这一点大家要牢记。

然后把 Service#onStartCommand() 的返回结果返回给服务端。这个方法的返回结果很重要，它影响了 Service 重启的方式。这里简单展示下结果的处理流程

// ActiveServices.java
void serviceDoneExecutingLocked(ServiceRecord r, int type, int startId, int res,
        boolean enqueueOomAdj) {
    boolean inDestroying = mDestroyingServices.contains(r);
    if (r != null) {
        if (type == ActivityThread.SERVICE_DONE_EXECUTING_START) {
            // 注意了，ServiceRecord#callStart , 是在 Service 执行完 onStartCommand() 并反馈结果后，才设置为 true
            r.callStart = true;
            switch (res) {
                case Service.START_STICKY_COMPATIBILITY:
                // Service 会重启，但是不会收到原来的启动参数
                case Service.START_STICKY: {
                    // 注意最后一个参数为 true
                    // 它表示从已发送的参数 Service#deliveredStarts 中移除此次执行的参数
                    // 因为Service重启时，不需要这个参数
                    r.findDeliveredStart(startId, false, true);
                    // Don't stop if killed.
                    r.stopIfKilled = false;
                    break;
                }
                case Service.START_NOT_STICKY: {
                    // ...
                    break;
                }
                // Service 会重启，并且也会收到原来的启动参数
                case Service.START_REDELIVER_INTENT: {
                    // 注意最后一个参数 true
                    // 它表示不需要从已发送的参数 Service#deliveredStarts 中移除此次执行的参数
                    // 因此Service重启时，需要这个参数
                    ServiceRecord.StartItem si = r.findDeliveredStart(startId, false, false);
                    if (si != null) {
                        si.deliveryCount = 0;
                        si.doneExecutingCount++;
                        // Don't stop if killed.
                        r.stopIfKilled = true;
                    }
                    break;
                }
                // ...
            }
            if (res == Service.START_STICKY_COMPATIBILITY) {
                r.callStart = false;
            }
        } else if (type == ActivityThread.SERVICE_DONE_EXECUTING_STOP) {
            // ...
        }
        final long origId = Binder.clearCallingIdentity();
        // 主要更新 oom ajd
        serviceDoneExecutingLocked(r, inDestroying, inDestroying, enqueueOomAdj);
        Binder.restoreCallingIdentity(origId);
    }
}

这里就涉及到 Service 的基本功，上面展示了两个返回值的处理过程，这两个返回值都表示，由于内存不足而杀掉的 Service，当内存充足时，会重启 Service，但是一个返回值需要再次发送之前的启动参数，而另外一个返回值不需要。

对于需要发送参数的返回值，不需要从 Service#deliveredStart 列表中删除已经发送的参数，因为 Service 重启时，需要发送它。相反，就需要从列表中删除已经发送的参数，因为 Service 重启不再需要它了。

结束

本文完整了分析了 Service 的启动流程，这个是最基本的，并且需要掌握的。

本文还顺带提了一下 Service 启动的限制，对于一个专业的开发者来说，遵守这些限制即可，但是对于系统开发者来说，你可能想 去掉/修改/增加 一些限制，那么你得自己研究下。

其实本文还遗留了一个很值得探讨的话题，那就是优化大量Service启动，对于系统优化的开发者来说，应该是必须要掌握的，后面如果有兴趣了，也有时间了，我会补一篇文章，更多关于ActivityManagerService Service启动的资料请关注我们其它相关文章！