简介
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。