请探讨一下鸿蒙下的Server为啥都lib库,而不是进程? 原创
请探讨一下,鸿蒙下的Server为啥都是lib库,而不是进程,那他如何解决
多进程访问,多进程资源互斥的问题呢?
尽管代码中使用ipc 多进程通讯机制,但他本身就是一个so,没有进程概念,
有ipc又如何起作用呢?那他属于哪个进程呢?
举例:
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”,
]
configs = [
“${utils_path}:utils_config”,
“:batterysrv_private_config”,
]
public_configs = [ “:batterysrv_public_config” ]
deps = [
“${aafwk_services_path}/appmgr:libappms”,
“${battery_manager_path}/interfaces/innerkits:batterysrv_client”,
“${displaymgr_native_innerkits_path}:displaymgr”,
“//base/hiviewdfx/hisysevent/interfaces/native/innerkits/hisysevent_manager:libhisyseventmanager”,
“//base/powermgr/battery_manager/frameworks/dialog/dialog_ui/js:dialog_js_files_etc”,
“//base/powermgr/power_manager/interfaces/innerkits:powermgr_client”,
“//base/powermgr/power_manager/utils/permission:power_permission”,
“//drivers/peripheral/battery/interfaces/hdi_service:libbattery_interface_service_1.0”,
“//foundation/arkui/ace_engine/interfaces/inner_api/ui_service_manager:ui_service_mgr”,
“//foundation/windowmanager/utils:libwmutil”,
“//utils/native/base:utils”,
]
external_deps = [
“ability_base:base”,
“ability_base:want”,
“bundle_framework:appexecfwk_base”,
“common_event_service:cesfwk_core”,
“common_event_service:cesfwk_innerkits”,
“drivers_interface_battery:libbattery_proxy_1.0”,
“eventhandler:libeventhandler”,
“hdf_core:libhdf_utils”,
“hdf_core:libhdi”,
“hicollie_native:libhicollie”,
“hisysevent_native:libhisysevent”,
“hiviewdfx_hilog_native:libhilog”,
“ipc:ipc_core”,
“multimedia_image_standard:image_native”,
“safwk:system_ability_fwk”,
“samgr_standard:samgr_proxy”,
“window_manager:libdm”,
]
part_name = “battery_manager_native”
}
猜想是C++中的static stance 语法机制?
void BatteryService::RegisterBatteryHdiCallback()
{
BATTERY_HILOGD(COMP_SVC, “register battery hdi callback”);
if (iBatteryInterface_ == nullptr) {
iBatteryInterface_ = IBatteryInterface::Get();
RETURN_IF_WITH_LOG(iBatteryInterface_ == nullptr, “failed to get battery hdi interface”);
}
sptr<IBatteryCallback> callback = new BatteryCallback();
ErrCode ret = iBatteryInterface_->Register(callback);
class BatteryService final : public SystemAbility,
public BatterySrvStub {
DECLARE_SYSTEM_ABILITY(BatteryService)
DECLARE_DELAYED_SP_SINGLETON(BatteryService);
请问哪位大神知道这其中的原委,谢谢
鸿蒙下的Server,可以以独立进程的形式提供服务,也可以以动态库的形式依附在某个进程内(如 foundation进程),通过这个进程对外提供服务。
前者可以参考//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所能提供的服务。
无论系统能力以哪种方式对外提供服务,只要使用了别的进程提供的服务,就都需要进行IPC,上述例子的后者,IPC由宿主进程foundation来实现。
非常感谢,
sa_profile/3302.xml 这里面有个 数字,就是后面会转化为一个 XX_ID的 Server ID
号一样的东西,对吗?
另外 系统启动阶段会 启动一个 进程“battery_stats”,这个 代码具体在哪, 是一个关联
库名字lib而 创建的 进程(fork),还是?如果说启动, 那之前如何配置 进程的权限呢,
需要 访问的资源等等,当然创建也一样有这个问题,请帮忙指导下。
这里是 跟 sa_profile 这个相关,这个概念和介绍在 官网那个网址,请帮忙指导下;
“系统启动阶段会 启动一个 进程“battery_stats”,这个 代码具体在哪”
可以查看 //base/powermgr/battery_statistics/sa_profile/3304.xml:
//base/powermgr/battery_statistics/services/BUILD.gn:
ohos_shared_library("batterystats_service")
编译目标里面就包含具体的代码实现。
“如果说启动, 那之前如何配置 进程的权限呢,需要 访问的资源等等,当然创建也一样有这个问题”
实际上,在 //base/powermgr/battery_statistics/etc/init/batterystats.cfg
这个.cfg文件,编译阶段会拷贝到 /system/etc/init/batterystats.cfg,系统启动到 post-init 阶段时,会去读取这个.cfg文件,启动这个 battery_stats 服务,通过运行 "path" : ["/system/bin/sa_main", "/system/profile/battery_stats.xml"] 来启动 battery_stats 服务,也就是init进程先 fork()一个子进程出来,去运行 sa_main 可执行程序,在 sa_main 中分析参数指定的 battery_stats.xml 配置文件,根据其中的配置去加载battery_stats.xml中描述的 libbatterystats_service.z.so, 并运行其中的代码,由此完成battery_stats 进程的启动。
详细过程请参考一下:
标准系统的进程拉起方式简介-开源基础软件社区-51CTO.COM
感谢,解释非常清晰,
我之前理解 有进程的地方一定 会有 etc/init 配置脚本,看来这个
逻辑是正确的,否则不是进程,只是一个lib so而已。
鸿蒙这样设计的目的和初衷是为了啥呢,
是出于什么考虑,这样干,如果so没有写好,考虑到进程互斥,里面现在
有一些全局变量的定义等,是为了 调用性能,还是?
应该不是 任何so可以通过sa_main加载成进程