愉快无负担的跨进程通信方式2

1.背景

前一段时间借鉴 EventBus 的思想写了 ProcessBus （ ）,可以让我们比较方便的进行跨进程通信，但是 EventBus 更多的是被动的监听某个事件，而我们在实际的场景当中，有时还需要主动的调用某个服务。所以又对 ProcessBus 进行了一些扩展，增加了服务的注册和调用的接口，同样也能够非常方便的进行跨进程调用。 欢迎一起共建。

地址：https://github.com/bearhuang-omg/ProcessBus

2.使用方式

新增的接口也非常的简单：

例子：

// 注册服务
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。

时序图

时序图如下所示：

关于性能

从上面的时序图当中可以看到，使用 ProcessBus 调用服务时，需要经历两次跨进程通信。第一次是子进程2 callService，将请求传递给主进程，主进程再将请求传递给子进程1，涉及了两次跨进程通信。 官方吭哧吭哧的搞了一套 binder，好不容易提高了性能，减少了一次内存拷贝，结果 ProcessBus 又把性能给降下去了。 其实这里主要是考虑以下两个因素：

1. ProcessBus 主要目的是降低跨进程通信的成本，防止每个模块都定义自己的 AIDL 文件，导致越来越难以维护；所以如果业务场景对于性能有较高的要求，可能还是使用原生的 AIDL 实现会比较合适；
2. 对于频繁跨进程通信的场景，其实有考虑过，提供一个 getService 的接口，返回 binder 对象，让子进程直接获取到 IService 对象，然后就可以直接用 IService 进行通信，而无需通过主进程了。但实际上，提供服务的大多是主进程，通常的一个调用流程如下： 此时，由主进程直接返回 response 会更加高效，因此暂时没有提供 getService 的接口，后续如果有需要，也可以提供出来。