笔记来自新书：《鸿蒙操作系统设计原理与架构》
HarmonyOS采用分层架构，从下到
上依次分为内核层、系统服务层、框架层和应用层。
- 内核层
内核层主要提供硬件资源抽象和常用软件资源，包括进程/线程管
理、内存管理、文件系统和IPC（Interprocess Communication，进程
间通信）等。
内核子系统：采用多内核（如Linux内核或LiteOS等）设计，支持针
对 不 同 资 源 受 限 设 备 选 用 合 适 的 内 核。
KAL（Kernel Abstract Layer，内核抽象层）通过屏蔽多内核差异，
为上层提供内核的统一基础能力，包括进程/线程管理、内存管理、
文件系统、网络管理和外围设备管理等。
驱动子系统：HDF是系统硬件生态开放的基础，提供统一的外围设
备访问能力和驱动开发、管理框架。
- 系统服务层
系统服务层是HarmonyOS的核心能力集，该层包含以下几个部分。
系统基本能力子系统集：为分布式用户程序在HarmonyOS多设备上
的运行、调度、迁移等操作提供基础能力。该子系统集由分布式软
总线、分布式数据管理、分布式任务调度，以及公共基础库、多模
输入、图形、安全、AI、方舟编译运行时等子系统组成。
基础软件服务子系统集：提供公共通用的软件服务，由事件通知、
电话、多媒体、DFX、MSDP（Multimodal Sensor Data Platform，多
模态传感数据平台）等子系统组成。
增强软件服务子系统集：提供针对不同设备的、差异化的能力增强
型软件服务，由智慧屏专有业务、穿戴专有业务、IoT专有业务等子
系统组成。
硬 件 服 务 子 系 统 集： 提 供 硬 件 服 务， 由 位 置 服 务、
IAM（Identity and Access Management，身份和访问管理）、穿戴专
有硬件服务、IoT专有硬件服务等子系统组成。
- 框架层
框架层是用户程序和系统交互的桥梁，为用户程序开发提供
JavaScript、C、C++等多语言的用户程序开发框架，以及UI框架、
Ability框架等同时为系统服务层的软硬件服务提供对外开放的多语
言框架API。
- 应用层
应用层包括基础用户程序和第三方用户程序，基础用户程序作为系
统的一部分，以用户程序的形式向用户和第三方用户程序提供系统
服务能力。第三方用户程序是HarmonyOS生态丰富的基础，
HarmonyOS用户程序通常由一个或多个HA组成，支持跨设备的调度
与分发，为用户提供一致、高效的体验。
HarmonyOS关键技术
- 分布式
分布式技术包括分布式计算、分布式存储、分布式调度、分布式软
总线、分布式安全、分布式硬件等。
分布式计算：HarmonyOS分布式计算，是指单个用户程序可以分解
为多个可执行实体，多个可执行实体分布在多个终端设备上分别执
行，最终协同完成整体任务。此处的分布式计算与以实现超算为目
的的并行计算和以弹性任务部署为目的的云系统中的分布式计算定
义有所不同。为了区别它们，把此处的分布式计算定义为"异构多端
非对称分布式计算"，而把后面两种定义为"同构多端对称分布式计
算"。可执行实体不是简单的一组指令，在HarmonyOS中一般以HA
为单位。
分布式存储：分布式存储（Distributed Storage）是指系统的各种存
储（如文件、数据库等）接口可以跨越不同的设备，文件的物理存
储位置由系统自动选择，用户程序不感知，用户程序感知的是经过
系统映射的逻辑存储位置。相对于单端文件系统，分布式文件系统
是允许文件通过网络在多台主机上分享的文件系统。对于文件访
问，单端文件系统一般直接访问底层的数据存储区块，而分布式文
件系统则以特定的通信协议和其他设备的存储服务一起访问。分布
式文件系统一般基于文件ACL（Access Control List，访问控制列
表）或用户授权等方式实现对文件系统的访问控制。CAP定理
（CAP Theorem）又称布鲁尔定理（Brewer's Theorem）指出，对一
个 分 布 式 系 统 来 说， 数 据 的 一 致 性、 可 用 性 和 分 区 容 错 性
（Partition Tolerance） 无 法 兼 具， 最 多 只 能 具 备 两 种。 在
HarmonyOS中，可用性优先级一般高于一致性优先级。
分布式调度：分布式调度（Distributed Schedule）是指对分布在不同
设备上的软件实体和系统服务进行统一调度。其中，对软件实体的
分布式调度，是指对可分解为多个可执行实体的单个用户程序，操
作系统将各个可执行实体分布在多个终端设备上执行，最终协同完
成整体任务，其分布式调度过程由操作系统根据系统动态配置的业
务和调度策略自动判别实施，用户程序自身不能主动实施。
分布式软总线：支持处于同一分布式系统下的设备之间自发现、自
连接、自组网及处于不同分布式系统下的设备之间发现和业务按需
互联的能力；在各种复杂环境里，最大程度地提高空口利用率，保
证多设备、多业务并发时高优先级业务的用户体验。
分布式安全：HarmonyOS提出一套基于分级安全理论体系的安全架
构，围绕"正确的人，通过正确的设备，正确地访问数据"，来构建
一套新的、纯净的用户程序和有序透明的生态秩序，为用户和开发
者带来安全分布式协同、严格隐私保护与数据安全的全新体验。
HarmonyOS安全能力根植于硬件实现的3个可信根，即启动、存储、
计算，以基础安全工程能力为依托，重点围绕设备完整性保护、数
据机密性保护、漏洞攻防对抗构建相关的安全技术和能力。
分布式硬件：一种虚拟化技术，包括虚拟外围设备和虚拟服务两
种。虚拟外围设备支持将处于同一分布式系统下的其他物理终端上
的外围设备，映射为本地物理设备的虚拟外围设备，从而使用户程
序可以无感知地使用处于同一分布式系统下的其他物理终端上的外
围设备。虚拟服务支持将处于同一分布式系统下的其他物理终端上
的服务，包括系统服务和用户程序提供的服务，映射为本地物理设
备的虚拟服务，从而使用户程序可以无感知地使用处于同一分布式
系统下的其他物理终端上的服务。
- 用户程序平滑迁移
在分布式系统中存在多个物理终端的情况下，用户程序可平滑地在
不同终端上迁移，即正在物理终端A上执行的用户程序，可以迁移
到处于同一分布式系统下的其他物理终端上继续执行。为简化系统
复杂性，对用户程序迁移进行如下设计约束。
第一，仅支持有限度的状态恢复，暂不考虑任意状态下的完全恢
复。
第二，只有采用HarmonyOS分布式开发框架开发的用户程序才能实
现平滑迁移。
第三，可迁移的用户程序需设计多状态可重入入口，即用户程序需
要设计1～N个状态，并且每个状态都有直达入口。例如，用户程序
A存在5个状态A～E，该程序在物理终端A上执行到状态B时发生迁
移，在迁移到目标设备上时，用户程序A将从状态B的初始阶段而非
状态B的当前阶段开始执行。
第四，每个可迁移的用户程序执行实体均会在编译时生成系统资源
需求Profile，只有满足系统资源需求的物理终端才能作为迁移的目标
终端。识别匹配迁移目标终端的过程由操作系统自动完成，用户程
序不能主动干预。IDE需要提供典型可迁移目标终端的仿真结果，并
在用户程序开发过程中让开发者理解其所开发的用户程序具备怎样
的可迁移能力，以及可迁移到哪些类型的物理终端上。
- GUI自适应
前文讲到HarmonyOS支持让GUI自动适配各种尺寸、各种形状的屏
幕，实现用户一次编程就可在多种设备上运行的目标。事实上，操
作系统无法确保对任意GUI的自动适配都能提供令人满意的视觉体
验，譬如，由于可能出现如图像过度缩放导致图像不美观甚至难以
识别，要显示的文字信息太多而在较小屏幕上无法有效显示等问
题，HarmonyOS自适应布局技术对开发者的GUI设计存在一定的技
术约束。为了让开发者直观了解其所开发的GUI在不同物理终端上
的自适应布局效果，并能够进行针对性设计，指示系统在某些条件
下进行何种自适应处理，HarmonyOS IDE提供在开发过程中对各种
典型终端的仿真能力。当然，用户程序开发者也可以指定某些类型
的物理终端作为用户程序运行的目标终端。
- 部件化拼装
HarmonyOS支持高度部件化，通过编译配置构建不同的部件，再通
过HPM将其拼装为可运行在目标终端上的系统镜像包。需要指出的
是，用于描述设备SystemCapability的Profile文件也会在编译构建过
程中自动生成，并最终打包在系统镜像包中。对于无法通过功能解
耦方式裁剪到目标大小的部件，则需要提供多种部件形态供HPM选
择。譬如，由于Linux内核无法裁剪到10 KB级别，HarmonyOS内核
部件组可提供Linux内核、LiteOS-A内核和LiteOS-M内核3种部件形
态。对于涉及多个部件形态的情况，HarmonyOS要求各部件接口集
合必须满足真子集包含关系。譬如，对于内核部件要求LiteOS-M接
口集合为LiteOS-A接口集合的真子集，则LiteOS-A接口集合必须为
Linux内核接口集合的真子集。
- 语言统一运行时
HarmonyOS支持多范式多编程语言的用户程序开发，支持的编程语
言包括ArkTS（华为在TypeScript基础上扩展定义的一种语言超
集）、JavaScript、仓颉（华为自研编程语言）、C/C++等，用户需
要相应的工具链和运行时来支撑这些高级编程语言的高效开发和运
行。Ark Compiler作为HarmonyOS的统一编程平台，包含编译器、工
具链、运行时等关键部件，支持多种编程语言、多种芯片平台的联
合编译与运行，通过插件化和模块化机制提供对不同编程语言和不
同运行设备场景的支持。
语言支持插件化使得语言接入可配置，例如在轻量设备上，可配置
为JavaScript单一语言运行时。运行时系统支持模块化按需组合，其
中执行引擎包括解释器、JIT（Just-In-Time，即时）编译器、
AOT（Ahead Of Time，预先）编译器等，内存管理包括多种分配器
和垃圾回收器。例如在轻量设备上，可选择纯解释器执行引擎方
案。
- 按需启停
与传统操作系统不同，HarmonyOS的内核线程和驱动不会在内核启
动时完全启动。启动的时机因不同的产品形态或不同的场景而不尽
相同，总的原则是按需加载和启动。譬如，在车机快速启动场景
下，内核只会启动与倒车影像等特性相关的部件。从用户态进程来
看，系统服务分为常驻服务和按需加载服务。常驻服务在系统启动
时启动，按需加载服务根据业务需要由系统动态加载，在业务结束
后系统动态关闭。同理，系统核心基础用户程序在系统启动时加
载，其他基础用户程序及第三方用户程序按业务需要由系统动态加
载。系统服务或用户程序出现故障时，系统需要根据故障服务的类
型对相关服务进行恢复，确保提供更好的用户体验。
- 多模态交互
多模态交互是指整合或融合两种及两种以上的交互方式，给用户提
供更便捷、更人性化的体验。交互方式包括键盘/鼠标或触控方式的
GUI、 语 音 控 制 方 式 的 VUI（Voice User Interface， 语 音 用 户 界
面）、手势/姿态控制的CVUI（Computer Vision User Interface，计算
机视觉用户界面）和GeUI（Gesture User Interface，手势用户界
面），以及基于设备之间相对位置变化的交互等。多模态交互是下
一代操作系统的重要交互方式，是支持多设备和全场景的关键能
力，是AI交互能力向开发者开放的关键路径。在原子化服务的时
代，多模态交互是服务和用户之间的纽带，是多种设备统一交互的
关键技术，需要在操作系统层面构建。
- 可动态挂载的HDF驱动框架
HarmonyOS采用全新设计的HDF驱动框架，实现驱动与系统完全解
耦，以及可在运行态动态挂载，使得驱动可以极低成本重用，突破
了传统驱动重用代价大、无法动态扩展硬件、安全风险高的瓶颈。
HDF驱动框架采用面向对象编程模型方式进行构建，通过硬件抽
象、内核解耦等方式，实现兼容不同内核部署的目的，从而帮助开
发者实现驱动"一次开发，多端部署"的效果。
- 原生智能
原生智能包括HarmonyOS内置AI基础能力和利用AI自主改造的能
力。AI基础能力主要包括对AI硬件的管理、内置AI开发框架及AI推
理和训练模型等，方便用户程序和操作系统的其他子系统高效利用
系统的AI资源。操作系统利用AI自主改造的能力主要体现在利用预
置的AI能力进一步提升操作系统中其他子系统的智能化水平。