OpenHarmony系統之Service代碼一鍵生成工具介紹（一）
前言
當開發者為OpenHarmony系統框架開發某些功能時，有時需要將這個功能包裝成一個獨立的服務進程運行在系統中，為了其它應用進程能夠調用此服務，開發人員需要基于系統IPC通信框架編寫一套遠程接口調用實現。實現Service遠程調用接口需要開發人員熟悉IPC通信框架，了解proxy/stub的繼承與實現方式，掌握C++類型轉為MessageParcel數據包的各種API方法，有一定的學習成本。而Service代碼生成工具能夠幫助使用者生成框架代碼，提升開發效率。用戶只需提供一個定義遠程方法的.h頭文件，工具會自動生成整個Service框架的代碼，包含Ability注冊、proxy/stub類實現、MessageParcel數據包構造、Service子系統編譯及開機自啟動相關配置文件。
1.工具原理
Service框架代碼生成工具包含工具入口、工具框架、公共模塊、運行環境、系統平臺。其中，工具入口描述調用Service框架代碼生成工具的入口方式，支持命令行調用、VS Code插件（即VS插件）調用，從而可以根據開發環境的不同，采用相對應的調用Service框架代碼生成工具的入口方式，實現Service框架代碼生成工具的入口多樣性，便于調用Service框架代碼生成工具。工具框架包含C語法解析器、代碼生成器兩部分，C語法解析器支持包括但不限于對class、function、properties、parameter等內容的解析，代碼生成器支持包括但不限于對proxy、stub、service、interface等服務框架代碼的生成。公共模塊描述通用的、在不同部分均會使用的公共接口與模塊，可以包括通用的正則校驗、類型映射、代碼模板、文件操作等模塊，運行環境描述Service框架代碼生成工具運行的環境，包括Nodejs與Python，由于Nodejs本身具有跨平臺性特點，故Service框架代碼生成工具可以在Windows、linux、mac、OpenHarmony等不同系統平臺靈活使用，Service框架代碼生成工具的運行環境另一部分是python，針對不同平臺做python適配，Service框架代碼生成工具即可實現跨平臺使用。
架構圖
2.使用說明
環境
visual studio code 版本需1.62.0及以上。
步驟
打開VS Code，在左側邊欄中選擇插件安裝。
在應用商店搜索service-gen插件，再單擊安裝。
安裝完成后就會在VS Code的插件管理器中能看到service-gen這個插件了。
在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右鍵單擊.h文件，選擇“ Service Generate Frame”選項。
工具打開 Service Generate Frame窗口，.h文件選擇框默認填寫被操作的.h文件的絕對路徑；輸出路徑選擇框默認填寫.h文件所在文件夾路徑，可修改為任意路徑；serviceID范圍是1-16777215之間的整數，超出范圍會提示錯誤，填入正確的serviceID，然后點擊ok。
轉換成功后，在輸出路徑下生成service框架代碼文件。
輸出文件說明
service工具生成文件說明如下圖所示：
其中消息調用流程為：
- 服務端實現SystemAbility接口OnStart()，將自己的serviceId注冊到SystemAbility Manager管理類。
- 客戶端根據serviceId向SystemAbility Manager管理類獲取該service的proxy對象。
- 客戶端使用proxy對象調用服務端的遠程接口。
- proxy將客戶端傳入的c++參數打包成消息數據，通過系統提供的dbinder進程間通信能力發送到服務端進程。
- 服務端OnRemoteRequest()接收到遠程調用消息，根據消息id分發給不同的innerFunction()處理。
- 服務端innerFunction()將遠程消息數據包還原成C/C++參數，傳入業務入口方法供業務開發人員處理。
3.集成說明
本集成說明針對的是OpenHarmony 3.2release系統，其他系統可能存在差別，開發者可自行調試修改。
修改編譯文件
修改testservice/BUILD.gn文件，將utils/native 改為 commonlibrary/c_utils，將samgr_standard改為samgr。修改后的BUILD.gn文件內容如下所示：
import("http://build/ohos.gni")
ohos_shared_library("testservice") {
sources = [
"http://testservice/src/i_test_service.cpp",
"http://testservice/src/test_service_stub.cpp",
"http://testservice/src/test_service.cpp"
]
include_dirs = [
"http://testservice/include",
"http://testservice/interface",
"http://commonlibrary/c_utils/base/include"
]
deps = [
"http://base/startup/syspara_lite/interfaces/innerkits/native/syspara:syspara",
"http://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 = [
"http://testservice/src/i_test_service.cpp",
"http://testservice/src/test_service_proxy.cpp",
"http://testservice/src/test_client.cpp"
]
include_dirs = [
"http://testservice/include",
"http://testservice/interface",
"http://commonlibrary/c_utils/base/include"
]
deps = [
"http://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": [
"http://testservice:testservice",
"http://testservice/sa_profile:testservice_sa_profile",
"http://testservice:testclient",
"http://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，再根據自身需求進行相關配置。
權限配置
在相應產品目錄下。
vendor/hihope/rk3568/security_config/high_privilege_process_list.json
增加以下內容。
{
"name": "testservice",
"uid": "system",
"gid": ["root", "system"]
}安全配置
testservice/etc/sample_service.cfg
"secon" : "u:r:testservice:s0"base/security/selinux/sepolicy/base/public/service_contexts
9016 u:object_r:sa_testservice:s0base/security/selinux/sepolicy/base/public/service.te
type sa_testservice, sa_service_attr;base/security/selinux/sepolicy/base/te/init.te
allow init testservice:process { getattr rlimitinh siginh transition };base/security/selinux/sepolicy/base/public/type.te
type testservice, sadomain, domain;/base/security/selinux/sepolicy/base/te目錄下增加新service的te文件，新增文件名即為服務名，例如：testservice
allow testservice init_param:file { map open read };
allow testservice sa_testservice:samgr_class { add get };示例演示
服務端修改
int testService::testFunc(int v1, int v2, bool v3)
{
// TODO: Invoke the business implementation
int ret = 0;
printf("service test begin \r\n");
if (v3) {
printf("service test v3 = true\r\n");
ret = v1 + v2;
} else {
printf("service test v3 = false \r\n");
ret = v1 - v2;
}
printf("service test end \r\n");
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---\r\n");
auto proxy = getRemoteProxy();
uint32_t result = 0;
// TODO: Invoke remote method by proxy
result = proxy->testFunc(8, 5, false);
printf("result is : %u\r\n", result);
printf("---functest end---\r\n");
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生態圈中一個有用的補充。
