OpenHarmony5.0版本系统架构[有一二级目录源码概览]

问题:看到openharmony总感觉大而全，且迷雾缭绕的，可能是由于没有安卓的经验(一直是工业类应用)，所以对很多的组件(子系统)一直不清楚具体的关系，例如app怎么写？用什么语言呢？必须用js吗？它是如何同时适配mcu和SOC的？

目的:梳理系统架构，从硬件、内核、组件、应用框架以及应用层整体过一遍，不会详尽，但尽可能把各个层之间的关系以及对应的接口能搞清楚。

其系统框架具有分层设计的特点，从下至上依次为内核层、系统服务层、框架层和应用层。以下是对各层的详细介绍：

一、整体框架概述

内核层

• 内核子系统：采用多内核（Linux内核或者LiteOS）设计，支持针对不同资源受限设备选用适合的OS内核。Linux内核适用于标准系统，提供全面的功能和性能；LiteOS则更适用于嵌入式设备及资源受限设备，具有小体积、高性能、低功耗等特征。内核抽象层（KAL）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

• 驱动子系统：驱动框架（HDF）是系统硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。它采用C面向对象编程模型构建，通过平台解耦、内核解耦，兼容不同内核，提供了归一化的驱动平台底座，旨在为开发者提供更精准、更高效的开发环境。

系统服务层

系统服务层是OpenHarmony的核心能力集合，通过框架层对应用程序提供服务。该层包含以下几个部分：

• 系统基本能力子系统集：为分布式应用在多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、公共基础库、多模输入、图形、安全、AI等子系统组成。其中，分布式软总线是系统的核心通信基础设施，支持多种通信协议和数据格式，实现了设备间的无缝连接和协同工作。分布式数据管理则提供了统一的数据管理框架，能够对分布式环境下的数据进行有效的组织、存储和访问。

• 基础软件服务子系统集：提供公共的、通用的软件服务，由事件通知、电话、多媒体、DFX（Design For X）等子系统组成。

• 增强软件服务子系统集：提供针对不同设备的、差异化的能力增强型软件服务，由智慧屏专有业务、穿戴专有业务、IoT专有业务等子系统组成。

• 硬件服务子系统集：提供硬件服务，由位置服务、用户IAM、穿戴专有硬件服务、IoT专有硬件服务等子系统组成。

根据不同设备形态的部署环境，基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪，每个子系统内部又可以按功能粒度裁剪。

框架层

框架层为应用开发提供了C/C++/JS等多语言的用户程序框架和Ability框架，适用于JS语言的ArkUI框架，以及各种软硬件服务对外开放的多语言框架API。这些框架和API使得开发者能够更方便地进行应用开发，同时保证了应用在不同设备上的运行兼容性。

应用层

应用层包括系统应用和第三方非系统应用。应用由一个或多个FA（Feature Ability）或PA（Particle Ability）组成。OpenHarmony提供统一的开发工具和框架，支持一次开发、多端部署的开发模式。开发者可以基于同一套代码，快速地将应用部署到不同类型的设备上，无需针对每个设备进行单独的开发和适配。

总的来说，OpenHarmony的系统框架具有高度的灵活性和可扩展性，能够根据不同设备的资源状况和功能需求进行裁剪和扩展。同时，其分层设计也使得各层之间职责明确、相互协作，有利于快速响应不同应用场景和硬件平台的需求。

下图是借用的一个图，可以参考：

• KAL（Kernel Abstract Layer，内核抽象层），为上层提供统一的内核抽象接口

• HAL（Hardware Abstract Layer，硬件抽象层），为上层提供统一的硬件抽象接口

• HDI（Hardware Driver Interface，硬件驱动接口），通过规范化的设备接口标准，为系统提供统一、稳定的硬件设备操作接口。

• HDF（Hardware Driver Foundation，硬件驱动框架），提供统一的硬件资源管理、驱动加载管理、设备节点管理、设备电源管理以及驱动服务模型等功能，需要包含设备管理、服务管理、DeviceHost、PnPManager等模块。

• OSAL（Operating System Abstract Layer，操作系统抽象层），为 HDF 提供统一的内核抽象接口,提供统一封装的内核操作相关接口，屏蔽不同系统操作差异，包含内存、锁、线程、信号量等接口。

通过《OpenHarmony-hdf-coding-guide.md》可知hdf为整体框架，包含了驱动加载、驱动服务管理和驱动消息机制，同时还提供了操作系统抽象层(OSAL, Operating System Abstraction Layer)和平台抽象层(PAL, Platform Abstraction Layer)来保证驱动程序的跨系统跨平台部署的特性。除此之外，HDF提供了驱动模型的抽象、公共工具、外围器件框架等能力。开发者应该基于HDF提供的这些能力开发驱动，从而保证驱动程序可以在各种形态的OpenHarmony上进行部署。

详细分析了一下各个层，但整理起来太耗时间，篇幅也过大，有时间就先一部分一部分的发出来吧。否则大概率夭折。。。

一二级目录源码概述

下面是梳理的开源鸿蒙系统(5.0版本)的源码，主要是一二级目录可了解大概都包含哪些东西(体力活~~~)。备注方式是优先参考的源码中的说明文档，有一些不太了解，也只是按自己的理解写的，仅供参考吧。

• 一级目录

├── applications # 示例应用程序
├── arkcompiler #方舟子系统
├── base #基础的应用服务
├── build # 构建编译相关
├── build.py -> build/build_scripts/build.py # 超链接，方便在根目录应用
├── build.sh -> build/build_scripts/build.sh # 超链接，方便在根目录应用
├── commonlibrary # 常用库包括c_utils、ets_utils、memory_utils等
├── developtools # 一些常用的开发工具
├── device #设备适配
├── docs #说明文档
├── domains # 领域包含广告服务框架、开放匿名设备标识符
├── drivers #驱动相关的核心部件包含hdf等
├── foundation #一些应用框架和功能组件
├── ide # IDE相关
├── interface #操作系统提供给应用使用接口包含c语言、JS
├── kernel # 操作系统包含linux、liteos_a、liteos_m等
├── napi_generator #一些提升开发效率的NAPI框架代码生成工具！
├── out #默认编译输出的目录
├── prebuilts #存放了一些交叉编译工具链包含如下:
├── productdefine #定义与芯片无关的通用系统组件形态配置
├── qemu-run -> vendor/ohemu/common/qemu-run # 模拟器
├── test #测试相关的部件
├── third_party #第三方库
└── vendor #存放与厂商相关的配置和组件。这些配置和组件可能包括但不限于硬件抽象层（HAL）的实现、设备驱动、厂商特定的应用程序或库等。通过将这些内容放置在vendor目录中，OpenHarmony系统能够实现对不同厂商硬件和软件的灵活支持。</