我们知道，Android启动Service有两种方式，startService和bindService。
对于通过startService启动的Service，只能作为接收方，启动方可以通过onStartCommand来传递参数。这种启动方式其可以有多个启动者，不过在销毁的时候，一旦有任意一个启动调用了stopService或者自身stopSelf后，该Service就会停止，而启动者的生命周期无法影响到该Service。
对于通过bindService启动的Service，其和启动方有个“绑定”的过程，启动方可以通过Service的binder引用来调用Service的方法。不过这种方式Service的生命周期会关联着启动方的，启动方生命周期结束后，会默认unbindService来结束。
startService很多过程在bindService中都会得到体现，所以本文只介绍bindService的流程。
先看看bindService的调用过程
bindService
bindServiceCommon
这一步中首先会把ServiceConnection转成Binder对象
这一步是在LoadApk中完成的
可以看到，LoadApk会为每个context保存一个key为ServiceConnection、value为ServiceDispatcher的map，这样尽量做到了ServiceConnection对应的Binder对象的复用。如果没有可复用，则把ActivityThread的主Handler和ServiceConnection对应起来，这样在复用的时候，ServiceDispatcher会调用validate方法检查handler为当前主线程handler，保证不错乱。另外，ServiceConnection作为回调接口，其在IPC中实质是以ServiceDispatcher的内部类InnerConnection作为载体来代替的。
接下来，就交给ActivityManagerService处理了
ActiveService.bindServiceLocked
这步顾名思义，是获取根据intent、binder等数据获取Service的信息，其中ServiceLookupResult包含了ServiceRecord和权限信息。进入函数我们可以看到如下：
这一步可以看到，再取ServiceRecord的时候，会先去尝试用缓存，如果设置了FLAG_EXTERNAL_SERVICE且是外部Service调用，则禁止复用。如果无法复用，则创建新的ServiceRecord并赋值。
回到bindServiceLocked中，往下走
首先，ServiceRecord会根据自己的成员函数retrieveAppBindingLocked方法来获取一个AppBindRecord。再此后面会用到一些数据结构：AppBindRecord、ServiceRecord、IntentBindRecord、ProcessRecord、ConnectionRecord。他们之间的关系需要理清楚一下：
ServiceRecord：保存了Service的信息
ProcessRecord：进程的信息
ConnectionRecord：进程和Service建立起的本次通信，记一次ConnectionRecord
AppBindRecord：当某个进程需要用某个Intent启动Service的时候，这时候应用程序和Service的关系由AppBindRecord来维持。所以里面包含：谁启动（ProcessRecord）、启动的是哪个（ServiceRecord）、用什么来启动（IntentBindRecord）、所有启动记录的信息（<code>ArraySet<ConnectionRecord></code>）
IntentBindRecord：如在AppBindRecord所说，用什么来启动Service（Intent），里面携带了ServiceRecord、及所有用此Intent启动Service的<code>ArrayMap<ProcessRecord, AppBindRecord></code>
举个很不恰当的比喻：我想在一张纸上盖一个“汪毅雄”的章。
ProcessRecord：我（行为发起者）
ServiceRecord：“汪毅雄”的章印（行为目标）
IntentBindRecord：制作刻了“汪毅雄”三个字、并且能记录盖章过程的一个智能章。（工具，有权限的人都能用。也可以有很多个不同的，只要能盖出“汪毅雄”这几个字就可以）
AppBindRecord：“我要盖章”这个过程一系列下来的所有记录。
ConnectionRecord：手摁章印的过程。
有上面对数据结构的认识，我们可以看到，要取一个AppbindRecord。
a、我们先用Intent去获取filter。
b、ServiceRecord里有一个成员Map bindings保存所有可以启动该Service的IntentBindRecord，获得filter后，利用它去bindings中尝试复用IntentBindRecord。
c、拿到IntentBindRecord后，再用ProcessRecord去检查IntentBindRecord，看看其里面有没有和ProcessRecord相同进程的且也是启动该Service的AppbindRecord，有的话当然不用再建一个AppBindRecord，直接复用返回。
继续往下
获得AppBindRecord后，再利用传递过来的信息（包括IServiceConnection这个回调接口）创建一个ConnectionRecord，并且把ConnectionRecord分别保存到AppBindRecord、ServiceRecord、ActivityRecord中。
如果flag不为BIND_AUTO_CREATE，或者bringUpServiceLocked成功（return null）后，则可以继续后续的操作，如：Service已存在的时候BIND_TREAT_LIKE_ACTIVITY可以降低Service被杀的概率、重新回调connected、rebind等，本文不做讨论。继续bringUpServiceLocked
在realStartServiceLocked之前，和Activity启动一样，我们先需要判断Service的进程是否存在，如果不存在，需要孵化新的进程，然后再继续Service的启动。这块在Activity启动过程中已经详述，这里就不重复说了，详见《Android 7.0中Launcher启动Activity过程》
当进程存在的时候，我们直接realStartServiceLocked
上面可以看到，这块利用binder通信去告诉进程去创建一个Service---scheduleCreateService，实际创建过程是在用户进程（ActivityThread）中。
ActivityThread会创建一个CreateServiceData，并把ServiceInfo等信息填入，交给main Handler处理，最终会到handleCreateService方法中。我们直接进入
在这个方法中，首先获得Service的ClassLoader，用之load一个Service实例。然后再设置ContextImpl，然后初始化Service在进程中的信息和其binder对象，最后调用Service.onCreate方法，完成创建。然后通过binder告诉AMS service创建成功，也就是serviceDoneExecuting，可以看到告诉AMS的有个type的字段设为SERVICE_DONE_EXECUTING_ANON。
这块是Service生命周期给AMS的回调的类型，有3类。但是在Service onCreate完成后，AMS收到后没太做处理，所以这部分跳过。
刚才在realStartServiceLocked，AMS告诉进程创建Service，但是步骤并没有真正完成，我们回到刚才的方法
看到这里，在创建完成后，会调用requestServiceBindingsLocked方法执行bind操作
AMS进程中，会对bindings中的每一个IntentBindRecord尝试bind其进程。
通过binder告诉ActivityThread，Service需要执行bind操作。然后在ActivityThread会调用到handleBindService方法。
可以看到如果不是rebind，Service会执行Service.onBind（）方法，把IntentBindRecord中的Intent告诉给Service谁bind它了。然后再告诉AMS publishService。
在publishServiceLocked中，对所有ConnectionRecord，把bind结果回调给其IServiceConnection。而IService的Stub在LoadApk中
之后会通过主handler post一个Connection Runnable
最终真正执行到ServiceConnection中的onServiceConnected方法，完成最终绑定的过程
整个Service的bind过程就完成了！