Android中的Service：Binder，Messenge
bindService()
这是一种比startService更复杂的启动方式，同时使用这种方式启动的service也能完成更多的事情，比如其他组件可向其发送请求，接受来自它的响应，甚至通过它来进行IPC等等。我们通常将绑定它的组件称为客户端，而称它为服务端。
如果要创建一个支持绑定的service，我们必须要重写它的onBind()方法。这个方法会返回一个IBinder对象，它是客户端用来和服务器进行交互的接口。
而要得到IBinder接口，我们通常有三种方式继承Binder类，使用Messenger类，使用AIDL。
1. 继承Binder类
Binder是什么？
Binder实现了IBinder接口，通过实现Binder类，我们的客户端可以直接通过这个类调用服务端的公有方法。另外，虽然从IPC的角度来讲，Binder是Android中的一种跨进程通信方式，但是其实一般service里面的Binder是不会涉及进程间通信的，所以其在这种情况下显得较为简单。
下面我们来看下通过继承Binder类实现客户端与服务端通信应该怎样做：
- 在service类中，创建一个满足以下任一要求的Binder实例：
- 包含客户端可调用的公共方法
- 返回当前Service实例，其中包含客户端可调用的公共方法
- 返回由当前service承载的其他类的实例，其中包含客户端可调用的公共方法
- 在onBind()方法中返回这个Binder实例
- 在客户端中通过onServiceDisconnected()方法接收传过去的Binder实例，并通过它提供的方法进行后续操作。
可以看到，在使用这种方法进行客户端与服务端之间的交互是需要有一个强制类型转换的——在onServiceDisconnected()中获得一个经过转换的IBinder对象，我们必须将其转换为service类中的Binder实例的类型才能正确的调用其方法。而这强制类型转换其实就隐含了一个使用这种方法的条件：客户端和服务端应当在同一个进程中！不然在类型转换的时候也许会出现问题——在另一个进程中一定有这个Binder实例么？没有的话就不能完成强制类型转换。
2 使用Messenger
Messenger的核心其实就是Message以及Handler来进行线程间的通信。下面讲一下通过这种方式实现IPC的步骤：
- 服务端实现一个Handler，由其接受来自客户端的每个调用的回调
- 使用实现的Handler创建Messenger对象
- 通过Messenger得到一个IBinder对象，并将其通过onBind()返回给客户端
- 客户端使用 IBinder 将 Messenger（引用服务的 Handler）实例化，然后使用后者将 Message 对象发送给服务
- 服务端在其 Handler 中（具体地讲，是在 handleMessage() 方法中）接收每个 Message
3 通过AIDL
基本上有下面这些步骤：
- 服务端创建一个AIDL文件，将暴露给客户端的接口在里面声明
- 在service中实现这些接口
- 客户端绑定服务端，并将onServiceConnected()得到的IBinder转为AIDL生成的IInterface实例
- 通过得到的实例调用其暴露的方法
Messenger与AIDL的比较
| 优点 | |
|---|---|
| AIDL | 1 在有大量的并发请求时具有优势，Messenger只能串行的解决请求。 2 当要直接跨进程调用服务端的方法时，只能使用AIDL。 而使用Messenger的时候只能通过Message来传递信息实现交互 |
| Messenger | 1 使用简单 2 它会把所有的请求排入队列，因此你几乎不用担心多线程可能会带来的问题。 |
service的生命周期
当服务与所有客户端之间的绑定全部取消时，Android 系统便会销毁这个服务（除非还使用 onStartCommand() 启动了该服务）。因此，如果服务是纯粹的绑定服务，原则上我们是无需对其生命周期进行管理的—Android 系统会根据它是否绑定到任何客户端帮我们管理。但实际上，我们应该始终在完成与服务的交互时或 Activity 暂停时取消绑定，以便服务能够在未被占用时关闭。
如果你只需要在 Activity 可见时与服务交互，则可以在 onStart() 期间绑定，在 onStop() 期间取消绑定。如果你希望 Activity 在后台停止运行状态下仍可接收响应，则可在 onCreate() 期间绑定，在 onDestroy() 期间取消绑定。但是注意，这意味着你的 Activity 在其整个运行过程中（甚至包括后台运行期间）都需要使用服务，因此如果服务位于其他进程内，那么当你提高该进程的权重时，系统终止该进程的可能性会增加。通常情况下，切勿在 Activity 的 onResume() 和 onPause() 期间绑定和取消绑定，因为每一次生命周期转换都会发生这些回调，我们应该使发生在这些转换期间的处理保持在最低水平。此外，如果我们的应用内的多个 Activity 绑定到同一服务，并且其中两个 Activity 之间发生了转换，则如果当前 Activity 在下一次绑定（恢复期间）之前取消绑定（暂停期间），系统可能会销毁服务并重建服务。
此外，如果我们的服务已启动并接受绑定，则当系统调用 onUnbind() 方法时，如果我们想在客户端下一次绑定到服务时接收 onRebind() 调用（而不是接收 onBind() 调用），则可选择返回 true。onRebind() 返回空值，但客户端仍在其 onServiceConnected() 回调中接收 IBinder。
什么时候用startService什么时候用bindService?
这个其实可以通过它们的特点很轻松的得到结论：它们之间的主要区别其实体现在两点，能否交互，以及生命周期。所以很显然的，startService适合那种启动之后不显式停止它就永远在后台运行，并且不需要客户端与服务端交互的service。比方说一条专门拿来存数据到本地数据库的service，它就一直在后台等着有别的组件startService，然后把拿到的数据存入数据库，这就显然是用startService做的事情。而bindService呢，就适合那种可以交互的，可以掌控它什么时候停什么时候开始的。另外，如果有IPC的需求，那当然bindService是必不可少的了。
在大多数情况下，startService和bindService都是相辅相成的，它们并不是孤立的存在。
作者：lypeer
链接：https://blog.csdn.net/luoyanglizi/article/details/51594016
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
