1.背景
前一段时间借鉴 EventBus 的思想写了 ProcessBus （ 愉快无负担的跨进程通信方式 ）,可以让我们比较方便的进行跨进程通信，但是 EventBus 更多的是被动的监听某个事件，而我们在实际的场景当中，有时还需要主动的调用某个服务。所以又对 ProcessBus 进行了一些扩展，增加了服务的注册和调用的接口，同样也能够非常方便的进行跨进程调用。
欢迎一起共建。
地址：https://github.com/bearhuang-omg/ProcessBus
2.使用方式
新增的接口也非常的简单：
| 接口 | 参数 | 返回值 | 备注 |
|---|---|---|---|
| registerService | service: IProcessService | 无 | 注册服务 |
| unRegisterService | serviceName: String | 无 | 反注册服务 |
| callService | request: Request | Response | 调用服务 |
例子：
// 注册服务
Bus.registerService(object : IProcessService {
override fun call(request: Request): Response {
Log.i(TAG, "request params:${request.params}")
return Response("hello world!!!")
}
override fun getServiceName(): String {
return "testService"
}
})
// 反注册服务
Bus.unRegisterService("testService")
// 调用服务
GlobalScope.launch {
val request = Request("testService")
request.addParams("parms1","test")
val response = Bus.callService(request)
}
3.实现
结构图
整体结构图如下所示：
我们在调用 registerService 的时候，需要传递 IProcessService 接口，内部会将其封装成一个 Iservice 对象，Iservice 是一个 binder 对象，然后将其传递给主进程，主进程会保存一个服务的 map，其中 key 是 serviceName ，value 是 Iservice 对象。
当另外一个进程来调用时，主进程会通过 serviceName 找到 Iservice ，调用 call 接口，然后返回 Response。
时序图
时序图如下所示：
| 步骤 | 备注 | |
|---|---|---|
| 1 | registerService | 子进程注册服务，传递 Iservice 对象 |
| 2 | callService | 另一个子进程通过 serviceName 调用服务 |
| 3 | call | 主进程匹配到服务之后，调用对应的服务 |
| 4 | 返回给主进程response | 子进程执行完成，将结果返回给主进程 |
| 5 | 返回给子进程response | 主进程收到结果，将结果返回给对应的进程 |
关于性能
从上面的时序图当中可以看到，使用 ProcessBus 调用服务时，需要经历两次跨进程通信。第一次是子进程2 callService，将请求传递给主进程，主进程再将请求传递给子进程1，涉及了两次跨进程通信。
官方吭哧吭哧的搞了一套 binder，好不容易提高了性能，减少了一次内存拷贝，结果 ProcessBus 又把性能给降下去了。
其实这里主要是考虑以下两个因素：
- ProcessBus 主要目的是降低跨进程通信的成本，防止每个模块都定义自己的 AIDL 文件，导致越来越难以维护；所以如果业务场景对于性能有较高的要求，可能还是使用原生的 AIDL 实现会比较合适；
- 对于频繁跨进程通信的场景，其实有考虑过，提供一个 getService 的接口，返回 binder 对象，让子进程直接获取到 IService 对象，然后就可以直接用 IService 进行通信，而无需通过主进程了。但实际上，提供服务的大多是主进程，通常的一个调用流程如下：
此时，由主进程直接返回 response 会更加高效，因此暂时没有提供 getService 的接口，后续如果有需要，也可以提供出来。