OpenHarmony 源码解析之DFX子系统-Hiview(上) 原创 精华
作者:吴文璐
1 简介
DFX(Design for X)子系统是为了提升软件质量设计的工具集,目前包含的内容主要有:DFR(Design for Reliability,可靠性)和DFT(Design for Testability,可测试性)特性。
已实现以下功能:
- HiLog:流水日志。
- HiSysEvent:系统事件记录接口。
- HiView:插件平台。
- FaultLoggerd:应用故障订阅和收集。
- HiAppEvent: js应用事件记录接口。
1.1 OpenHarmony架构图
1.2 Hiview简介
Hiview是一个跨平台的终端设备维测服务集。目前开源部分仅包含插件管理平台和系统事件源。
Hiview架构图如下:
Hiview由框架和插件组成,分别为:
- 操作系统适配层(adapter),对使用的系统服务的接口进行适配。
- Hiview基础定义(hiview base),包括插件基类、管道的定义,事件、事件队列定义以及一些工具类。
- Hiview的核心模块(hiview core),包括插件配置,插件管理以及事件源。
- Hiview服务(hiview services),目前仅包括hiview运行信息dump功能。
- Hiview插件(plugins),为独立功能的业务模块。
Hiview维测服务是由事件驱动的,其核心为分布在系统各处的HiSysEvent桩点。
格式化的事件通过HiSysEvent API上报至hiview进行处理,如下图:
- 应用框架、系统服务使用HiSysEvent组件上报系统事件。
- Hiview中SysEventSource获取消息,解析并组装成管道事件分发给插件处理。
1.3 Hiview代码目录
2 源码分析
本文主要分析hiview插件管理平台的初始化,和事件处理流程。
hiview是个常驻服务,在开机阶段启动。
base/hiviewdfx/hiview/service/config/hiview.cfg定义如下
2.1 初始化
hiview的入口函数定义在base/hiviewdfx/hiview/main.cpp中
HiviewPlatform::InitEnvironment()函数实现如下:
注[1]处PluginConfig::StartParse()函数会按照特定规则去解析插件配置文件:
目前使用的插件配置文件/system/etc/hiview/plugin_config内容如下:
- 注:base/hiviewdfx/hiview/plugins 下有eventlogger eventservice faultlogger freeze_detector hicollie_collector五个插件目录,而目前插件配置文件里实际只用到了Faultlogger和SysEventService。
PluginConfig::StartParse()解析完之后会把相关信息保存到列表中。类图如下:
PluginConfig::ParsePipelineGroup()代码如下
说明:
- 在解析pipelinegroups时,如果发现pipelineGroupName和pluginInfoList中某个插件的name一致,则把该插件PluginInfo.isEventSource置为true并且把pipelineNameList赋值给PluginInfo.pipelineNameList。
- 结合/system/etc/hiview/plugin_config配置文件,可以看到SysEventSource插件是带管道(SysEventPipeline)的,插件SysEventService和Faultlogger隶属于管道SysEventPipeline,用于处理SysEventSource扔给管道的事件。
解析完插件配置信息之后会调用HiviewPlatform::LoadBusinessPlugin(const PluginConfig& config)去装载插件和管道。
代码如下
说明:
注[1]InitPlugin()这一步中,如果插件的workHandlerType为thread,则绑定工作线程EventLoop。如果插件是EventSource类型,则绑定管道Pipeline,并且调用StartEventSource开启消息监听。代码如下:
至此,插件管理平台初始化工作已完成。
2.2 事件处理流程
结合插件配置文件,目前实际使用的插件类图如下:
说明:
- 前文最后的代码段提到,如果插件是EventSource类型,则绑定管道,并且调用StartEventSource开启消息监听。结合类图,只有SysEventSource是EventSource类型的插件,所以只有SysEventSource持有管道。
- EventSource类型的插件会监听HiSysEvent接口发来的消息,解析并组装成管道事件,分发给管道中的插件处理。
SysEventSource::StartEventSource()函数实现如下。
SysEventSource有个成员变量eventServer,EventServer会开启socketserver端用于接收HiSysEvent接口发来的socket消息。
类图如下:
说明:
- 1.SysEventSource::StartEventSource()中把SysEventReceiver对象加入到EventServer的receivers_容器中。
- 2.EventServer收到socket消息之后,调用SysEventReceiver::HandlerEvent(const std::string& rawMsg)方法处理接收到的消息。
- 3.SysEventReceiver::HandlerEvent()方法中会调用SysEventParser::Parser(const std::string& rawMsg)方法解析消息并组装成SysEvent对象,然后调用EventSource::PublishPipelineEvent(std::shared_ptr<PipelineEvent> event)方法把管道事件发布出去。
EventSource::PublishPipelineEvent()代码如下:
结合上面的类图,EventSource持有管道列表对象listeners_,EventSource::PublishPipelineEvent()函数中会遍历该列表,调用Pipeline::ProcessEvent(std::shared_ptr<PipelineEvent> event)函数去处理管道事件。(Pipeline对象是在HiviewPlatform::InitPlugin()函数中被加入到EventSource.listeners_中的。)
Pipeline类型有个成员变量std::list<std::weak_ptr<Plugin>> processors_,
在插件平台初始化的时候,HiviewPlatform::CreatePipeline()函数中已经把Plugin插件对象加入到了processors_列表中。
接下来分析Pipeline::ProcessEvent()函数做了什么。
把Pipeline的processors_对象赋给了PipelineEvent的processors_对象,然后调用
PipelineEvent::OnContinue()函数。
接下来分析PipelineEvent::OnContinue()函数:
不管插件是否使用了事件队列,最终都会调用到Plugin::OnEventProxy()函数来处理管道事件。
Plugin::OnEventProxy()函数实现如下:
先调用注[1]OnEvent()函数处理事件,再判断管道事件传递是否已结束,如未结束则调用注[2]PipelineEvent::OnContinue()函数继续把管道事件传递给后面的
插件处理。
结合目前的插件配置文件,整个插件管理平台的消息处理流程大致如下:
EventServer接收到HiSysEvent组件接口发来的消息 --> SysEventReceiver::HandlerEvent() --> SysEventParser::Parser() --> EventSource::PublishPipelineEvent() --> Pipeline::ProcessEvent() --> PipelineEvent::OnContinue() --> SysEventService::OnEventProxy --> SysEventService::OnEvent --> PipelineEvent::OnContinue() --> Faultlogger::OnEventProxy --> Faultlogger::OnEvent --> 结束
至此,事件处理流程已分析完。
3 总结
以上内容首先分析了hiview插件管理平台的初始化,然后对事件的处理流程做了分析。后续会详细讲解base/hiviewdfx/hiview/plugins目录下每个插件的源码。
更多原创内容请关注:深开鸿技术团队
入门到精通、技巧到案例,系统化分享HarmonyOS开发技术,欢迎投稿和订阅,让我们一起携手前行共建鸿蒙生态。
跟着大佬把OpenHarmony吃透
带我一个,带我一个!嘿嘿