#夏日挑战赛#【FFH】OpenHarmony设备开发基础知识(一） 原创 精华

本文正在参加星光计划3.0–夏日挑战赛

OpenHarmony基础知识（一）

OpenHarmony技术架构

根据其技术架构图中各模块各的功能划分，我们需要初步判断自己开发的应用属于哪个子系统，再结合组件和目录的对应关系，判断出模块代码应该放在什么位置。

OpenHarmony的两个基本概念

• 子系统：为逻辑概念，由对应的组件构成，提供特定的服务能力
• 组件：是最基本的交付单元，是对子系统的进一步拆分，可复用的软件单元，包含源码、配置文件、资源文件和编译脚本。
  <br>

组件和模块配置

编译构建子系统提供了一个基于gn和ninja的编译构建框架。gn用于产生ninja文件，ninja为一个专注于速度的小型构建系统

后续发布的文章将会以实例具体解析编译过程，现在我们先来了解以下特殊组件，为今后的开发打下基础。
<br>

编译构建子系统

目录结构如下：

build/lite
├── components                  # 组件描述文件
├── figure                     # readme中的图片
├── hb                          # hb pip安装包源码
├── make_rootfs                 # 文件系统镜像制作脚本
├── config                      # 编译配置项
│   ├── component               # 组件相关的模板定义
│   ├── kernel                  # 内核相关的编译配置
│   └── subsystem               # 子系统编译配置
├── platform                    # ld脚本
├── testfwk                     # 测试编译框架
└── toolchain                   # 编译工具链配置，包括：编译器路径、编译选项、链接选项等

如下图中实例，build/lite/components目录下配置了诸如applications.json(应用子系统配置）、security.json(安全子系统配置）、communication.json(通信子系统配置）等众多子系统，每个子系统都有一个独立的json文件进行配置。

以sensor子系统的sensor服务组件为例，了解一下组件属性定义描述字段说明：

json文件中根节点为components，支持以数组形式配置多个组件信息，每个组件配置了组件名称、源码路径等属性定义，新增组件时需要在对应子系统json文件中添加相应的组件定义。
<br>相关规则：

1. 编译目标名称与组件一致。
2. 组件源码路径命名规则为：{领域}/{子系统}/{组件}
3. 组件对外可配置的特性变量需声明在该组件BUILD.gn中，特性变量命名规则：ohos_{subsystem}{component}{feature}。
4. 宏定义规则：OHOS_{SUBSYSTEM}{COMPONENT}{FEATURE}

芯片解决方案

芯片解决方案指基于某款开发板的完整解决方案，包含设备侧接口适配、HDF驱动和开发板SDK等。
其源码路径规则为：device/{芯片解决方案厂商}/{开发板}。如下图。

芯片解决方案在板级有一个BUILD.gn编译脚本，子目录下支持多个内核配置，支持相同的不同版本，也支持不同类型内核的配置。每个内核配置分别对应一个config.gni配置文件（例如下图中的hispark_taurus可选linux内核版本也可选liteos_a版本，其下都有对应的编译配置。）

7.29日补充

::: hljs-center

图源《OpenHarmony设备开发入门》

:::

config.gni是开发板编译相关的配置，编译时会采用该配置文件中的参数编译所有OS组件，编译阶段全局可见。
以device/board/hisilicon/hispark_taurus/liteos_a/config.gni为例，了解config.gni的关键字段：

# Kernel type, e.g. "linux", "liteos_a", "liteos_m".即开发板使用的内核类型
kernel_type = "liteos_a"

# Kernel version.内核版本
kernel_version = ""

# Board CPU type, e.g. "cortex-a7", "riscv32".开发板CPU类型
board_cpu = "cortex-a7"

# Board arch, e.g.  "armv7-a", "rv32imac".开发芯片arch
board_arch = ""

# Toolchain name used for system compiling.开发板自定义的编译工具链名称
# E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang,  riscv32-unknown-elf.
# Note: The default toolchain is "ohos-clang". 若为空，则使用默认"ohos-clang"。It's not mandatory if you use the default toolchain.
board_toolchain = ""

# The toolchain path installed, it's not mandatory if you have added toolchain path to your ~/.bashrc.
board_toolchain_path = ""

# Compiler prefix.编译工具链前缀，例如:"gcc-arm-none-eabi".
board_toolchain_prefix = ""

# Compiler type, "gcc" or "clang".编译工具链类型，目前支持gcc和clang.例如,"gcc","clang".
board_toolchain_type = "clang"

# Board related common compile flags.开发板配置的c文件编译选项
board_cflags = [
  "-mfloat-abi=softfp",
  "-mfpu=neon-vfpv4",
]
# 开发板配置的cpp文件编译选项。
board_cxx_flags = [
  "-mfloat-abi=softfp",
  "-mfpu=neon-vfpv4",
]
# 开发板配置的链接选项
board_ld_flags = []

# Board related headfiles search path.
board_include_dirs = []

# Board adapter dir for OHOS components.
board_adapter_dir = "//device/soc/hisilicon/common/hal"

# Sysroot path.
board_configed_sysroot = ""

# Board storage type, it used for file system generation.
storage_type = "emmc"

产品解决方案

产品解决方案为基于开发板的完整产品，主要包含产品对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基础
在书写本篇文章过程中，我梳理了设备开发和编译过程中要用到的一部分基本概念，对照源码仔细体会了一下。希望本篇笔记能帮助大家加深理解，为以后的开发工作打下良好的基础。更多的内容大家可以查阅上述链接。
作为小白，本篇文章可能有不对的地方，欢迎交流探讨~