Android Service的绑定过程 _Android

人生难得几回搏，此时不搏待何时。这篇文章主要讲述Android Service的绑定过程相关的知识，希望能为你提供帮助。
通常我们使用Service都要和它通信，当想要与Service通信的时候，那么Service要处于绑定状态的。然后客户端可以拿到一个Binder与服务端进行通信，这个过程是很自然的。
那你真的了解过Service的绑定过程吗？为什么可以是Binder和Service通信？
同样的先看一张图大致了解一下，灰色背景框起来的是同一个类的方法，如下：

文章图片

我们知道调用Context的bindService方法即可绑定一个Service，而ContextImpl是Context的实现类。那接下来就从源码的角度分析Service的绑定过程。
当然是从ContextImpl的bindService方法开始，如下：

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

在bindService方法中又会转到bindServiceCommon方法，将Intent， ServiceConnection对象传进。
那就看看bindServiceCommon方法的实现。

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

在上述代码中，调用了mPackageInfo（ LoadedApk对象）的getServiceDispatcher方法。从getServiceDispatcher方法的名字可以看出是获取一个“服务分发者”。其实是根据这个“服务分发者”获取到一个Binder对象的。
那现在就看到getServiceDispatcher方法的实现。

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

从getServiceDispatcher方法的实现可以知道， ServiceConnection和ServiceDispatcher构成了映射关系。当存储集合不为空的时候，根据传进的key，也就是ServiceConnection，来取出对应的ServiceDispatcher对象。
当取出ServiceDispatcher对象后，最后一行代码是关键，

return sd.getIServiceConnection();

调用了ServiceDispatcher对象的getIServiceConnection方法。这个方法肯定是获取一个IServiceConnection的。

IServiceConnection getIServiceConnection() { return mIServiceConnection; }

那么mIServiceConnection是什么？现在就可以来看下ServiceDispatcher类了。ServiceDispatcher是LoadedApk的内部类，里面封装了InnerConnection和ServiceConnection。如下：

static final class ServiceDispatcher { private final ServiceDispatcher.InnerConnection mIServiceConnection; private final ServiceConnection mConnection; private final Context mContext; private final Handler mActivityThread; private final ServiceConnectionLeaked mLocation; private final int mFlags; private RuntimeException mUnbindLocation; private boolean mForgotten; private static class ConnectionInfo { IBinder binder; IBinder.DeathRecipient deathMonitor; }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); } } }private final ArrayMap< ComponentName, ServiceDispatcher.ConnectionInfo> mActiveConnections = new ArrayMap< ComponentName, ServiceDispatcher.ConnectionInfo> (); ServiceDispatcher(ServiceConnection conn, Context context, Handler activityThread, int flags) { mIServiceConnection = new InnerConnection(this); mConnection = conn; mContext = context; mActivityThread = activityThread; mLocation = new ServiceConnectionLeaked(null); mLocation.fillInStackTrace(); mFlags = flags; }//代码省略}

先看到ServiceDispatcher的构造方法，一个ServiceDispatcher关联一个InnerConnection对象。而InnerConnection呢？，它是一个Binder，有一个很重要的connected方法。至于为什么要用Binder，因为与Service通信可能是跨进程的。
好，到了这里先总结一下：调用bindService方法绑定服务，会转到bindServiceCommon方法。
在bindServiceCommon方法中，会调用LoadedApk的getServiceDispatcher方法，并将ServiceConnection传进，根据这个ServiceConnection取出与其映射的ServiceDispatcher对象，最后调用这个ServiceDispatcher对象的getIServiceConnection方法获取与其关联的InnerConnection对象并返回。简单点理解就是用ServiceConnection换来了InnerConnection。
现在回到bindServiceCommon方法，可以看到绑定Service的过程会转到ActivityManagerNative.getDefault()的bindService方法，其实从抛出的异常类型RemoteException也可以知道与Service通信可能是跨进程的，这个是很好理解的。
而ActivityManagerNative.getDefault()是ActivityManagerService，那么继续跟进ActivityManagerService的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); } }

在上述代码中，绑定Service的过程转到ActiveServices的bindServiceLocked方法，那就跟进ActiveServices的bindServiceLocked方法瞧瞧。如下：

int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service, String resolvedType, final IServiceConnection connection, int flags, String callingPackage, final int userId) throws TransactionTooLargeException {//代码省略ConnectionRecord c = new ConnectionRecord(b, activity, connection, flags, clientLabel, clientIntent); IBinder binder = connection.asBinder(); ArrayList< ConnectionRecord> clist = s.connections.get(binder); if (clist = = null) { clist = new ArrayList< ConnectionRecord> (); s.connections.put(binder, clist); } clist.add(c); //代码省略if ((flags& Context.BIND_AUTO_CREATE) != 0) { s.lastActivity = SystemClock.uptimeMillis(); if (bringUpServiceLocked(s, service.getFlags(), callerFg, false, permissionsReviewRequired) != null) { return 0; } }//代码省略return 1; }

将connection对象封装在ConnectionRecord中，这里的connection就是上面提到的InnerConnection对象。这一步很重要的。
然后调用了bringUpServiceLocked方法，那么就探探这个bringUpServiceLocked方法，

private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg, boolean whileRestarting, boolean permissionsReviewRequired) throws TransactionTooLargeException {//代码省略if (app != null & & app.thread != null) { try { 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. }//代码省略return null; }

可以看到调用了realStartServiceLocked方法，真正去启动Service了。
那么跟进realStartServiceLocked方法探探，如下：

private final void realStartServiceLocked(ServiceRecord r, ProcessRecord app, boolean execInFg) throws RemoteException {//代码省略app.thread.scheduleCreateService(r, r.serviceInfo, mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo), app.repProcState); r.postNotification(); created = 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)); }sendServiceArgsLocked(r, execInFg, true); //代码省略 }

这里会调用app.thread的scheduleCreateService方法去创建一个Service，然后会回调Service的生命周期方法，然而绑定Service呢？
在上述代码中，找到一个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; } } }

咦，我再按住Ctrl+ 鼠标左键，点进去requestServiceBindingLocked方法。如下：

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; }//代码省略return true; }

r.app.thread调用了scheduleBindService方法来绑定服务，而r.app.thread是ApplicationThread，现在关注到 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); }

封装了待绑定的Service的信息，并发送了一个消息给主线程，

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; //代码省略} }

调用了handleBindService方法，即将绑定完成啦。

private void handleBindService(BindServiceData data) { Service s = mServices.get(data.token); 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) { IBinder binder = s.onBind(data.intent); ActivityManagerNative.getDefault().publishService( data.token, data.intent, binder); } else { 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); } } } }

根据token获取到Service，然后Service回调onBind方法。结束了？
可是onBind方法返回了一个binder是用来干嘛的？
我们再看看ActivityManagerNative.getDefault()调用了publishService方法做了什么工作，此时又回到了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); } }

又会交给ActiveServices处理，转到了publishServiceLocked方法，那看到ActiveServices的publishServiceLocked方法，

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)) { if (DEBUG_SERVICE) Slog.v( TAG_SERVICE, " Not publishing to: " + c); if (DEBUG_SERVICE) Slog.v( TAG_SERVICE, " Bound intent: " + c.binding.intent.intent); if (DEBUG_SERVICE) Slog.v( TAG_SERVICE, " Published intent: " + intent); continue; } if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, " Publishing to: " + c); try { c.conn.connected(r.name, service); } //代码省略}

c.conn是什么？它是一个InnerConnection对象，对，就是那个那个Binder，上面也贴出了代码，在ActiveServices的bindServiceLocked方法中， InnerConnection对象被封装在ConnectionRecord中。那么现在它调用了connected方法，就很好理解了。
InnerConnection的connected方法如下：

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

会调用ServiceDispatcher 的connected方法，如下

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

从而ActivityThread会投递一个消息到主线程，此时就解决了跨进程通信。
那么你应该猜到了RunConnection一定有在主线程回调的onServiceConnected方法，

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

咦，还不出现？继续跟进doConnected方法，

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

在最后一个if判断，终于找到了onServiceConnected方法！
总结一下，当Service回调onBind方法，其实还没有结束，会转到ActivityManagerService，然后又会在ActiveServices的publishServiceLocked方法中，从ConnectionRecord中取出InnerConnection对象。有了InnerConnection对象后，就回调了它的connected。在InnerConnection的connected方法中，又会调用ServiceDispatcher的connected方法，在ServiceDispatcher的connected方法向主线程扔了一个消息，切换到了主线程，之后就在主线程中回调了客户端传进的ServiceConnected对象的onServiceConnected方法。
【Android Service的绑定过程】至此， Service的绑定过程分析完毕。