#夏日挑战赛#【FFH】OpenHarmony设备开发基础知识(一) 原创 精华
OpenHarmony基础知识(一)
OpenHarmony技术架构
根据其技术架构图中各模块各的功能划分,我们需要初步判断自己开发的应用属于哪个子系统,再结合组件和目录的对应关系,判断出模块代码应该放在什么位置。
OpenHarmony的两个基本概念
- 子系统:为逻辑概念,由对应的组件构成,提供特定的服务能力
- 组件:是最基本的交付单元,是对子系统的进一步拆分,可复用的软件单元,包含源码、配置文件、资源文件和编译脚本。
组件和模块配置
编译构建子系统提供了一个基于gn和ninja的编译构建框架。gn用于产生ninja文件,ninja为一个专注于速度的小型构建系统
后续发布的文章将会以实例具体解析编译过程,现在我们先来了解以下特殊组件,为今后的开发打下基础。
编译构建子系统
目录结构如下:
如下图中实例,build/lite/components目录下配置了诸如applications.json(应用子系统配置)、security.json(安全子系统配置)、communication.json(通信子系统配置)等众多子系统,每个子系统都有一个独立的json文件进行配置。
以sensor子系统的sensor服务组件为例,了解一下组件属性定义描述字段说明:
json文件中根节点为components,支持以数组形式配置多个组件信息,每个组件配置了组件名称、源码路径等属性定义,新增组件时需要在对应子系统json文件中添加相应的组件定义。
相关规则:
- 编译目标名称与组件一致。
- 组件源码路径命名规则为:{领域}/{子系统}/{组件}
- 组件对外可配置的特性变量需声明在该组件BUILD.gn中,特性变量命名规则:ohos_{subsystem}{component}{feature}。
- 宏定义规则:OHOS_{SUBSYSTEM}{COMPONENT}{FEATURE}
芯片解决方案
芯片解决方案指基于某款开发板的完整解决方案,包含设备侧接口适配、HDF驱动和开发板SDK等。
其源码路径规则为:device/{芯片解决方案厂商}/{开发板}。如下图。
芯片解决方案在板级有一个BUILD.gn编译脚本,子目录下支持多个内核配置,支持相同的不同版本,也支持不同类型内核的配置。每个内核配置分别对应一个config.gni配置文件(例如下图中的hispark_taurus可选linux内核版本也可选liteos_a版本,其下都有对应的编译配置。)
7.29日补充
图源《OpenHarmony设备开发入门》
config.gni是开发板编译相关的配置,编译时会采用该配置文件中的参数编译所有OS组件,编译阶段全局可见。
以device/board/hisilicon/hispark_taurus/liteos_a/config.gni为例,了解config.gni的关键字段:
产品解决方案
产品解决方案为基于开发板的完整产品,主要包含产品对OS的适配,组件拼装配置、启动配置、文件系统配置和产品信息配置等。
源码路径规则为:
vendor/{产品解决方案厂商}/{产品名称}。
其目录树规则如下:
例如:
其中最重要的要属config.json和BUILD.gn
-
vendor/company/product/config.json文件为编译构建的主入口,包含了开发板、OS组件和内核等配置信息。
-
vendor/company/product/BUILD.gn为产品编译的入口,主要用于编译解决方案厂商源码和拷贝启动配置文件。若某个产品被选择为要编译的产品,那么对应产品目录下的BUILD.gn为被默认编译。
总结
- 组件是最小可独立交付的模块、代码、资源等,并且通过逻辑概念子系统进行管理和配置。
- 芯片解决方案是一个特殊的组件,需要通过芯片厂商、开发板名称等信息确定组件位置,并根据内核类型和版本找到开发板编译相关配置。
- 产品解决方案则是根据产品需要呈现给用户的功能组合。config.json中根据功能需要配置子系统和组件依赖,构建时根据组件间的依赖关系进行编译。BUILD.gn会默认编译,一般情况下只需要配置一个group即可。group名称和三级目录product名称保持一致。如果产品比较特殊,有更多的依赖和配置项,可在group中增加。
后记
参考文献及教程:
OpenHarmony设备开发文档
OpenHarmony基础
在书写本篇文章过程中,我梳理了设备开发和编译过程中要用到的一部分基本概念,对照源码仔细体会了一下。希望本篇笔记能帮助大家加深理解,为以后的开发工作打下良好的基础。更多的内容大家可以查阅上述链接。
作为小白,本篇文章可能有不对的地方,欢迎交流探讨~
写得很详细了,辛苦整理
鸿蒙开发这么复杂的啊😱
写的真不错