细谈客户端与服务端的联动机制

前情回顾

在之前的文章中，我们介绍了鸿蒙系统框架中的主要构成者，server和client是进行往来的主要对象，而samgr则充当一个中介处，为某些特定的服务功能提供往来帮助，也分析了客户端与服务端的搭建流程，那么今天，我们将分析客户端与服务端之间的IPC来往机制。

IPC过程（client EP 与 Server）

简单介绍来往流程和相关重要函数介绍

首先我们要知道IPC来往的原理，无非就是client EP向Server注册、查询相关Feature等等。

所以今天我们从之前简单谈到的 RegisterRemoteEndpoint 函数开始分析。

static int RegisterRemoteEndpoint(const IpcContext *context, SvcIdentity *identity)	//注册远程终端
// IpcContext是指函数中使用到的Ipc的上下文
// SvcIdentity是指客户端和服务端进行调用的使用者身份

该函数中用来实现Ipc过程的函数主要是这两句：

SvcIdentity samgr = {
   
   SAMGR_HANDLE, SAMGR_TOKEN, SAMGR_COOKIE};
int err = Transact(context, samgr, INVALID_INDEX, &req, &reply, LITEIPC_FLAG_DEFAULT, (uintptr_t *)&replyBuf);

Transact函数定义在liteipc_adapter.c中的SendRequest()函数，顾名思义，该函数的功能就是用来发送IPC请求的，其相关变量的定义如下：
1.req: IPC通信中传送的命令和重要参数，经过序列化处理了，接收端反序列化处理即可解析出来。
2.reply：类似req，但是是信息接收端处理完消息后，反馈回来的应答信息。
3.context: IPC通信通道的上下文。

在前面的学习中我们知道，在samgr中，IPC是通信接收方的身份信息；Handle的作用是标明用哪个EP（终端）来接收信息；token的作用是标明在该EP下用哪个router来处理信息。在服务端与客户端的IPC来往中很多Handle和token都是固定的、对应写好的。

所以接下来我们分析samgr EP

当Samgr EP接收到IPC请求时的处理

通过查询一些大牛的博客，我大概知道了Samgr EP的一些工作流程，首先就是它的boss监控线会在StartLoop循环中收到发给我们前面提到的SvcIdentity samgr的IPC消息，然后通过一个特定的函数——Dispatch（）来对消息进行处理，我们来简单看看这个函数：

Dispatch()

static int Dispatch(const IpcContext *context, void *ipcMsg, IpcIo *data, void *argv)
{
   
   
    if (argv == NULL || ipcMsg == NULL) {
   
   
        return EC_INVALID;
    }
    //当前boss所在EP
    Endpoint *endpoint = (Endpoint *)argv;
    uint32_t token = (uint32_t