HCIA-HarmonyOS设备开发认证V2.0-1.OpenHarmony介绍

置顶攻下一城

已于 2024-01-31 20:42:43 修改

阅读量952

点赞数 7

分类专栏： HCIA-HarmonyOS设备开发认证V2.0 文章标签： harmonyos 华为 OpenHarmony

于 2024-01-21 06:30:17 首次发布

本文链接：https://blog.csdn.net/navydianzi/article/details/135716266

版权

HCIA-HarmonyOS设备开发认证V2.0 专栏收录该内容

26 篇文章 3 订阅

订阅专栏

本文介绍了OpenHarmony，一个面向全场景的开源操作系统，重点讨论了其设计理念、技术架构、部件化设计以及关键技术特性，如统一OS、弹性部署、一次开发和硬件互助等，旨在促进万物互联的发展和多设备生态融合。

摘要由CSDN通过智能技术生成

在这里插入图片描述

一、OpenHarmony 简介

OpenHarmony 是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目。目标是面向全场景、全连接、全智能时代，基于开源的方式，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。
OpenHarmony 支持如下几种系统类型：
- 轻量系统（mini system）：面向mcu类处理器，例如Arm Cortex-M、RISC-V 32位的设备，硬件资源极其有限，支持的设备最小内存为 128KiB，可以提供多种轻量级网络协议，轻量级的图形框架，以及丰富的 IoT 总线读写部件等。可支撑的产品如智能家居领域的连接类模组、传感器设备、穿戴类设备等。
- 小型系统（small system）：面向应用处理器例如 Arm Cortex-A 的设备，支持的设备最小内存为 1MiB，可以提供更高的安全能力、标准的图形框架、视频编解码的多媒体能力。可支撑的产品如智能家居领域的 IP Camera、电子猫眼、路由器以及智慧出行域的行车记录仪等。
- 标准系统（standard system）：面向应用处理器例如 Arm Cortex-A 的设备，支持的设备最小内存为 128MiB，可以提供增强的交互能力、3D GPU 以及硬件合成能力、更多控件以及动效更丰富的图形能力、完整的应用框架。可支撑的产品如高端的冰箱显示屏。

二、OpenHarmony 设计理念

2.1 OpenHarmony 设计理念概述

从操作系统技术角度来讲，用户的本质就是交互体验，生态的本质是开发体验。
OpenHarmony 的设计理念有两条：
- 消费者体验最佳原则：在终端硬件形态多样化的趋势下，保证用户分布式多设备协同体验一致性。
- 开发者最小代价原则：像开发单设备应用一样开发分布式应用，一次开发，多端部署，实现多终端生态一体化。

2.2 OpenHarmony 试图解决的问题

应用生态割裂问题
用户数据割裂问题
软硬件能力割裂问题
多设备交互割裂问题

除了上述提到四个割裂问题外，设备间的安全认证和数据保护，如何向应用开发者提供一套支持跨设备的开发框架等都是需要考虑的问题。

2.4 OpenHarmony 设计目标

请添加图片描述

三、OpenHarmony 技术架构

3.1 OpenHarmony 技术架构图

OpenHarmony 整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统>子系统>功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。
请添加图片描述

3.2 OpenHarmony 技术架构解析

3.2.1内核层

内核层主要包括内核子系统和驱动子系统。

内核子系统：OpenHarmony采用多内核设计，支持不同资源受限设备选用适合的OS核。**内核抽象层(KAL, Kernel Abstract Layer)**通过屏蔽多内核差异，对上层提供基础内核能力，包括：进程/线程管理、内存管理、文件系统、网络管理以及外设管理等。
驱动子系统：硬件驱动框架(HDF)是 OpenHarmony 硬件生态开放的基础，提供统一的外设访问能力、驱动开发、管理框架。
- 统一驱动框架优势：驱动与内核解耦，支持运行动态加载，让更多的IOT设备接入超级终端。
  - 通过平台、系统接口解耦，构建统一的驱动平台底座，兼容Linux、LiteOS等不同的内核；
  - 支撑百K级~G级容量的1+8+N设备的部署；
  - 根据不同的设备形态，支持用户态部署和内核态部署；

请添加图片描述

3.2.2 系统服务层

根据不同设备形态的部署环境，各个子系统集可以按子系统粒度裁剪，子系统内部又可以按功能粒度裁剪。

请添加图片描述

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

系统基本能力子系统集：为分布式应用在 OpenHarmony 多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI 等子系统组成。其中，方舟运行时提供了ArkTS/TS/JS 多语言运行时和基础的系统类库。
基础软件服务子系统集：为 OpenHarmony 提供公共的、通用的软件服务，由事件通知、电话、多媒体、DFX（Design For X）、MSDP&DV 等子系统组成。
增强软件服务子系统集：为 OpenHarmony 提供针对不同设备的、差异化的能力增强型软件服务，由智慧屏专有业务、穿戴专有业务、IoT 专有业务等子系统组成。
硬件服务子系统集：为 OpenHarmony 提供硬件服务，由位置服务、生物特征识别、穿戴专有硬件服务、IoT 专有硬件服务等子系统组成。
根据不同设备形态的部署环境，基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪，每个子系统内部又可以按功能粒度裁剪。

3.2.3 框架层

框架层为 OpenHarmony 应用开发提供了 ArkTS/JS/C/C++等多语言的用户程序框架，以及各种软硬件服务对外开放的多语言框架 API。根据系统的组件化裁剪程度，OpenHarmony 设备支持的 API 也会有所不同。
请添加图片描述

3.2.4 应用层

应用层包括系统应用和扩展/第三方非系统应用。
Stage 模型：在该模型中，由于提供了 AbilityStage、WindowStage 等类作为应用组件和Window 窗口的“舞台”，因此称这种应用模型为 Stage 模型。

四、OpenHarmony 部件化架构设计

4.1 部件化架构

OpenHarmony 在模块化、组件化的基础上，引入了部件化架构的软件工程方法，综合运用模块化、部件化、组件化等手段，有效支撑了统一的操作在不同规格、不同形态、不同类型的设备上的弹性部署。
请添加图片描述

4.2 架构分层与组件化

请添加图片描述

应用层：由应用开发者交付，向最终消费者提供 UI 接口，为消费者体验负责。应用层向下仅依赖于框架层提供的 API，应用开发仅依赖于操作发布的 SDK。应用层每个应用对应于一个个独立交付的应用组件。
基础平台：具体包括框架层、系统服务层和内层，由操作系统平台开发者交付，面向北向应用生态提供 API 和 SDK，面向南向设备生态提供 Driver Interface 和 DDK。内核层向上提供 KAL（Kernel Abstract Layer，支持 POSIX 和 CMSIS 两种标准接口）和 HDI 接口，内核层每种内核形态对应于一个内核组件；系统服务层和框架层之间未定义标准的层级接口，框架层和系统服务层组合成系统组件。
驱动层：由设备开发者交付，向操作系统提供器件驱动实现。驱动层仅依赖于驱动框架提供的Driver Interface，驱动开发仅依赖于操作系统发布的 DDK。驱动层对应于芯片组件。

4.3 部件管理

部件是系统拼装的一个个零部件，每个部件都提供一定的系统能力，一些部件还涉及面向应用暴露 API 接口，不同部件组合部署到特定设备上，面向应用提供的 API 能力必然存在差异。
为了支持基于部件的积木化拼装，部件的基本特征包括：

部件之间相对独立
和所依赖的部件一起拼装部署
可对外提供一定的系统软硬件能力

请添加图片描述

五、OpenHarmony 技术特性

请添加图片描述

5.1 统一 OS，弹性部署

OpenHarmony 通过组件化和小型化等设计方法，支持多种终端设备按需弹性部署，能够适配不同类别的硬件资源和功能需求。支撑通过编译链关系去自动生成组件化的依赖关系，形成组件树依赖图，支撑产品系统的便捷开发，降低硬件设备的开发门槛。

支持各组件的选择（组件可有可无）：根据硬件的形态和需求，可以选择所需的组件。
支持组件内功能集的配置（组件可大可小）：根据硬件的资源情况和功能需求，可以选择配置组件中的功能集。例如，选择配置图形框架组件中的部分控件。
支持组件间依赖的关联（平台可大可小）：根据编译链关系，可以自动生成组件化的依赖关系。例如，选择图形框架组件，将会自动选择依赖的图形引擎组件等。

5.2 一次开发，多端部署

OpenHarmony 提供了用户程序框架、Ability 框架以及 UI 框架，支持应用开发过程中多终端的业务逻辑和界面逻辑进行复用，能够实现应用的一次开发、多端部署，提升了跨设备应用的开发效率。
其中，UI 框架支持使用 ArkTS、JS 语言进行开发，并提供了丰富的多态控件，可以在手机、平板、智能穿戴、智慧屏、车机上显示不同的 UI 效果。采用业界主流设计方式，提供多种响应式布局方案，支持栅格化布局，满足不同屏幕的界面适配能力。

请添加图片描述

5.3 硬件互助，资源共享

多种设备之间能够实现硬件互助、资源共享，依赖的关键技术包括分布式软总线、分布式设备虚拟化、分布式数据管理、分布式任务调度等。

- 分布式软总线

分布式软总线是手机、平板、智能穿戴、智慧屏、车机等分布式设备的通信基座，为设备之间的互联互通提供了统一的分布式通信能力，为设备之间的无感发现和零等待传输创造了条件。
开发者只需聚焦于业务逻辑的实现，无需关注组网方式与底层协议。
请添加图片描述

- 分布式设备虚拟化

请添加图片描述

- 分布式数据管理

请添加图片描述

- 分布式任务调度

请添加图片描述

六、OpenHarmony 系统安全

请添加图片描述

七、思考题

1. 以下哪几项属于OpenHarmony的技术特性？（）
    A. 统一OS，弹性部署
    B. 一次开发，多端部署
    C. 硬件互助，资源共享

2. OpenHarmony硬件互助资源共享特性依赖以下哪几项技术？（）
    A. 分布式软总线
    B. 分布式任务调度
    C. 分布式设备虚拟化
    D. 分布式数据管理