Android Gems — AMS的Service生命周期管理

Service对于Android开发来说再熟悉不过了，不过大部分人对Service的了解也仅限于api，这篇文章，我们通过分析AMS的源码，从一个更高的高度来了解一下Service的整个生命周期。

Service的生命周期接口：

1. startService

2. bindService

3. stopService

4. unbindService

这几个接口在apk进程里调用，通过ActivityManagerNative这个Binder最后调用到ActivityManagerService里，而AMS管理Service的类是ActiveService，这个类接管了所有Service生命周期的函数，包括startServiceLocked、stopServiceLocked、bindServiceLocked、unbindServiceLocked等。

startServiceLocked：

该函数实现Service的启动，首先调用retrieveServiceLocked根据Intent查询ServiceLookupResult（主要字段ServiceRecord），查询是先在ServiceMap里找，没有就重新由PackageManager的resolveService来获得ResolveInfo，创建新的ServiceRecord。针对Service的case，startService分为下面三种case，1，caller app是前台应用或者Service所在的app的进程优先级较高（高于PROCESS_STATE_SERVICE）， 那么无限制的start。2，其他情况的Service作为background service，会加入到mStartingBackground list里，如果starting  list的size没有达到上限，那么直接启动。3，此时starting list已到上限，那么此Service的start会推迟，Service会加到mDelayedStartList里。

    ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
            int callingPid, int callingUid, String callingPackage, int userId)
            throws TransactionTooLargeException {
        ......
        ......
        // 检查caller app是否是前台进程
        final boolean callerFg;
        if (caller != null) {
            final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
            if (callerApp == null) {
                throw new SecurityException(
                        "Unable to find app for caller " + caller
                        + " (pid=" + Binder.getCallingPid()
                        + ") when starting service " + service);
            }
            callerFg = callerApp.setSchedGroup != Process.THREAD_GROUP_BG_NONINTERACTIVE;
        } else {
            callerFg = true;
        }

        // 查找ServiceRecord
        ServiceLookupResult res =
            retrieveServiceLocked(service, resolvedType, callingPackage,
                    callingPid, callingUid, userId, true, callerFg);
       
        ......
        ...... 
        ServiceRecord r = res.record;
        ......
        ......
        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;
        if (!callerFg && r.app == null && mAm.mStartedUsers.get(r.userId) != null) {
            ProcessRecord proc = mAm.getProcessRecordLocked(r.processName, r.appInfo.uid, false);
            if (proc == null || proc.curProcState > ActivityManager.PROCESS_STATE_RECEIVER) {
                // 这个分支表示Service所在的进程不存在，或者进程优先级小于PROCESS_STATE_RECEIVER，说明这个Service是background service
                ......

                // 如果Service在delayed start list，则直接返回
                if (r.delayed) {
                     if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "Continuing to delay: " + r);
                    return r.name;
                }
                // 如果后starting background list超上限，则加到mDelayedStartList，暂时不startService，直接返回
                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;
                }
                if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "Not delaying: " + r);
                addToStarting = true;
            } else if (proc.curProcState >= ActivityManager.PROCESS_STATE_SERVICE) {
                // 这个分支表示Service所在的进程优先级小于PROCESS_STATE_SERVICE，但又比PROCESS_STATE_RECEIVER大，加到starting list里，并startService
                addToStarting = true;
                if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                        "Not delaying, but counting as bg: " + r);
            } else if (DEBUG_DELAYED_STARTS) {
                StringBuilder sb = new StringBuilder(128);
                sb.append("Not potential delay (state=").append(proc.curProcState)
                        .append(' ').append(proc.adjType);
                String reason = proc.makeAdjReason();
                if (reason != null) {
                    sb.append(' ');
                    sb.append(reason);
                }
                sb.append("): ");
                sb.append(r.toString());
                Slog.v(TAG_SERVICE, sb.toString());
            }
        } 
        ......
        ......
        // 分支走到这里等于startService会成功，addToStarting表示是否加到StartingBackground List
        return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    }

Service的start是由函数startServiceInnerLocked完成，而startServiceInnerLocked则是调用bringUpServiceLocked完成Service的start，每次startService都会往ServiceRecord的pendingStarts里填加一项StartItem，即使是被放入Delayed List的Service启动。bringUpServiceLocked做的事就是拉起Service。

一，如果进程r.app和r.app.thread已经初始化（代表着Service之前已经Create过），那么bringUpServiceLocked只需要执行onStartCommand，这是通过调用sendServiceArgsLocked来实现，sendServiceArgsLocked就遍历之前pendingStarts的所有StartItem（每个startService都会对应一个StartItem），逐个调用app.thread.scheduleServiceArgs。app.thread是Service所在进程的IApplicationThread Binder对象，用于AMS的SystemServer进程到Client App端的跨进程调用，IApplicationThread的实现是在ActivityThread的内部类ApplicationThread，AMS ->  ActivityThread的调用通过IApplicationThread，ActivityThread -> AMS的调用就是ActivityManagerNative，这样就打通了一条从AMS到ActivityThread的跨进程调用之路。scheduleServiceArgs在ActivityThread里的对应就是ActivityThread.handleServiceArgs，这就执行到了我们所熟悉的onStartCommand。至此可以解释两个我们对于Service的认知：1，每次startService，都会对应一次onStartCommand，就算Service已经onCreate成功。2，Service的回调函数都是在主线程，这个和ApplicationThread这个Binder Client的执行线程一致。sendServiceArgsLocked之后，pendingStarts里的StartItem就被加入到了deliveredStarts里，等待后续stopService或者Service restart的时候用。

二，如果Service所在的进程已经创建（ProcessRecord不空），那么会调用realStartServiceLocked来启动Service，这时的Service是还没有调用过onCreate。realStartServiceLocked会调用app.thread.scheduleCreateService来完成Service的启动，scheduleCreateService同scheduleServiceArgs一样，会调用到ActivityThread里，最终会执行Service的onCreate。之后同样执行sendServiceArgsLocked回调到onStartCommand。

三，如果Service所在的进程还未创建，那么bringUpServiceLocked做的事就是调用AMS的startProcessLocked创建进程，并将Service放进mPendingServices，等待进程创建成功，调用attachApplicationLocked的时候，会遍历所有的mPendingServices，继续调用realStartServiceLocked来完成Service的启动。

最后再看看bringUpServiceLocked的代码来加深一下印象

    private final String bringUpServiceLocked(Servi