作者:苟晶晶
当开发者为OpenHarmony系统框架开发某些功能时,有时需要将这个功能包装成一个独立的服务进程运行在系统中,为了其它应用进程能够调用此服务,开发人员需要基于系统IPC通信框架编写一套远程接口调用实现。实现Service远程调用接口需要开发人员熟悉IPC通信框架,了解proxy/stub的继承与实现方式,掌握C++类型转为MessageParcel数据包的各种API方法,有一定的学习成本。而Service代码生成工具能够帮助使用者生成框架代码,提升开发效率。用户只需提供一个定义远程方法的.h头文件,工具会自动生成整个Service框架的代码,包含Ability注册、proxy/stub类实现、MessageParcel数据包构造、Service子系统编译及开机自启动相关配置文件。
Service框架代码生成工具包含工具入口、工具框架、公共模块、运行环境、系统平台。其中,工具入口描述调用Service框架代码生成工具的入口方式,支持命令行调用、VS Code插件(即VS插件)调用,从而可以根据开发环境的不同,采用相对应的调用Service框架代码生成工具的入口方式,实现Service框架代码生成工具的入口多样性,便于调用Service框架代码生成工具。工具框架包含C语法解析器、代码生成器两部分,C语法解析器支持包括但不限于对class、function、properties、parameter等内容的解析,代码生成器支持包括但不限于对proxy、stub、service、interface等服务框架代码的生成。公共模块描述通用的、在不同部分均会使用的公共接口与模块,可以包括通用的正则校验、类型映射、代码模板、文件操作等模块,运行环境描述Service框架代码生成工具运行的环境,包括Nodejs与Python/ target=_blank class=infotextkey>Python,由于Nodejs本身具有跨平台性特点,故Service框架代码生成工具可以在windows、linux、mac、OpenHarmony等不同系统平台灵活使用,Service框架代码生成工具的运行环境另一部分是python,针对不同平台做python适配,Service框架代码生成工具即可实现跨平台使用。
visual studio code 版本需1.62.0及以上。
1、 打开VS Code,在左侧边栏中选择插件安装。
2、 在应用商店搜索service-gen插件,再单击安装。
3、 安装完成后就会在VS Code的插件管理器中能看到service-gen这个插件了。
4、 在VS Code中找到需要转换的.h文件,待转换的.h文件内容如下所示:
#ifndef TEST_H
#define TEST_H
namespace OHOS {
namespace Example {
/**
* @brief service服务,提供IPC调用接口
* @ServiceClass
*/
class test {
public:
int testFunc(int v1, int v2, bool v3);
};
} // namespace Example
} // namespace OHOS
#endif // TEST_H
5、 右键单击.h文件,选择“ Service Generate Frame”选项。
6、 工具打开 Service Generate Frame窗口,.h文件选择框默认填写被操作的.h文件的绝对路径;输出路径选择框默认填写.h文件所在文件夹路径,可修改为任意路径;serviceID范围是1-16777215之间的整数,超出范围会提示错误,填入正确的serviceID,然后点击ok。
7、 转换成功后,在输出路径下生成service框架代码文件。
service工具生成文件说明如下图所示:
其中消息调用流程为:
本集成说明针对的是OpenHarmony 3.2release系统,其他系统可能存在差别,开发者可自行调试修改。
修改testservice/BUILD.gn文件,将utils/native 改为 commonlibrary/c_utils,将samgr_standard改为samgr。修改后的BUILD.gn文件内容如下所示:
import("//build/ohos.gni")
ohos_shared_library("testservice") {
sources = [
"//testservice/src/i_test_service.cpp",
"//testservice/src/test_service_stub.cpp",
"//testservice/src/test_service.cpp"
]
include_dirs = [
"//testservice/include",
"//testservice/interface",
"//commonlibrary/c_utils/base/include"
]
deps = [
"//base/startup/syspara_lite/interfaces/innerkits/native/syspara:syspara",
"//commonlibrary/c_utils/base:utils",
]
external_deps = [
"hiviewdfx_hilog_native:libhilog",
"ipc:ipc_core",
"safwk:system_ability_fwk",
"samgr:samgr_proxy",
"startup_l2:syspara",
]
part_name = "testservice_part"
subsystem_name = "testservice"
}
ohos_executable("testclient") {
sources = [
"//testservice/src/i_test_service.cpp",
"//testservice/src/test_service_proxy.cpp",
"//testservice/src/test_client.cpp"
]
include_dirs = [
"//testservice/include",
"//testservice/interface",
"//commonlibrary/c_utils/base/include"
]
deps = [
"//commonlibrary/c_utils/base:utils",
]
external_deps = [
"hiviewdfx_hilog_native:libhilog",
"ipc:ipc_core",
"samgr:samgr_proxy",
]
part_name = "testservice_part"
subsystem_name = "testservice"
}
修改testservice/bundle.json文件,将"name": “@ohos/testservice"修改为 “name”: “@ohos/testservice_part”;将"samgr_standard"改为"samgr”,“utils_base"修改为"c_utils”;修改的bundle.json文件内容如下所示:
{
"name": "@ohos/testservice_part",
"description": "system ability framework test",
"homePage": "https://gitee.com/",
"version": "3.1",
"license": "Apache License 2.0",
"repository": "",
"publishAs": "code-segment",
"segment": {
"destPath": "testservice"
},
"dirs": {},
"scripts": {},
"component": {
"name": "testservice_part",
"subsystem": "testservice",
"adapted_system_type": [
"standard"
],
"rom": "2048KB",
"ram": "~4096KB",
"deps": {
"components": [
"hiviewdfx_hilog_native",
"ipc",
"samgr",
"c_utils",
"safwk",
"startup_l2"
],
"third_party": [ "libxml2" ]
},
"build": {
"sub_component": [
"//testservice:testservice",
"//testservice/sa_profile:testservice_sa_profile",
"//testservice:testclient",
"//testservice/etc:test_service_init"
],
"inner_kits": [
],
"test": [
]
}
}
}
服务配置
foundation/systemabilitymgr/samgr/interfaces/innerkits/samgr_proxy/include/system_ability_definition.h增加以下两行(ID说明: TEST_SERVICE_ID值与用户指定的ID一致;TEST_SERVICE_ID宏值定义必须为这个,因为代码中使用的就是这个)
TEST_SERVICE_ID = 9016,
{TEST_SERVICE_ID, "testservice" },
子系统配置
build/subsystem_config.json
增加以下内容
"testservice": {
"path":"testservice",
"name": "testservice"
}
产品配置,如rk3568
vendor/hihope/rk3568/config.json
增加以下内容
{
"subsystem": "testservice",
"components": [
{
"component": "testservice_part",
"features": []
}
]
}
注意:若用户需要配置selinux相关配置,则将开关改为true,再根据自身需求进行相关配置
testservice/etc/sample_service.cfg
"secon" : "u:r:testservice:s0"
base/security/selinux/sepolicy/base/public/service_contexts
9016 u:object_r:sa_testservice:s0
base/security/selinux/sepolicy/base/public/service.te
type sa_testservice, sa_service_attr;
test_service.cpp
在testservice/src/test_service.cpp注释“// TODO: Invoke the business implementation”处添加各个接口的服务端实现代码。本例实现一个简单的加减法,服务端代码如下所示:
int testService::testFunc(int v1, int v2, bool v3)
{
// TODO: Invoke the business implementation
int ret = 0;
printf("service test begin rn");
if (v3) {
printf("service test v3 = truern");
ret = v1 + v2;
} else {
printf("service test v3 = false rn");
ret = v1 - v2;
}
printf("service test end rn");
return ret;
}
远程方法的参数包装已在生成代码test_service_stub.cpp中统一处理,开发人员无需关注
test_client.cpp 为自动生成的客户端样例代码。编译烧录后,会在/system/bin/目录下生成可执行程序test_client
在testservice/src/test_client.cpp的mAIn函数中使用proxy对象进行远程方法调用,参考注释示例。本例实现一个简单的加减法,客户端代码如下所示:
int main(int argc, char *argv[])
{
printf("---functest begin---rn");
auto proxy = getRemoteProxy();
uint32_t result = 0;
// TODO: Invoke remote method by proxy
result = proxy->testFunc(8, 5, false);
printf("result is : %urn", result);
printf("---functest end---rn");
IPCSkeleton::JoinWorkThread();
return 0;
}
远程方法的参数包装已在生成代码test_service_proxy.cpp中统一处理,开发人员无需关注
编码完成后,执行镜像编译命令
./build.sh --product-name 产品名
若编译rk3568开发板,则执行
./build.sh --product-name rk3568
将编译好的镜像烧录到开发板后,使用hdc_std shell登录开发板。
查看服务端进程是否已正常启动
ps -ef | grep testservice
system 682 1 0 08:00:08 ? 00:00:00 testservice_sa --- 服务进程已正常运行
如下图所示:
运行客户端
/system/bin/testclient
运行结果如下所示:
---functest begin---
result is : 3
---functest end---
(客户端具体执行哪些远程调用方法请在test_client.cpp的main方法中实现)
service生成工具是一个开源项目,我们欢迎有兴趣的开发者试用该工具,并提出宝贵的改进意见,我们将继续不断优化和完善该工具软件。我们相信,该工具会成为OpenHarmony生态圈中一个有用的补充。