深入理解四大组件（四）Service 的绑定过程

概述

我们可以通过调用 Context 的 startService 来启动 Service，也可以通过 Context 的 bindService 来绑定 ServiceService 的绑定过程将分为两个部分来进行讲解，分别是 ContextImpl 到 AMS 的调用过程和 Service 的绑定过程。

1. ContextImpl 到 AMS 的调用过程

ContextImpl 到 AMS 的调用过程如图所示：

ContextImpl 到 AMS 的调用过程
我们可以用 bindService 方法来绑定 Service，它的实现在 ContextWrapper 中，代码如下所示：
frameworks/base/core/java/android/content/ContextWrapper.java

@Override
 public boolean bindService(Intent service, ServiceConnection conn,
         int flags) {
     return mBase.bindService(service, conn, flags);
 }

上一章我们得知 mBase 具体就是指向 ContextImpl 的，接着查看 ContextImpl 的 bindService 方法：
frameworks/base/core/java/android/app/ContextImpl.java

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

在 bindService 方法中，又返回了 bindServiceCommon 方法，代码如下所示：
frameworks/base/core/java/android/app/ContextImpl.java

private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags, Handler
        handler, UserHandle user) {
    IServiceConnection sd;
    if (conn == null) {
        throw new IllegalArgumentException("connection is null");
    }
    if (mPackageInfo != null) {
        sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags);  //1
    } else {
        throw new RuntimeException("Not supported in system context");
    }
    validateServiceIntent(service);
    try {
     ...
     /**
     * 2
     */
        int res = ActivityManagerNative.getDefault().bindService(
            mMainThread.getApplicationThread(), getActivityToken(), service,
            service.resolveTypeIfNeeded(getContentResolver()),
            sd, flags, getOpPackageName(), user.getIdentifier());
      ...
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

在注释 1 处调用了 LoadedApk 类型的对象 mPackageInfo 的 getServiceDispatcher 方法，它的主要作用是将 ServiceConnection 封装为 IServiceConnection 类型的对象 sd，从 IServiceConnection 的名字我们就能得知它实现了 Binder 机制，这样 Service 的绑定就支持了跨进程。接着在注释 2 处我们又看见了熟悉的代码，最终会调用 AMS 的 bindService 方法。

2. Service 的绑定过程

AMS 的 bindService 方法代码如下所示：
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

  public int bindService(IApplicationThread caller, IBinder token, Intent service,
            String resolvedType, IServiceConnection connection, int flags, String callingPackage,
            int userId) throws TransactionTooLargeException {
        enforceNotIsolatedCaller("bindService");
...
        synchronized(this) {
            return mServices.bindServiceLocked(caller, token, service,
                    resolvedType, connection, flags, callingPackage, userId);
        }
    }

bindService 方法最后会调用 ActiveServices 类型的对象 mServices 的 bindServiceLocked 方法：
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

    int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
            String resolvedType, final IServiceConnection connection, int flags,
            String callingPackage, final int userId) throws TransactionTooLargeException {
      ···
      try {
          ···
            AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);  //1
          ···
                if ((flags&Context.BIND_AUTO_CREATE) != 0) {
                    s.lastActivity = SystemClock.uptimeMillis();
                    if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,
                            permissionsReviewRequired) != null) {  //2
                        return 0;
                    }
                }
              ···
              if (s.app != null && b.intent.received) {  //3
                try {
                    c.conn.connected(s.name, b.intent.binder, false);  //4
                } catch (Exception e) {
                    Slog.w(TAG, "Failure sending service " + s.shortName
                            + " to connection " + c.conn.asBinder()
                            + " (in " + c.binding.client.processName + ")", e);
                }
                if (b.intent.apps.size() == 1 && b.intent.doRebind) {  //5
                    requestServiceBindingLocked(s, b.intent, callerFg, true);  //6
                }
            } else if (!b.intent.requested) {  //7
                requestServiceBindingLocked(s, b.intent, callerFg, false);  //8
            }
            getServiceMapLocked(s.userId).ensureNotStartingBackgroundLocked(s);
        } finally {
            Binder.restoreCallingIdentity(origId);
        }
        return 1;
    }

讲到这里，有必要先介绍几个与 Service 相关的对象类型，这样有助于对源码进行理解，如下所示：

• ServiceRecord：用于描述一个 Service。
• ProcessRecord：一个进程的信息。
• ConnectionRecord：用于描述应用程序进程和 Service 建立的一次通信。
• AppBindRecord：应用程序进程通过 Intent 绑定 Service 时，会通过 AppBindRecord 来维护 Service 与应用程序进程之间的关联。其内部存储了谁绑定的 Service（ProcessRecord）、被绑定的 Service（AppBindRecord ）、绑定 Service 的 Intent（IntentBindRecord）和所有绑定通信记录的信息（ArraySet<ConnectionRecord>）。
• IntentBindRecord：用于描述绑定 Service 的 Intent。

在注释 1 处调用了 ServiceRecord 的 retrieveAppBindingLocked 方法来获得 AppBindRecord，retrieveAppBindingLocked 方法内部创建 IntentBindRecord，并对 IntentBindRecord 的成员变量进行赋值，后面我们会详细极少这个关键的方法。
在注释 2 处调用 bringUpServiceLocked 方法，在 bringUpServiceLocked 方法中又调用 realStartServiceLocked 方法，最终由 ActivityThread 来调用 Service 的 onCreate 方法启动 Service，这也说明了 bindService 方法内部会启动 Service，启动 Service 这一过程上一章我们已经讲过。在注释 3 处 s.app != null 表示 Service 已经运行，其中 s 是 ServiceRecord 类型对象，app 是 ProcessRecord 类型对象。b.intent.received 表示当前应用程序进程已经接受到绑定 Service 时返回的 Binder，这样应用程序进程就可以通过 Binder 来获取要绑定的 Service 的访问接口。在注释 4 处调用 c.conn 的 connected 方法，其中 c.conn 指的是 IServiceConnection，它的具体实现为 ServiceDispatcher.InnerConnection，其中 ServiceDispathcer 是 LoadedApk 的内部类，InnerConnection 的 connected 方法内部会调用 H 的 post 方法向主线程发送消息，并且解决当前应用程序进程和 Service 跨进程通信的问题，在后面会详细介绍这一过程。在注释 5 处如果当前应用程序进程是第一个与 Service 进行绑定的，并且 Service 已经调用过 onUnBind 方法，则需要调用注释 6 处的代码。在注释 7 处如果应用程序进程的 Client 端没有发送过绑定 Service 的请求，则会调用注释 8 处的代码，注释 8 处和注释 6 处的代码区别就是最后一个参数 rebind 为 false，表示不是重新绑定。接着我们查看注释 6 处的 requestServiceBindingLocked 方法，代码如下所示：
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
        boolean execInFg, boolean rebind) throws TransactionTooLargeException {
   ...
    if ((!i.requested || rebind) && i.apps.size() > 0) {  //1
        try {
            bumpServiceExecutingLocked(r, execInFg, "bind");
            r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
            r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
                    r.app.repProcState);  //2
           ...
        } 
        ...
    }
    return true;
}

注释 1 处 i.requested 表示是否发送过绑定 Service 的请求，从前面的代码得知是没有发送过，因此，!i.requested 为 true。从前面的代码得知 rebind 值为 false，那么 (!i.requested || rebind) 的值为 true。i.apps.size() > 0 表示什么呢？其中 i 是 IntentBindRecord 类型的对象，AMS 会为每个绑定 Service 的 Intent 分配一个 IntentBindRecord 类型对象，代码如下所示：
frameworks/base/services/core/java/com/android/server/am/IntentBindRecord.java

final class IntentBindRecord {
    //被绑定的 Service
    final ServiceRecord service;
    //绑定 Service 的 Intent
    final Intent.FilterComparison intent; // 
    //所有用当前 Intent 绑定 Service 的应用程序进程
    final ArrayMap<ProcessRecord, AppBindRecord> apps
            = new ArrayMap<ProcessRecord, AppBindRecord>();  //1
···
}

我们来查看 IntentBindRecord 类，不同的应用程序进程可能使用同一个 Intent 来绑定 Service，因此在注释 1 处会用 apps 来储存所有用当前 Intent 绑定 Service 的应用程序进程。i.apps.size() > 0 表示所有用当前 Intent 绑定 Service 的应用程序进程个数大于 0，下面来验证 i.apps.size() > 0 是否为 ture。我们回到 bindServiceLocked 方法的注释 1 处，ServiceRecord 的 retrieveAPPBindingLocked 方法如下所示：
frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java

    public AppBindRecord retrieveAppBindingLocked(Intent intent,
            ProcessRecord app) {
        Intent.FilterComparison filter = new Intent.FilterComparison(intent);
        IntentBindRecord i = bindings.get(filter);
        if (i == null) {
            i = new IntentBindRecord(this, filter);  //1
            bindings.put(filter, i);
        }
        AppBindRecord a = i.apps.get(app);  //2
        if (a != null) {
            return a;
        }
        a = new AppBindRecord(this, i, app);  //3
        i.apps.put(app, a);
        return a;
    }

注释 1 处创建了 IntentBindRecord，注释 2 处根据 ProcessRecord 获得 IntentBindRecord 中储存的 AppBindRecord，如果 AppBindRecord 不为 null 就返回，如果不为 null 就在注释 3 处创建 AppBindRecord，并将 ProcessRecord 作为 key，AppBindRecord 作为 value 保存在 IntentBindRecord 的 apps（i.apps）中。回到 requestServiceBindingLocked 方法的注释 1 处，结合 ServiceRecord 的 requestServiceBindingLocked 方法，我们得知 i.apps.size() > 0 为 ture，这样就会调用注释 2 处的代码，r.app.thread 的类型为 IApplicationThread，它的实现我们已经很熟悉了，是 ActivityThread 的内部类 ApplicationThread，scheduleBindService 方法如下所示：
frameworks/base/core/java/android/app/ActivityThread.java

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);
      }

首先将 Service 的信息封装成 BindServiceData 对象，需要注意的 BindServiceData 的成员变量 rebind 的值为 false，后面会用到它。接着将 BindServiceData 传入到 sendMessage 方法中。sendMessage 向 H 发送消息，我们接着查看 H 的 handleMessage 方法：
frameworks/base/core/java/android/app/ActivityThread.java

public void handleMessage(Message msg) {
          if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
          switch (msg.what) {
          ...
              case BIND_SERVICE:
                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceBind");
                    handleBindService((BindServiceData)msg.obj);
                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                    break;
          ...
           }
        ...
        }

H 在接受到 BIND_SERVICE 类型消息时，会在 handleMessage 方法中会调用 handleBindService 方法：
frameworks/base/core/java/android/app/ActivityThread.java

    private void handleBindService(BindServiceData data) {
        Service s = mServices.get(data.token);  //1
        if (DEBUG_SERVICE)
            Slog.v(TAG, "handleBindService s=" + s + " rebind=" + data.rebind);
        if (s != null) {
            try {
                data.intent.setExtrasClassLoader(s.getClassLoader());
                data.intent.prepareToEnterProcess();
                try {
                    if (!data.rebind) {  //2
                        IBinder binder = s.onBind(data.intent);  //3
                        ActivityManager.getService().publishService(
                                data.token, data.intent, binder);  //4
                    } else {
                        s.onRebind(data.intent);  //5
                        ActivityManager.getService().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);
                }
            }
        }
    }

在注释 1 处获取要绑定的 Service。注释 2 处的 BindServiceData 的成员变量 rebind 的值为 false，这样会调用注释 3 处的代码来调用 Service 的 onBind 方法，到这里 Service 处于绑定状态了。如果 rebind 的值为 ture 就会调用注释 5 处的 Service 的 onRebind 方法，这一点结合前文的 bindServiceLocked 方法的注释 5 处，得出的结论就是：如果当前应用程序进程第一个与 Service 进行绑定，并且 Service 已经调用过 onUnBind 方法，则会调用 Service 的 onBind 方法。handleBindService 方法有两个分支，一个是绑定过 Service 的情况，另一个是未绑定的情况，这里分析未绑定的情况，查看注释 4 处的代码，实际上是调用 AMS 的 publishService 方法。讲到这，先给出这一部分的代码时序图（不包括 Service 启动过程）

Service 绑定过程部分时序图
接着来查看 AMS 的 publishService 方法，代码如下所示：
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

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

publishService 方法中，调用了 ActiveServices 类型的 mServices 对象的 publishServiceLocked 方法：
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
       final long origId = Binder.clearCallingIdentity();
       try {
          ...
                   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++) {
                        ...
                           try {
                               c.conn.connected(r.name, service); //1
                           } catch (Exception e) {
                            ...
                           }
                       }
                   }
               }
               serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false);
           }
       } finally {
           Binder.restoreCallingIdentity(origId);
       }
   }

注释 1 处的代码，我在前面介绍过，c.conn 指的是 IServiceConnection，它是 ServiceConnection 在本地的代理，用于解决当前应用程序进程和 Service 跨进程通信的问题，具体实现为 ServiceDispatcher.InnerConnection，其中 ServiceDispatcher 是 LoadedApk 的内部类，ServiceDispatcher.InnerConnectiond 的 connected 方法的代码如下所示：
frameworks/base/core/java/android/app/LoadedApk.java

static final class ServiceDispatcher {
     ...
        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);  //1
                }
            }
        }
 ...
 }

在注释 1 处调用了 ServiceDispatcher 类型的 sd 对象的 connected 方法，代码如下所示：
frameworks/base/core/java/android/app/LoadedApk.java

public void connected(ComponentName name, IBinder service) {
           if (mActivityThread != null) {
               mActivityThread.post(new RunConnection(name, service, 0));  //1
           } else {
               doConnected(name, service);
           }
       }

注释 1 处调用 Handler 类型的对象 mActivityThread 的 post 方法，mActivityThread 实际上指向的是 H。因此，通过调用 H 的 post 方法将 RunConnection 对象的内容运行在主线程中。RunConnection 是 LoadedApk 的内部类，定义如下所示：
frameworks/base/core/java/android/app/LoadedApk.java

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 的 run 方法中调用了 doConnected 方法：
frameworks/base/core/java/android/app/LoadedApk.java

public void doConnected(ComponentName name, IBinder service) {
  ...
    if (old != null) {
        mConnection.onServiceDisconnected(name);
    }
    if (service != null) {
        mConnection.onServiceConnected(name, service);  //1
    }
}

在注释 1 处调用了 ServiceConnection 类型的对象 mConnection 的 onServiceConnected 方法，这样在客户端中实现了 ServiceConnection 接口的类的 onServiceConnected 方法就会被执行。至此，Service 的绑定过程就分析到这。

最后给出剩余部分的代码时序图：

Service 的绑定过程剩余部分的代码时序图