「本文正在参加星光计划3.0–夏日挑战赛」

@toc

简介

IPC通信，通常包括客服端和服务端。服务端的拉起: 通常都配置成开机启动拉起，开机的时候init进程把服务拉起。此文章介绍服务的另外一种拉起方式动态加载：服务不配置成开机拉起，在客户端运行的时候，去拉起对应的服务。示例以OpenHarmony3.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, 启动，并且客户端和服务端的交互结果也已经输出。

动态加载的官网