OpenHarmony 临时学习记录

1. 系统架构

内核层

• 内核子系统：采用多内核（Linux内核或者LiteOS）设计，支持针对不同资源受限设备选用适合的OS内核。内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

• 驱动子系统：驱动框架（HDF）是系统硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。

系统服务层

• 系统基本能力子系统集：为分布式应用在多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、公共基础库、多模输入、图形、安全、AI等子系统组成。

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

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

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

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

框架层

• 框架层为应用开发提供了C/C++/JS等多语言的用户程序框架和Ability框架，适用于JS语言的ArkUI框架，以及各种软硬件服务对外开放的多语言框架API。根据系统的组件化裁剪程度，设备支持的API也会有所不同。

应用层

• 应用层包括系统应用和第三方非系统应用。应用由一个或多个FA（Feature Ability）或PA（Particle Ability）组成。其中，FA有UI界面，提供与用户交互的能力；而PA无UI界面，提供后台运行任务的能力以及统一的数据访问抽象。基于FA/PA开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验

技术特性 todo？ 需要去了解如何实现的

• 分布式软总线：分布式软总线是多设备终端的统一基座，为设备间的无缝互联提供了统一的分布式通信能力，能够快速发现并连接设备，高效地传输任务和数据。

• 分布式数据管理：分布式数据管理位于基于分布式软总线之上的能力，实现了应用程序数据和用户数据的分布式管理。用户数据不再与单一物理设备绑定，业务逻辑与数据存储分离，应用跨设备运行时数据无缝衔接，为打造一致、流畅的用户体验创造了基础条件

• 分布式任务调度：分布式任务调度基于分布式软总线、分布式数据管理、分布式Profile等技术特性，构建统一的分布式服务管理（发现、同步、注册、调用）机制，支持对跨设备的应用进行远程启动、远程调用、绑定/解绑、以及迁移等操作，能够根据不同设备的能力、位置、业务运行状态、资源使用情况并结合用户的习惯和意图，选择最合适的设备运行分布式任务

• 设备虚拟化：分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理，将周边设备作为手机能力的延伸，共同形成一个超级虚拟终端。

2. 各个子系统模块

3. 支持开发板

• http://ci.openharmony.cn/developBoard/list
• 轻量系统（mini system），面向MCU类处理器（例如Arm Cortex-M、RISC-V 32位）的轻量设备，硬件资源极其有限，支持的设备最小内存为128KiB
• 小型系统（small system），面向应用处理器（例如Arm Cortex-A 64位）的设备，支持的设备最小内存为1MiB
• 标准系统（standard system），面向应用处理器（例如Arm Cortex-A 64位）的设备，支持的设备最小内存为128MiB

4. 代码目录结构

• 组件(可独立部署、二进制复用) > 部件(可独立开发、编译和测试) > 模块(代码级复用)

.1. 部件目录结构

• <领域>/<子系统>/<部件>， 例如：foundation/filemanagement/storage_service

├── interfaces          # 接口
│   ├── kits			# 应用接口，可选
│   │    ├── js			# JS接口，可选
│   │    └── native  	# C/C++接口，可选
│   └── inner_api       # 系统内部件间接口
├── frameworks          # 部件无独立进程的实现，可选
│   ├── native          # C/C++实现，可选
│   └── js              # JS API的实现，可选
│        ├── napi       # napi代码实现，可选
│        ├── builtin	# 仅用于LiteOS-M，可选
│        └── plugin     # Ark UI特有，可选
├── services            # 独立进程的实现，可选
├── test                # 测试代码，必选
├── BUILD.gn            # 编译入口，必选
└── bundle.json         # 部件描述文件，必选

.2. API类型

• Public API：OpenHarmony对所有应用开发者公开的API。
• Test API：测试专用的API，仅在测试阶段使用。
• System API：提供给系统特权应用使用的API，普通应用无法使用。
• HDI：描述硬件能力的接口。
• Driver API：提供给驱动开发者使用的接口。
• Inner API：系统服务和框架实现彼此调用的API，仅供系统内部使用，不承诺兼容性。

• application-dev
• device-dev
• readme
• 64bits-coding-guide
• java-secure-coding-guide
• cpp-coding-guide
• c-coding-guide

Resource

• Samples：示例代码
• Codelabs：教程指导
• 获取OpenHarmony源码：下载说明
• 设备开发快速入门
• 应用开发快速入门