Android Service重启恢复（Service进程重启）原理解析

Android系统中，APP进程被杀后，等一会经常发现进程又起来了，这个现象同APP中Service的使用有很大关系，本文指的Service是通过startService启动的，而不是通binderSertvice启动的，binderSertvice是通Activity显示界面相关的，如果两者统一进程，binderSertvice的影响可以忽略，如果不是同一进程，Service会被重启，毕竟业务都没了，Service也没必要启动了，但是对于通过startService启动的服务，很可能需要继续处理自己需要处理的问题，因此，可能需要重启。

相信不少人之前多少都了解过，如果想要Service在进程结束后重新唤醒，那么可能需要用到将Service的onStartCommand返回值设置成START_REDELIVER_INTENT或者START_STICKY等，这样被杀后Service就可以被唤醒，那么为什么？

@Override
public int onStartCommand(Intent intent, int flags, int startId) {

    return START_REDELIVER_INTENT（或者START_STICKY  、START_STICKY_COMPATIBILITY）;
}
复制代码

先看下Google文档对于Service的onStartCommand常用的几个返回值的解释（不完全正确）：

• START_REDELIVER_INTENT

Constant to return from onStartCommand(Intent, int, int): if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), then it will be scheduled for a restart and the last delivered Intent re-delivered to it again via onStartCommand(Intent, int, int).

• START_STICKY

Constant to return from onStartCommand(Intent, int, int): if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), then leave it in the started state but don't retain this delivered intent.

• START_NOT_STICKY

Constant to return from onStartCommand(Intent, int, int): if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), and there are no new start intents to deliver to it, then take the service out of the started state and don't recreate until a future explicit call to Context.startService(Intent).

简单说就是：进程被杀后，START_NOT_STICKY 不会重新唤起Service，除非重新调用startService，才会调用onStartCommand，而START_REDELIVER_INTENT跟START_STICKY都会重启Service，并且START_REDELIVER_INTENT会将最后的一个Intent传递给onStartCommand。不过，看源码，这个解释并不准确，START_REDELIVER_INTENT不仅仅会发送最后一个Intent，它会将之前所有的startService的Intent都重发给onStartCommand，所有在AMS中会保存所有START_REDELIVER_INTENT的Intent信息：

而START_NOT_STICKY跟START_STICKY都不需要AMS存储Intent，如下图：

从测试来看，所有的Intent都会被重发，而不仅仅是最后一个。为什么设置了某些选项就会重启，甚至会重新发送之前Intent呢？本文就来分析下原理，先简单跟踪下启动，因为恢复所需要的所有信息都是在启动的时候构建好的，之后再分析恢复。（基于Android6.0）

Service首次启动简述（Android6.0）

为了简化流程，我们假设Service所在的进程已经启动，代码我们直接从AMS调用ActiveService 的startServiceLocked开始，主要看看启动的时候是如何为恢复做准备的

  ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
            int callingPid, int callingUid, String callingPackage, int userId)
            throws TransactionTooLargeException {
         <!--构建ServiceRecord-->
        ServiceLookupResult res =
            retrieveServiceLocked(service, resolvedType, callingPackage,
                    callingPid, callingUid, userId, true, callerFg);
        ..
        ServiceRecord r = res.record;				 ..
        <!--为调用onStartCommand添加ServiceRecord.StartItem-->
        r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                service, neededGrants));
         ...
      <!--继续启动Service路程-->   
    return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    }
复制代码

启动Service的时候，AMS端先为其构建一个ServiceRecord，算是Service在AMS端的映像，然后添加一个ServiceRecord.StartItem到pendingStarts列表，这个是回调onStartCommand的依据，之后调用startServiceInnerLocked 再调用bringUpServiceLocked进一步启动Service:

   <!--函数1-->
   ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r,
        boolean callerFg, boolean addToStarting) throws TransactionTooLargeException {
    <!--还没有处理onStart-->
    r.callStart = false;
    ...
    String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false);
    ...
     
   <!--函数2-->          
    private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
            boolean whileRestarting) throws TransactionTooLargeException {
         //第一次调用的时候，r.app=null，第二次可以直接调用sendServiceArgsLocked触发onStartCommand的执行
        if (r.app != null && r.app.thread != null) {
            // 启动的时候也会调用
            sendServiceArgsLocked(r, execInFg, false);
            return null;
        }
        ...
        
       if (!isolated) {
        app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
        if (app != null && app.thread != null) {
            try {
                app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
               // 调用realStartServiceLocked真正开始启动Servie
                realStartServiceLocked(r, app, execInFg);
          ...           
复制代码

第一次启动service的时候，为了表示APP端Service还没启动，r.app是没有赋值的，r.app要一直到realStartServiceLocked的执行才被赋值，如果已经启动了，再次调用startService，这里就会走sendServiceArgsLocked，直接回调到APP端onstartCommand：

  private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
       
        r.app = app;
        r.restartTime = r.lastActivity = SystemClock.uptimeMillis();
		 ..
        boolean created = false;
        try {
           <!--通知APP启动Service-->
            app.thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
            r.postNotification();
            created = 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.
    <!--恢复：这里应该主要是给start_sticky用的，恢复的时候触发调用onStartCommand-->
    if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
        r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                null, null));
    }
    <!--处理onstartComand-->
    sendServiceArgsLocked(r, execInFg, true);
    ...
复制代码

realStartServiceLocked会通过Binder通知APP创建Service：app.thread.scheduleCreateService，然后接着通过通知APP回调onStartCommand，由于AMS是通过向APP的UI线程插入消息来处理的，等到sendServiceArgsLocked的请求被执行的时候，Service一定会被创建完成，创建流程没什么可说的，这里主要说的是sendServiceArgsLocked。之前在s