Android四大组件——Service的工作过程分析

启动Service分为两种方式,分别是start方式和bind方式。

start方式对应的是Service由Context.startService(Intent service)方法来启动,从创建到销毁经历的生命周期方法是onCreate、onStartCommand、onDestory。已经在后台运行的Service,如果外界调用Context.stopService(Intent service)方法或者Service自己调用stopSelf()方法,Service会执行onDestory生命周期方法,然后结束运行。start状态的Service与Activity相互独立,即使Activity销毁,Service还是会存在。每次start方式启动Service,其onStartCommand方法均会被调用。

bind方式对应的是Service由Context.bindService(Intent service, ServiceConnection conn, int flags)方法来启动,从创建到销毁经历的生命周期方法是onCreate、onBind、onUnbind、onDestory。bind状态的Service与Activity相互关联,可以认为Service与Activity的生命周期绑定。多次bind启动同一个Service,其onBind方法只会被调用一次。bind启动的Service,可以调用Context.unbindService(ServiceConnection conn)方法来解除绑定,Activity销毁的时候也会自动与bind状态的Service解除绑定。当Service上的所有绑定都解除后,Service会被销毁。

注意:Service的周期方法中不管是多次start还是多次bind启动,onCreate方法只会调用一次。Service不同状态的启动方法和销毁方法是对应的,假如用start方式启动,调用unbind是没有效果的,只有调用对用的stop方法才可以销毁Service;反之同理。

简单来说,start状态和bind状态的区别有4点:
a. 启动方式不同
b. 生命周期阶段不同
c. 销毁方式不同。
d. 交互不同,以start方式启动的Service,组件与Service是无法交互的。以bind方式启动的Service,组件可以与Service进行交互。

Service可以以start方式和bind方式混合启动,如果一个Service通过start方式和bind方式启动,想要停止这个Service的话,它的stopService和unbindService都要调用,调用顺序没有关系,只调用一个是无法停止Service的。还要注意一点,多次startService只要一次stopService就可以了,但是如果多次bindService就需要多次unBindService,或者与Service绑定的组件结束其生命周期。

下面按照start方式和bind方式来分别介绍Service的启动过程。

start方式启动

不管是start方式还是bind方式,启动一个Service都是通过ContextWrapper的方法来的,例如:

# android.content.ContextWrapper
@Override
public ComponentName startService(Intent service) {
    return mBase.startService(service);
}

其实最终它还是通过mBase来启动,这是典型的桥接模式。Application、Activity、Service在对象创建完毕之后第一件事就是调用他们自身的attach方法,在attach方法中又会调用attachBaseContext方法,进而对mBase进行赋值。这个mBase实际上就是ContextImpl对象,ContextImpl的创建过程在Activity启动过程之生命周期方法回调分析中也有介绍。

我们直接看一下ContextImpl的startService方法,这个方法后面调用了startServiceCommon方法。而startServiceCommon中通过ActivityManagerNative的getDefault对象去startService。相信看过Activity启动过程分析这篇文章的应该很明白,ActivityManagerNative.getDefault()获取的是ActivityManagerService在本地进程的一个代理对象,通过Binder机制,进行一次IPC过程调用到ActivityManagerService的startService方法。

# android.app.ContextImpl
@Override
public ComponentName startService(Intent service) {
    warnIfCallingFromSystemProcess();
    return startServiceCommon(service, mUser);
}

private ComponentName startServiceCommon(Intent service, UserHandle user) {
    try {
        validateServiceIntent(service);
        service.prepareToLeaveProcess(this);
        ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
                        getContentResolver()), getOpPackageName(), 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) {
        throw e.rethrowFromSystemServer();
    }
}

ActivityManagerNative相关内容我们就不多做介绍了,直接看一下ActivityManagerService的startService方法。在该方法中又会调用mServices的startServiceLocked方法,这个mServices是ActiveServices类型,用来是辅助AMS对Service进行启动管理的。

@Override
public ComponentName startService(IApplicationThread caller, Intent service,
                                  String resolvedType, String callingPackage, int userId)
        throws TransactionTooLargeException {
    enforceNotIsolatedCaller("startService");
   ...
    synchronized(this) {
        final int callingPid = Binder.getCallingPid();
        final int callingUid = Binder.getCallingUid();
        final long origId = Binder.clearCallingIdentity();
        ComponentName res = mServices.startServiceLocked(caller, service,
                resolvedType, callingPid, callingUid, callingPackage, userId);
        Binder.restoreCallingIdentity(origId);
        return res;
    }
}

ActiveServices的startServiceLocked中会对所要启动的Service进行检查,包括其它一些安全方面的校验。如果所有的检查都通过,就会调用ActiveServices自身的startServiceInnerLocked方法。

# com.android.server.am.ActiveServices
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
                                 int callingPid, int callingUid, String callingPackage, final int userId)
        throws TransactionTooLargeException {
  ...
    // 对所要启动的Service进行检查
    ServiceLookupResult res =
            retrieveServiceLocked(service, resolvedType, callingPackage,
                    callingPid, callingUid, userId, true, callerFg, false);
    if (res == null) {
        return null;
    }
    if (res.record == null) {
        return new ComponentName("!", res.permission != null
                ? res.permission : "private to package");
    }
    
    ...
    return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
}

在ActiveServices的startServiceInnerLocked中,会继续调用bringUpServiceLocked方法。

# com.android.server.am.ActiveServices
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r,
                                      boolean callerFg, boolean addToStarting) throws TransactionTooLargeException {
  ...
    String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false, false);
    if (error != null) {
        return new ComponentName("!!", error);
    }
  ...
    return r.name;
}

在ActiveServices的startServiceInnerLocked中,如注释1处,首先判断当前的Service是否已经启动过,如果已经启动多的话会通过一个IPC过程调用ApplicationThread的scheduleServiceArgs,然后通过Hander的切换调用到ActivityThread的handleServiceArgs方法,进而调用Service的onStartCommand方法。这里我们先不细说了,继续分析Service的启动过程。

在这个方法中还是根据当前启动的Service是否需要一个独立的进程,如果不需要独立的进程并且当前的进程已经存在的话就会调用realStartServiceLocked。如果进程不存在话还会先创建一个进程,进程的创建是通过ActivityManagerService的startProcessLocked方法来进行的。

# com.android.server.am.ActiveServices
private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
                                    boolean whileRestarting, boolean permissionsReviewRequired)
        throws TransactionTooLargeException {
    //Slog.i(TAG, "Bring up service:");
    //r.dump("  ");

 //  1 判断当前的Service是否已经启动过
    if (r.app != null && r.app.thread != null) {
        sendServiceArgsLocked(r, execInFg, false);
        return null;
    }

    if (!whileRestarting && r.restartDelay > 0) {
        // If waiting for a restart, then do nothing.
        return null;
    }

    if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Bringing up " + r + " " + r.intent);

    // We are now bringing the service up, so no longer in the
    // restarting state.
    if (mRestartingServices.remove(r)) {
        r.resetRestartCounter();
        clearRestartingIfNeededLocked(r);
    }

    // Make sure this service is no longer considered delayed, we are starting it now.
    if (r.delayed) {
        if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (bring up): " + r);
        getServiceMap(r.userId).mDelayedStartList.remove(r);
        r.delayed = false;
    }

    // Make sure that the user who owns this service is started.  If not,
    // we don't want to allow it to run.
    if (!mAm.mUserController.hasStartedUserState(r.userId)) {
        String msg = "Unable to launch app "
                + r.appInfo.packageName + "/"
                + r.appInfo.uid + " for service "
                + r.intent.getIntent() + ": user " + r.userId + " is stopped";
        Slog.w(TAG, msg);
        bringDownServiceLocked(r);
        return msg;
    }

    // Service is now being launched, its package can't be stopped.
    try {
        AppGlobals.getPackageManager().setPackageStoppedState(
                r.packageName, false, r.userId);
    } catch (RemoteException e) {
    } catch (IllegalArgumentException e) {
        Slog.w(TAG, "Failed trying to unstop package "
                + r.packageName + ": " + e);
    }

// 2 判断是否需要独立的进程
    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 {
      // 3 进程存在,
                app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                realStartServiceLocked(r, app, execInFg);
                return null;
            } catch (TransactionTooLargeException e) {
                throw e;
            } 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;
    }

    // Not running -- get it started, and enqueue this service record
    // to be executed when the app comes up.
    // 4 进程不存在,需要创建进程
    if (app == null && !permissionsReviewRequired) {
        if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                "service", r.name, false, isolated, false)) == 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);
            return msg;
        }
        if (isolated) {
            r.isolatedProc = app;
        }
    }

    if (!mPendingServices.contains(r)) {
        mPendingServices.add(r);
    }

    if (r.delayedStop) {
        // Oh and hey we've already been asked to stop!
        r.delayedStop = false;
        if (r.startRequested) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                    "Applying delayed stop (in bring up): " + r);
            stopServiceLocked(r);
        }
    }

    return null;
}

我们假设进程已经存在,现在开始分析ActiveServices的realStartServiceLocked方法,看名字也能猜到,在这里是真的要启动一个Service了。在该方法中有一段代码app.thread.scheduleCreateService,app.thread 表示的就是IApplicationThread在本地的一个代理,这个方法通过一个IPC过程会调用到ApplicationThread的scheduleCreateService方法。

# com.android.server.am.ActiveServices
private final void realStartServiceLocked(ServiceRecord r,
                                          ProcessRecord app, boolean execInFg) throws RemoteException {
    if (app.thread == null) {
        throw new RemoteException();
    }
    if (DEBUG_MU)
        Slog.v(TAG_MU, "realStartServiceLocked, ServiceRecord.uid = " + r.appInfo.uid
                + ", ProcessRecord.uid = " + app.uid);
    r.app = app;
    r.restartTime = r.lastActivity = SystemClock.uptimeMillis();

    final boolean newService = app.services.add(r);
    bumpServiceExecutingLocked(r, execInFg, "create");
    mAm.updateLruProcessLocked(app, false, null);
    mAm.updateOomAdjLocked();

    boolean created = false;
    try {
        if (LOG_SERVICE_START_STOP) {
            String nameTerm;
            int lastPeriod = r.shortName.lastIndexOf('.');
            nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;
            EventLogTags.writeAmCreateService(
                    r.userId, System.identityHashCode(r), nameTerm, r.app.uid, r.app.pid);
        }
        synchronized (r.stats.getBatteryStats()) {
            r.stats.startLaunchedLocked();
        }
        mAm.notifyPackageUse(r.serviceInfo.packageName,
                PackageManager.NOTIFY_PACKAGE_USE_SERVICE);
        app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
        // 1 通过IPC过程创建Service
        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);
        throw e;
    } finally {
        if (!created) {
            // Keep the executeNesting count accurate.
            final boolean inDestroying = mDestroyingServices.contains(r);
            serviceDoneExecutingLocked(r, inDestroying, inDestroying);

            // Cleanup.
            if (newService) {
                app.services.remove(r);
                r.app = null;
            }

            // Retry.
            if (!inDestroying) {
                scheduleServiceRestartLocked(r, false);
            }
        }
    }

    if (r.whitelistManager) {
        app.whitelistManager = true;
    }

    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 在该方法中会通过IPC过程调动Service的onStartCommand方法
    sendServiceArgsLocked(r, execInFg, true);

    if (r.delayed) {
        if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (new proc): " + r);
        getServiceMap(r.userId).mDelayedStartList.remove(r);
        r.delayed = false;
    }

    if (r.delayedStop) {
        // Oh and hey we've already been asked to stop!
        r.delayedStop = false;
        if (r.startRequested) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                    "Applying delayed stop (from start): " + r);
            stopServiceLocked(r);
        }
    }
}

我们来看一下,ApplicationThread的scheduleCreateService方法,其实ApplicationThread的中的方法都像套路一样,均会发送一个消息,然后进入ActivityThread的内部类H的handleMessage方法中。这个传递的参数对象是一个CreateServiceData,就是一个JavaBean对象,封装了IBinder、ServiceInfo、CompatibilityInfo,可以看到这里面传递的也是一个IBinder的token,这个token就是用于识别这个对应的Service。AMS那边实际上存的也是这个token。

# andorid.app.ActivityThread$ApplicationThread
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);
}

在Handler中又会调用ActivityThread的handleCreateService方法。

# andorid.app.ActivityThread$H
public void handleMessage(Message msg) {
    if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
    switch (msg.what) {
    。。。
        case CREATE_SERVICE:
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, ("serviceCreate: " + String.valueOf(msg.obj)));
            handleCreateService((CreateServiceData)msg.obj);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            break;
    }
    ...
}

在ActivityThread的handleCreateService方法中,做的事情清晰明了,其实与Activity的创建过程类似,可以查看Activity启动过程之生命周期方法回调分析

  1. 通过getPackageInfoNoCheck方法获取LoadedApk对象
  2. 通过LoadedApk中的ClassLoader对象创建Service对象,对于一个已经安装的Apk来讲,这个ClassLoader一般指的就是PathClassLoader。
  3. 创建ContextImpl对象
  4. 调用LoadedApk的makeApplication创建Application对象,一个LoadedApk只会对应一个Application,如果已经存在的话直接返回该对象。
  5. 调用attach方法,绑定一些必须的参数,注意这个context就是ContextImpl对象,也就是我们之前讲的在ContextWrapper中获取的mBase对象就是它
  6. 调用Service的onCreate方法
  7. mServices.put(data.token, service),用于缓存一个App进程中已经创建的Service
  8. 通过IPC调用AMS的serviceDoneExecuting方法,这个传递的type是SERVICE_DONE_EXECUTING_ANON类型,实际上在AMS那边是没有做处理的。这里我们暂时不分析它。
# andorid.app.ActivityThread
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();
    // 1 获取LoadedApk对象
    LoadedApk packageInfo = getPackageInfoNoCheck(
            data.info.applicationInfo, data.compatInfo);
    Service service = null;
    // 2 创建Service对象
    try {
        java.lang.ClassLoader cl = packageInfo.getClassLoader();
        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);
        // 3 创建ContextImpl对象,
        ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
        context.setOuterContext(service);
        
        //4 调用LoadedApk的makeApplication创建Application对象,一个LoadedApk只会对应一个Application
        Application app = packageInfo.makeApplication(false, mInstrumentation);
        // 5 调用attach方法,绑定一些必须的参数,注意这个context就是ContextImpl对象,也就是我们之前讲的在ContextWrapper中获取的mBase对象就是它
        service.attach(context, this, data.info.name, data.token, app,
                ActivityManagerNative.getDefault());
        // 6 调用Service的onCreate方法
        service.onCreate();
        // 7 存储起来
        mServices.put(data.token, service);
        // 8 通过IPC调用AMS的serviceDoneExecuting方法
        try {
            ActivityManagerNative.getDefault().serviceDoneExecuting(
                    data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
        } catch (RemoteException e) {
            throw e.rethrowFromSystemServer();
        }
    } catch (Exception e) {
        if (!mInstrumentation.onException(service, e)) {
            throw new RuntimeException(
                    "Unable to create service " + data.info.name
                            + ": " + e.toString(), e);
        }
    }
}

这个方法执行完毕之后,这次IPC过程就结束了。但是AMS那边的方法还没有执行完毕呢?
我们接着分析realStartServiceLocked方法。
在这个方法中实际上还会尝试通过requestServiceBindingsLocked进而来调用bindService的方法,不过因为我们是以start方式启动的,因此ServiceRecord中是没有bind意图的,因此也不会调用bind方法,这里我们就不分析它了,留到在bind方式启动的时候再来看它。
在方法中还会调用sendServiceArgsLocked方法,该方法中会通过IPC过程调动Service的onStartCommand方法,还记得我们之前说过吗,如果Service已经创建的话实际上ActiveServices就是会直接调用sendServiceArgsLocked这个方法。

# com.android.server.am.ActiveServices
private final void realStartServiceLocked(ServiceRecord r,
                                          ProcessRecord app, boolean execInFg) throws RemoteException {
...
        // 1 通过IPC过程创建Service
        app.thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                app.repProcState);
        r.postNotification();
        created = true;
    } catch (DeadObjectException e) {
      ...
    } finally {
        ...
    }

...
    // 2 请求调用bindService
    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));
    }

    // 3 在该方法中会通过IPC过程调动Service的onStartCommand方法
    sendServiceArgsLocked(r, execInFg, true);

    if (r.delayed) {
        if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (new proc): " + r);
        getServiceMap(r.userId).mDelayedStartList.remove(r);
        r.delayed = false;
    }

    if (r.delayedStop) {
        // Oh and hey we've already been asked to stop!
        r.delayedStop = false;
        if (r.startRequested) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                    "Applying delayed stop (from start): " + r);
            stopServiceLocked(r);
        }
    }
}

我们来看一下ActiveServices的sendServiceArgsLocked方法,在该方法中会调用r.app.thread.scheduleServiceArgs方法,这是一个IPC过程,调用ApplicationThread的 scheduleServiceArgs方法。

# com.android.server.am.ActiveServices
private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
                                         boolean oomAdjusted) throws TransactionTooLargeException {
    final int N = r.pendingStarts.size();
    if (N == 0) {
        return;
    }

    while (r.pendingStarts.size() > 0) {
        Exception caughtException = null;
        ServiceRecord.StartItem si = null;
        try {
            si = r.pendingStarts.remove(0);
            if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "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 通过IPC调用ApplicationThread的 scheduleServiceArgs方法
            r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
        } catch (TransactionTooLargeException e) {
         ...
        } catch (RemoteException e) {
          ...
        } catch (Exception e) {
            ...
        }

    ...
    }
}
# andorid.app.ActivityThread$ApplicationThread
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);
}
# andorid.app.ActivityThread$H
public void handleMessage(Message msg) {
...
    switch (msg.what) {
        case SERVICE_ARGS:
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, ("serviceStart: " + String.valueOf(msg.obj)));
            handleServiceArgs((ServiceArgsData)msg.obj);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            break;
...
    }
   ...    
}

我们来看一下ActivityThread的handleServiceArgs方法,该方法比较简单

  1. 就是首先通过token从mServices中获取对应的Service
  2. 给Intent设置extrasClassLoader,主要是为了反序列化Intent中携带的一个Parcelable类型的对象
  3. 调用Service的onStartCommand方法,获取其返回值
  4. 通过IPC告知AMS调用结果,注意这个时候把onStartCommand的返回值传递过去了,结果类型type为SERVICE_DONE_EXECUTING_START。
private void handleServiceArgs(ServiceArgsData data) {
    // 1 获取Service
    Service s = mServices.get(data.token);
    if (s != null) {
        try {
            // 2. 给Intent设置extrasClassLoader,主要是为了反序列化Intent中携带的一个Parcelable类型的对象
            if (data.args != null) {
                data.args.setExtrasClassLoader(s.getClassLoader());
                data.args.prepareToEnterProcess();
            }
            int res;
            // 3 调用Service的onStartCommand方法
            if (!data.taskRemoved) {
                res = s.onStartCommand(data.args, data.flags, data.startId);
            } else {
                s.onTaskRemoved(data.args);
                res = Service.START_TASK_REMOVED_COMPLETE;
            }

            QueuedWork.waitToFinish();
            
            // 4 通过IPC告知AMS调用结果,注意这个时候把onStartCommand的返回值传递过去了
            try {
                ActivityManagerNative.getDefault().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
            } catch (RemoteException e) {
                throw e.rethrowFromSystemServer();
            }
            ensureJitEnabled();
        } catch (Exception e) {
            if (!mInstrumentation.onException(s, e)) {
                throw new RuntimeException(
                        "Unable to start service " + s
                                + " with " + data.args + ": " + e.toString(), e);
            }
        }
    }
}

看一下ActivityManagerService的serviceDoneExecuting方法,其实也就是做了一下中转,中间做了一下校验,要保证客户端传递来的token是正确的类型。之后会调用ActiveServices的serviceDoneExecutingLocked方法。

# com.android.server.am.ActivityManagerService
public void serviceDoneExecuting(IBinder token, int type, int startId, int res) {
    synchronized(this) {
        if (!(token instanceof ServiceRecord)) {
            Slog.e(TAG, "serviceDoneExecuting: Invalid service token=" + token);
            throw new IllegalArgumentException("Invalid service token");
        }
        mServices.serviceDoneExecutingLocked((ServiceRecord)token, type, startId, res);
    }
}

在 serviceDoneExecutingLocked方法中会根据传递过来的type,来进行对应的处理,此时传递的是SERVICE_DONE_EXECUTING_START,然后就会根据对应的res来进行处理。正常情况下这个res就是Service的onStartCommand的返回值。

# com.android.server.am.ActiveServices
void serviceDoneExecutingLocked(ServiceRecord r, int type, int startId, int res) {
    boolean inDestroying = mDestroyingServices.contains(r);
    if (r != null) {
        if (type == ActivityThread.SERVICE_DONE_EXECUTING_START) {
            // This is a call from a service start...  take care of
            // book-keeping.
            r.callStart = true;
            switch (res) {
                case Service.START_STICKY_COMPATIBILITY:
                case Service.START_STICKY: {
                    // We are done with the associated start arguments.
                    r.findDeliveredStart(startId, true);
                    // Don't stop if killed.
                    r.stopIfKilled = false;
                    break;
                }
                case Service.START_NOT_STICKY: {
                    // We are done with the associated start arguments.
                    r.findDeliveredStart(startId, true);
                    if (r.getLastStartId() == startId) {
                        // There is no more work, and this service
                        // doesn't want to hang around if killed.
                        r.stopIfKilled = true;
                    }
                    break;
                }
                case Service.START_REDELIVER_INTENT: {
                    // We'll keep this item until they explicitly
                    // call stop for it, but keep track of the fact
                    // that it was delivered.
                    ServiceRecord.StartItem si = r.findDeliveredStart(startId, false);
                    if (si != null) {
                        si.deliveryCount = 0;
                        si.doneExecutingCount++;
                        // Don't stop if killed.
                        r.stopIfKilled = true;
                    }
                    break;
                }
                case Service.START_TASK_REMOVED_COMPLETE: {
                    // Special processing for onTaskRemoved().  Don't
                    // impact normal onStartCommand() processing.
                    r.findDeliveredStart(startId, true);
                    break;
                }
                default:
                    throw new IllegalArgumentException(
                            "Unknown service start result: " + res);
            }
            if (res == Service.START_STICKY_COMPATIBILITY) {
                r.callStart = false;
            }
        } else if (type == ActivityThread.SERVICE_DONE_EXECUTING_STOP) {
            // This is the final call from destroying the service...  we should
            // actually be getting rid of the service at this point.  Do some
            // validation of its state, and ensure it will be fully removed.
            if (!inDestroying) {
                // Not sure what else to do with this...  if it is not actually in the
                // destroying list, we don't need to make sure to remove it from it.
                // If the app is null, then it was probably removed because the process died,
                // otherwise wtf
                if (r.app != null) {
                    Slog.w(TAG, "Service done with onDestroy, but not inDestroying: "
                            + r + ", app=" + r.app);
                }
            } else if (r.executeNesting != 1) {
                Slog.w(TAG, "Service done with onDestroy, but executeNesting="
                        + r.executeNesting + ": " + r);
                // Fake it to keep from ANR due to orphaned entry.
                r.executeNesting = 1;
            }
        }
        final long origId = Binder.clearCallingIdentity();
        serviceDoneExecutingLocked(r, inDestroying, inDestroying);
        Binder.restoreCallingIdentity(origId);
    } else {
        Slog.w(TAG, "Done executing unknown service from pid "
                + Binder.getCallingPid());
    }
}

onStartCommand方法的返回值是int型,返回值有4种。

  1. START_STICKY_COMPATIBILITY = 0,这个是START_STICKY的兼容版本,被杀死后重启并不保证一定调用onStartCommand方法。这个一般是在android系统小于5 的时候使用。

  2. START_STICKY = 1,当Service已经启动后,如果onStartCommand方法返回值是这个,表示的是如果因内存不足Service被系统杀掉,系统会在后续内存空闲时尝试着重新创建这个Service,但是不会再传递上次启动Service的Intent,onStartCommand中的Intent参数会为null。

  3. START_NOT_STICKY = 2,系统把Service杀死后,不会尝试重新创建这个Service。

  4. START_REDELIVER_INTENT = 3,系统把Service杀死后,会尝试重新创建这个Service,并且会把之前启动Service的最后一个Intent重新传递回来。

到此,我们就分析完Service的start方式启动的过程了。我们小结一下

小结

  1. startService启动Service调用的是ContextImpl的startService方法,在ContextImpl中通过一个IPC过程调用到AMS端的startService方法,AMS再去委托ActiveServices去对Service的启动进行管理。ActiveServices首先回去校验Service的合法性,如果合法的话判断Service所在进程是否已经启动,如果没有启动的话会先去创建进程再来启动Service。如果Service所在进程已经启动,就会通过一个IPC过程调用ApplicationThread的scheduleCreateService方法,进而调用ActivityThread的handleCreateService方法,完成Service的创建以及绑定上下文环境并调用Service的onCreate方法。

  2. 创建Service的IPC过程结果之后,会返回ActiveServices的方法调用处接着执行方法,然后会再通过一个IPC过程来调用Service的onStartCommand方法,并且该方法结束之后会把onStartCommand的返回值告知AMS,AMS又会通知ActiveServices去进行处理。当Service因空间不足被系统杀死后,会根据不同的返回值来对Service进行相应处理。

bind方式启动Service

前面也说了,startService、bindService均是通过ContextImpl进行。直接看一下ContextImpl的bindService方法。

# android.app.ContextImpl
@Override
public boolean bindService(Intent service, ServiceConnection conn,
                           int flags) {
    warnIfCallingFromSystemProcess();
    return bindServiceCommon(service, conn, flags, mMainThread.getHandler(),
            Process.myUserHandle());
}

bindService方法有3个参数,第一个参数Intent,不同说就是表示启动的Service对应的意图,第2个参数ServiceConnection是一个接口用来监控bind方式启动的Service的连接状态。第3个参数是一个flag,一般传递的是Context.BIND_AUTO_CREATE。

需要说明的是,ServiceConnection的onServiceConnected会在Service的onBind方法返回IBinder对象之后调用,而其onServiceDisconnected是在Service意外挂掉,比如Service被系统杀死的时候才会被回调。

# android.content.ServiceConnection
public interface ServiceConnection {
    public void onServiceConnected(ComponentName name, IBinder service);
    public void onServiceDisconnected(ComponentName name);
}

ContextImpl的bindService方法会调用其bindServiceCommon方法。

# android.app.ContextImpl
private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags, Handler
        handler, UserHandle user) {
    IServiceConnection sd;
    if (conn == null) {
        throw new IllegalArgumentException("connection is null");
    }
    // 1 调用LoadedApk的getServiceDispatcher方法
    if (mPackageInfo != null) {
        sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags);
    } else {
        throw new RuntimeException("Not supported in system context");
    }
    validateServiceIntent(service);
    try {
        IBinder token = getActivityToken();
        if (token == null && (flags&BIND_AUTO_CREATE) == 0 && mPackageInfo != null
                && mPackageInfo.getApplicationInfo().targetSdkVersion
                < android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
            flags |= BIND_WAIVE_PRIORITY;
        }
        service.prepareToLeaveProcess(this);
        // 2 通过IPC过程调用AMS的bindService方法
        int res = ActivityManagerNative.getDefault().bindService(
                mMainThread.getApplicationThread(), getActivityToken(), service,
                service.resolveTypeIfNeeded(getContentResolver()),
                sd, flags, getOpPackageName(), user.getIdentifier());
        if (res < 0) {
            throw new SecurityException(
                    "Not allowed to bind to service " + service);
        }
        return res != 0;
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}
package android.app;

import android.content.ComponentName;

oneway interface IServiceConnection {
    void connected(in ComponentName name, IBinder service);
}

bindServiceCommon方法中主要完成两件事情。
首先会调用LoadedApk的getServiceDispatcher方法,该方法会创建一个IServiceConnection对象,IServiceConnection是用AIDL写的,在这里实际上就是ServiceDispatcher.InnerConnection对象。这是因为ServiceConnection必须借助Binder来让远端server回调自己的方法,但是ServiceConnection不具有跨进程通信的能力,而ServiceDispatcher.InnerConnection是一个Binder对象,刚好可以充当这个跨进程通信的角色。ServiceDispatcher在ServiceDispatcher.InnerConnection和ServiceConnection之间起着桥梁的作用。

# android.app.LoadedApk
public final IServiceConnection getServiceDispatcher(ServiceConnection c,
                                                     Context context, Handler handler, int flags) {
    synchronized (mServices) {
        LoadedApk.ServiceDispatcher sd = null;
        ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher> map = mServices.get(context);
        if (map != null) {
            sd = map.get(c);
        }
        if (sd == null) {
            sd = new ServiceDispatcher(c, context, handler, flags);
            if (map == null) {
                map = new ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher>();
                mServices.put(context, map);
            }
            map.put(c, sd);
        } else {
            sd.validate(context, handler);
        }
        return sd.getIServiceConnection();
    }
}

上面的方法中mServices是一个ArrayMap,存储了一个应用当前活动的ServiceConnection和ServiceDispatcher的映射关系。键表示一个Context,说明每个Context对象中是可以存放一组映射关系的。

private final ArrayMap<Context, ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher>> mServices
        = new ArrayMap<Context, ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher>>();

系统首先会搜索ServiceConnection对应 ServiceDispatcher是否存在,如果不存在的话会创建一个ServiceDispatcher对象,在ServiceDispatcher的构造方法中会创建一个InnerConnection对象并持有ServiceDispatcher的引用,而ServiceDispatcher中又持有ServiceConnection的引用,因此当服务端回调的时候可以通过InnerConnection间接的找到ServiceConnection,回调它的方法。

接着分析ContextImpl的bindServiceCommon方法,LoadedApk的getServiceDispatcher返回一个IServiceConnection对象(InnerConnection类型),接着通过一个IPC过程调用了AMS的bindService方法来完成Service的绑定过程,注意此时把IServiceConnection对象传递到了服务端,当然了,服务端拿到的实际上是IServiceConnection的代理对象。

看一下AMS的bindService方法。

public int bindService(IApplicationThread caller, IBinder token, Intent service,
                       String resolvedType, IServiceConnection connection, int flags, String callingPackage,
                       int userId) throws TransactionTooLargeException {
    enforceNotIsolatedCaller("bindService");

    // Refuse possible leaked file descriptors
    if (service != null && service.hasFileDescriptors() == true) {
        throw new IllegalArgumentException("File descriptors passed in Intent");
    }

    if (callingPackage == null) {
        throw new IllegalArgumentException("callingPackage cannot be null");
    }

    synchronized(this) {
        return mServices.bindServiceLocked(caller, token, service,
                resolvedType, connection, flags, callingPackage, userId);
    }
}

bindService中主要做了一些校验,接下来,AMS会调用ActiveServices的bindServiceLocked方法。bindServiceLocked方法会调用bringUpServiceLocked,bringUpServiceLocked会调用realStartServiceLocked方法,realStartServiceLocked方法和之前讲的start方式启动Service的逻辑一致,均是通过ApplicationThread来完成Service的创建并执行其onCreate方法,这里就不重复讲解了。和start方式不同的是,在realStartServiceLocked方法中,当执行完app.thread.scheduleCreateService过程,完成Service的创建和onCreate方法回调之后,还会接着调用ActiveServices的requestServiceBindingsLocked方法。

private final void requestServiceBindingsLocked(ServiceRecord r, boolean execInFg)
        throws TransactionTooLargeException {
    for (int i=r.bindings.size()-1; i>=0; i--) {
        IntentBindRecord ibr = r.bindings.valueAt(i);
        if (!requestServiceBindingLocked(r, ibr, execInFg, false)) {
            break;
        }
    }
}

private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
                                                  boolean execInFg, boolean rebind) throws TransactionTooLargeException {
    if (r.app == null || r.app.thread == null) {
        // If service is not currently running, can't yet bind.
        return false;
    }
    if ((!i.requested || rebind) && i.apps.size() > 0) {
        try {
            bumpServiceExecutingLocked(r, execInFg, "bind");
            r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
            r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
                    r.app.repProcState);
            if (!rebind) {
                i.requested = true;
            }
            i.hasBound = true;
            i.doRebind = false;
        } catch (TransactionTooLargeException e) {
            // Keep the executeNesting count accurate.
            if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while binding " + r, e);
            final boolean inDestroying = mDestroyingServices.contains(r);
            serviceDoneExecutingLocked(r, inDestroying, inDestroying);
            throw e;
        } catch (RemoteException e) {
            if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while binding " + r);
            // Keep the executeNesting count accurate.
            final boolean inDestroying = mDestroyingServices.contains(r);
            serviceDoneExecutingLocked(r, inDestroying, inDestroying);
            return false;
        }
    }
    return true;
}

Service有一个特性,同一个ServiceConnection多次绑定一个Service,Service的onBind方法只会被调用一次。一个ServiceConnection对应AMS端的一个IntentBindRecord。在上面的代码中也可以看出,对于同一个IntentBindRecord只会调用onBind一次。

在ActiveServices的bindServiceLocked方法中会调用ServiceRecord的retrieveAppBindingLocked方法,在这里会用一个Map集合bindings存放bind信息。Intent.FilterComparison是键,它实际上包裹了一个请求Service的Intent,比较两个Intent.FilterComparison是否相等是根据Intent的filterHashCode方法,这个与Intent的mAction、mType、mType、mPackage、mComponent、mCategories有关。我们知道,5.0以上的系统,Service只能够显式启动。具体的是在ContextImpl的validateServiceIntent方法中。

final ArrayMap<Intent.FilterComparison, IntentBindRecord> bindings
            = new ArrayMap<Intent.FilterComparison, IntentBindRecord>();

在requestServiceBindingLocked中, r.app.thread指的就是ApplicationThread的本地代理对象,通过一个IPC过程调用到ApplicationThread的scheduleBindService方法。

public final void scheduleBindService(IBinder token, Intent intent,
                                      boolean rebind, int processState) {
    updateProcessState(processState, false);
    BindServiceData s = new BindServiceData();
    s.token = token;
    s.intent = intent;
    s.rebind = rebind;

    if (DEBUG_SERVICE)
        Slog.v(TAG, "scheduleBindService token=" + token + " intent=" + intent + " uid="
                + Binder.getCallingUid() + " pid=" + Binder.getCallingPid());
    sendMessage(H.BIND_SERVICE, s);
}

这种套路我们已经分析太多了,通过Handler H来发送一个H.BIND_SERVICE消息。然后会交给ActivityThread的handleBindService方法。在该方法中首先根据token获取对应的Service,然后给Intent设置extrasClassLoader, 如果不是重新绑定,就调用Service的onBind方法,并且返回IBinder对象,并传递给AMS。如果是重新绑定,调用Service的onRebind方法。

private void handleBindService(BindServiceData data) {
    // 1 根据token获取Service
    Service s = mServices.get(data.token);
    if (DEBUG_SERVICE)
        Slog.v(TAG, "handleBindService s=" + s + " rebind=" + data.rebind);
    if (s != null) {
        try {
            // 2. 给Intent设置extrasClassLoader
            data.intent.setExtrasClassLoader(s.getClassLoader());
            data.intent.prepareToEnterProcess();
            try {
                // 3 如果不是重新绑定,就调用Service的onBind方法,并且返回IBinder对象,并传递给AMS
                if (!data.rebind) {
                    IBinder binder = s.onBind(data.intent);
                    ActivityManagerNative.getDefault().publishService(
                            data.token, data.intent, binder);
                } else {
                    // 4 如果是重新绑定,直接调用Service的onRebind方法
                    s.onRebind(data.intent);
                    ActivityManagerNative.getDefault().serviceDoneExecuting(
                            data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
                }
                ensureJitEnabled();
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(s, e)) {
                throw new RuntimeException(
                        "Unable to bind to service " + s
                                + " with " + data.intent + ": " + e.toString(), e);
            }
        }
    }
}

当Service的onBind方法调用之后,会通过IPC过程调用AMS的publishService方法。

# com.android.server.am.ActivityManagerService
public void publishService(IBinder token, Intent intent, IBinder service) {
    // Refuse possible leaked file descriptors
    if (intent != null && intent.hasFileDescriptors() == true) {
        throw new IllegalArgumentException("File descriptors passed in Intent");
    }

    synchronized(this) {
        if (!(token instanceof ServiceRecord)) {
            throw new IllegalArgumentException("Invalid service token");
        }
        mServices.publishServiceLocked((ServiceRecord)token, intent, service);
    }
}

从上面的代码可以看出,AMS的publishService方法将具体的工作交给了ActiveServices来完成,调用了它的publishServiceLocked方法。

# com.android.server.am.ActiveServices
void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
    final long origId = Binder.clearCallingIdentity();
    try {
        if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "PUBLISHING " + r
                + " " + intent + ": " + service);
        if (r != null) {
            Intent.FilterComparison filter
                    = new Intent.FilterComparison(intent);
            IntentBindRecord b = r.bindings.get(filter);
            if (b != null && !b.received) {
                b.binder = service;
                b.requested = true;
                b.received = true;
                for (int conni=r.connections.size()-1; conni>=0; conni--) {
                    ArrayList<ConnectionRecord> clist = r.connections.valueAt(conni);
                    for (int i=0; i<clist.size(); i++) {
                        ConnectionRecord c = clist.get(i);
                        if (!filter.equals(c.binding.intent.intent)) {
                         ...
                            continue;
                        }
                        if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Publishing to: " + c);
                        try {
                            c.conn.connected(r.name, service);
                        } catch (Exception e) {
                           ...
                        }
                    }
                }
            }

            serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false);
        }
    } finally {
        Binder.restoreCallingIdentity(origId);
    }
}

publishServiceLocked方法中看起来很多,核心点就一个地方c.conn.connected(r.name, service)。c的类型是ConnectionRecord,c.conn返回的是IServiceConnection对象,实际上就是一个本地代理。真实的对象是ServiceDispatcher.InnerConnection。c.conn.connected实际上就是一个IPC过程调用到ServiceDispatcher.InnerConnection的connected方法。参数中的service就是调用Service的onBind方法返回的Ibinder对象。

来看一下ServiceDispatcher.InnerConnection的定义。

# android.app.LoadedApk.ServiceDispatcher.InnerConnection
private static class InnerConnection extends IServiceConnection.Stub {
    final WeakReference<LoadedApk.ServiceDispatcher> mDispatcher;

    InnerConnection(LoadedApk.ServiceDispatcher sd) {
        mDispatcher = new WeakReference<LoadedApk.ServiceDispatcher>(sd);
    }

    public void connected(ComponentName name, IBinder service) throws RemoteException {
        LoadedApk.ServiceDispatcher sd = mDispatcher.get();
        if (sd != null) {
            sd.connected(name, service);
        }
    }
}

InnerConnection的connected方法中会调用ServiceDispatcher的connected方法。

# android.app.LoadedApk.ServiceDispatcher
public void connected(ComponentName name, IBinder service) {
    if (mActivityThread != null) {
        mActivityThread.post(new RunConnection(name, service, 0));
    } else {
        doConnected(name, service);
    }
}

mActivityThread是一个Handler,实际上就是ActivityThread的H这个Handler,是在ContextImpl的bindService方法中一路传递过来的,作为了ServiceDispatcher的成员变量。所以mActivityThread不为null,就会调用Handler的post方法来切换到主线程中。后面RunConnection的run方法会执行。注意此时传递的第三个参数为0。

看一下RunConnection。

# android.app.LoadedApk.ServiceDispatcher.RunConnection
private final class RunConnection implements Runnable {
    RunConnection(ComponentName name, IBinder service, int command) {
        mName = name;
        mService = service;
        mCommand = command;
    }

    public void run() {
        if (mCommand == 0) {
            doConnected(mName, mService);
        } else if (mCommand == 1) {
            doDeath(mName, mService);
        }
    }

    final ComponentName mName;
    final IBinder mService;
    final int mCommand;
}

RunConnection是ServiceDispatcher的非静态内部类,在run方法中又调用了ServiceDispatcher的doConnected方法。

# android.app.LoadedApk.ServiceDispatcher
public void doConnected(ComponentName name, IBinder service) {
    ServiceDispatcher.ConnectionInfo old;
    ServiceDispatcher.ConnectionInfo info;

    synchronized (this) {
        if (mForgotten) {
            // We unbound before receiving the connection; ignore
            // any connection received.
            return;
        }
        old = mActiveConnections.get(name);
        if (old != null && old.binder == service) {
            // Huh, already have this one.  Oh well!
            return;
        }

        if (service != null) {
            // A new service is being connected... set it all up.
            info = new ConnectionInfo();
            info.binder = service;
            info.deathMonitor = new DeathMonitor(name, service);
            try {
                service.linkToDeath(info.deathMonitor, 0);
                mActiveConnections.put(name, info);
            } catch (RemoteException e) {
                // This service was dead before we got it...  just
                // don't do anything with it.
                mActiveConnections.remove(name);
                return;
            }

        } else {
            // The named service is being disconnected... clean up.
            mActiveConnections.remove(name);
        }

        if (old != null) {
            old.binder.unlinkToDeath(old.deathMonitor, 0);
        }
    }

    // If there was an old service, it is not disconnected.
    if (old != null) {
        mConnection.onServiceDisconnected(name);
    }
    // If there is a new service, it is now connected.
    if (service != null) {
        mConnection.onServiceConnected(name, service);
    }
}

在ServiceDispatcher的doConnected方法最后,调用了mConnection的onServiceConnected方法,也就是调用了在bindService的时候传递的ServiceConnection的onServiceConnected方法。

到此,Service的bind启动过程也分析完毕了。

至于Service的unBind过程,会调用到ActiveServices的unbindServiceLocked方法,在该方法中又调用removeConnectionLocked方法。会去移除ServiceConnetion,当Service上所有的bind 的ServiceConnetion都移除的时候,会通过IPC调用ApplicationThread的scheduleUnbindService方法,然后调用Service的unBind方法。接下来,unbindServiceLocked中还会调用其bringDownServiceLocke方法,在该方法中调用ApplicationThread的scheduleStopService方法,进而调用Service的onDestory方法。

推荐阅读更多精彩内容