OpenHarmony 服务编译成动态库,而不是进程，问题详解_openharmony sa_main

目录

一、问题背景

二、 具体的代码和Server

2.1 Server定义

2.2 main入口：sa_main

2.3 sa_main如何加载 libbatteryservice.z.so

三.官方解释

safwk组件

四、最后思考问题：

---

一、问题背景

OpenHarmony 很多服务都是编译成动态库, 动态库服务，没有main函数入口。服务的拉起的入口在哪?  一直有这样的疑问，理论上和原则上，服务进程必须有main，同时在linux下需要配置对应的init配置脚本等。

 带着这一系统问题，通过问和学习，终于从问题找到了答案。

鸿蒙下的Server，可以以独立进程的形式提供服务，也可以以动态库的形式依附在某个进程内（如 foundation进程），通过这个进程对外提供服务。

二、 具体的代码和Server

2.1 Server定义

ohos_shared_library(“batteryservice”) {
sources = [
“${battery_manager_path}/services/zidl/src/battery_srv_stub.cpp”,
“native/src/battery_callback.cpp”,
“native/src/battery_dump.cpp”,
“native/src/battery_service.cpp”,
“native/src/battery_service_event_handler.cpp”,
“native/src/battery_service_subscriber.cpp”,
]

 ---当然并不是所有的server都是可以转成进程的，是需要对应的配置的。

比如这个例子就不行。需要另外一个，基本的判断是看有没有etc/init，但是没有main

前者可以参考//base/powermgr/battery_statistics/，这里的sa_profile/3304.xml会被拷贝到：/system/profile/battery_stats.xml，系统启动阶段会通过这个profile启动一个独立的进程“battery_stats”，对外提供服务。

后者如你所举的例子//base/powermgr/battery_manager/，它的sa_profile/3302.xml会被拷贝到：/system/profile/foundation.xml，作为foundation进程的一个特性而存在，系统启动阶段会通过这个foundation.xml启动一个独立的进程“foundation”进程，通过foundation进程对外提供libbatteryservice所能提供的服务。

可以查看 //base/powermgr/battery_statistics/sa_profile/3304.xml：

<info>
    <process>battery_stats</process>
    <systemability>
        <name>3304</name>
        <libpath>libbatterystats_service.z.so</libpath>
        <run-on-create>true</run-on-create>
        <distributed>false</distributed>
        <dump-level>1</dump-level>
    </systemability>
</info>

复制

//base/powermgr/battery_statistics/services/BUILD.gn:

2.2 main入口：sa_main

sa_main是含有main入口的独立可执行文件。学习者可以自己在代码中去看：

配置路径：foundation\distributedschedule\safwk\services\safwk\BUILD.gn

2.3 sa_main如何加载 libbatteryservice.z.so

updater_sa.xml配置了动态库libbatteryservice.z.so的各项信息。

sa_main通过读取解析updater_sa.xml, 把动态库libbatteryservice.z.so加载到自身进程中来。

即运行命令：system/bin/sa_main", "/system/profile/battery_stats.xml"

是XXX_SERVICE_ID的值，该值定义在

utils\system\safwk\native\include\system_ability_definition.h中。

可以查看 //base/powermgr/battery_statistics/sa_profile/3304.xml：

<info>
    <process>battery_stats</process>
    <systemability>
        <name>3304</name>
        <libpath>libbatterystats_service.z.so</libpath>
        <run-on-create>true</run-on-create>
        <distributed>false</distributed>
        <dump-level>1</dump-level>
    </systemability>
</info>

复制

//base/powermgr/battery_statistics/services/BUILD.gn:

powermgr_battery_statistics/ bundle.json ----鸿蒙3.2开始都换成这个新的编译方式

"build": {

"sub_component": [

"//base/powermgr/battery_statistics/etc/init:batterystats.rc",

"//base/powermgr/battery_statistics/frameworks/js/napi:batterystatistics",

"//base/powermgr/battery_statistics/interfaces/innerkits:batterystats_client",

"//base/powermgr/battery_statistics/sa_profile:batterystats_sa_profile",

"//base/powermgr/battery_statistics/services:batterystats_service",

"//base/powermgr/battery_statistics/services/profile:power_average.json",

"//base/powermgr/battery_statistics/utils:batterystat_dump"

],

三.官方解释

distributedschedule_safwk: System ability framework | 系统服务框架定义

safwk组件

在系统服务管理子系统中safwk组件定义OpenHarmony中SystemAbility的实现方法，并提供启动、注册等接口实现。

SystemAbility实现一般采用XXX.cfg + profile.xml + libXXX.z.so的方式由init进程执行对应的XXX.cfg文件拉起相关SystemAbility进程。

C++实现SystemAbility

REGISTER_SYSTEM_ABILITY_BY_ID(ListenAbility, DISTRIBUTED_SCHED_TEST_LISTEN_ID, true);

•  SystemAbility配置

以c++实现的SA必须配置相关System Ability的profile配置文件才会完成SA的加载注册逻辑，否则没有编写profile配置的System Ability不会完成注册。配置方法如下：

在子系统的根目录新建一个以sa_profile为名的文件夹，然后在此文件夹中新建两个文件：一个以serviceId为前缀的xml文件，另外一个为BUILD.gn文件。

serviceid.xml：

<?xml version="1.0" encoding="UTF-8"?>
<info>
    <process>listen_test</process>
    <systemability>
    <name>serviceid</name>
    <libpath>/system/lib64/liblistentest.z.so</libpath>
    <run-on-create>true</run-on-create>
    <distributed>false</distributed>
    <dump-level>1</dump-level>
</systemability>
</info>

1. 进程名字即该SystemAbility要运行的进程空间，此字段是必填选项。
2. 一个SystemAbility配置文件只能配置一个SystemAbility节点，配置多个会导致编译失败。
3. SystemAbility的name为对应的serviceId必须与代码中注册的serviceId保持一致，必配项。
4. libpath为SystemAbility的加载路径，必配项。
5. run-on-create：true表示进程启动后即向samgr组件注册该SystemAbility；false表示按需启动，即在其他模块访问到该SystemAbility时启动，必配项。
6. distributed：true表示该SystemAbility为分布式SystemAbility，支持跨设备访问；false表示只有本地跨IPC访问。
7. bootphase：可不设置；可以设置的值有三种：BootStartPhase、CoreStartPhase、OtherStartPhase（默认类型），三种优先级依次降低，当同一个进程中，会优先拉起注册配置BootStartPhase的SystemAbility，然后是配置了CoreStartPhase的SystemAbility，最后是OtherStartPhase；当高优先级的SystemAbility全部启动注册完毕才会启动下一级的SystemAbility的注册启动。
8. dump-level：表示systemdumper支持的level等级，默认配置1。
9. BUILD.gn中subsystem_name为相应部件名称；sources表示当前子系统需要配置的SystemAbility列表，可支持配置多个SystemAbility

四、最后思考问题：

鸿蒙这样设计目的？

如何做到进程的互斥？