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 mActivityThre