鸿蒙读书笔记1：《鸿蒙操作系统设计原理与架构》

笔记来自新书：《鸿蒙操作系统设计原理与架构》
HarmonyOS采用分层架构，从下到
上依次分为内核层、系统服务层、框架层和应用层。

1. 内核层
内核层主要提供硬件资源抽象和常用软件资源，包括进程/线程管
理、内存管理、文件系统和IPC（Interprocess Communication，进程
间通信）等。
内核子系统：采用多内核（如Linux内核或LiteOS等）设计，支持针
对 不 同 资 源 受 限 设 备 选 用 合 适 的 内 核。
KAL（Kernel Abstract Layer，内核抽象层）通过屏蔽多内核差异，
为上层提供内核的统一基础能力，包括进程/线程管理、内存管理、
文件系统、网络管理和外围设备管理等。
驱动子系统：HDF是系统硬件生态开放的基础，提供统一的外围设
备访问能力和驱动开发、管理框架。

2. 系统服务层
系统服务层是HarmonyOS的核心能力集，该层包含以下几个部分。
系统基本能力子系统集：为分布式用户程序在HarmonyOS多设备上
的运行、调度、迁移等操作提供基础能力。该子系统集由分布式软
总线、分布式数据管理、分布式任务调度，以及公共基础库、多模
输入、图形、安全、AI、方舟编译运行时等子系统组成。
基础软件服务子系统集：提供公共通用的软件服务，由事件通知、
电话、多媒体、DFX、MSDP（Multimodal Sensor Data Platform，多
模态传感数据平台）等子系统组成。
增强软件服务子系统集：提供针对不同设备的、差异化的能力增强
型软件服务，由智慧屏专有业务、穿戴专有业务、IoT专有业务等子
系统组成。
硬 件 服 务 子 系 统 集： 提 供 硬 件 服 务， 由 位 置 服 务、
IAM（Identity and Access Management，身份和访问管理）、穿戴专
有硬件服务、IoT专有硬件服务等子系统组成。
3. 框架层
框架层是用户程序和系统交互的桥梁，为用户程序开发提供
JavaScript、C、C++等多语言的用户程序开发框架，以及UI框架、
Ability框架等同时为系统服务层的软硬件服务提供对外开放的多语
言框架API。
4. 应用层
应用层包括基础用户程序和第三方用户程序，基础用户程序作为系
统的一部分，以用户程序的形式向用户和第三方用户程序提供系统
服务能力。第三方用户程序是HarmonyOS生态丰富的基础，
HarmonyOS用户程序通常由一个或多个HA组成，支持跨设备的调度
与分发，为用户提供一致、高效的体验。

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