简介
IPC通信，通常包括客服端和服务端。服务端的拉起: 通常都配置成开机启动拉起，开机的时候init进程把服务拉起。此文章介绍服务的另外一种拉起方式动态加载：服务不配置成开机拉起，在客户端运行的时候，去拉起对应的服务。示例以openharmony 3.1版本为基础实现的。
- 动态加载的流程解析。
- 动态加载的示例。
- 动态加载的测试。
- 本用例开发板(3516开发板：HiSpark_AI_Hi3516D_One_Light_VER.B开发板上测试)。
如果需要对下IPC有更全面的了解，需要参考下面三篇文档：
服务的开机启动配置参考文档OpenHarmony SA 动态库服务 拉起的main入口IPC的通信流程参考Openharmony IPC通信。
如何实现一个IPC客户端和服务端参考Openharmony 实现的一个IPC的客户端和服务端。
动态加载数据流程解析
动态加载涉及到4个进程间的数据流转。对于init的数据处理到拉起服务端过程进行大致梳理，如果发现有问题的的可以交流，把这个流程做更正确更精准一些。流程可以参考下图+结合后面的示例分析。
- 客户端(myappclient) 发起拉起 服务命令，最后init拉起服务端(myappservice_sa)。
- 服务拉启之后，客户端和服务端 进行IPC通信。
流程图工具vscode+plantUML(插件)。
init拉起服务的日志：hilog -t kmsg。
动态加载示例
子系统配置
build\subsystem_config.json：
"myapp": {
"path":"myapptest",
"name": "myapp"
}
产品配置
productdefine\common\products\Hi3516DV300.json：
"myapp:myappservice_test":{}
代码
代码目录结构
myapptest放在代码根目录，代码见附件。
服务ID的添加
服务ID有统一的头文件。
foundation\distributedschedule\samgr\interfaces\innerkits\samgr_proxy\include\system_ability_definition.h：
MY_APP_SERVICE_ID = 9000,
...
{ MY_APP_SERVICE_ID, "MyAppService"},
客户端动态加载服务的关键代码段，见附件：
// 加载动态库服务
sptr<CallBack> callback(new CallBack());
saMgr->LoadSystemAbility(MY_APP_SERVICE_ID, callback);
// 阻塞，等待isload传入值
bool laodResult = callback->getLoadResult();
(void)laodResult;
编译
要全量编译9000.xml 才能生产myappservice_sa.xml。
编译命令：./build.sh --product-name Hi3516DV300 --ccache。
修改开发板的读写权限
进入终端：hdc_std.exe shell
修改权限：mount -o remount,rw /
添加test目录：mkdir /data/test/
将编译文件发送到开发板对应目录：
动态服务库：libmyappservice.z.so 发送到开发板目录：/system/lib/
动态库的xml文件：myappservice_sa.xml 发送到开发板目录：/system/profile/
启动配置：myappservice_sa.cfg 发送到开发板目录：/system/etc/init/
客户端：myappclient 发送到开发板目录：/data/test/
修改客户端可执行权限(其他文件权限不够也需要对于修改，这里只以客户端为例)。
切到对应的目录：cd /data/test/
修改成可执行：chmod 0755 myappclient
测试
第一步：重启开发板
终端1:
第二步：查询服务是否启动ps -A | grep myappservice_sa, 没有启动。
终端2：
第三步：运行客户端/data/test/myappclient。
终端1：
第四步：查询服务是否启动ps -A | grep myappservice_sa, 启动，并且客户端和服务端的交互结果也已经输出。
动态加载的官网。
文章相关附件可以点击下面的原文链接前往下载。
https://ost.51cto.com/resource/2112。
https://ost.51cto.com/resource/2113。
