第04章-开源鸿蒙的架构概览

第4章开源鸿蒙的架构概览

本章目标：从整体到局部，逐层剖析开源鸿蒙的系统架构，理解各层的职责与协作关系。

4.1 整体架构

开源鸿蒙的系统架构采用分层设计，自上而下可以分为四层：

复制代码

┌─────────────────────────────────────────────────────┐
│                    应用层                             │
│            （系统应用 + 第三方应用）                    │
├─────────────────────────────────────────────────────┤
│                    应用框架层                         │
│         （Ability框架 + ArkUI + ArkTS）               │
├─────────────────────────────────────────────────────┤
│                    系统服务层                         │
│    ┌──────────┬──────────┬──────────┬──────────┐    │
│    │ 分布式   │  基础    │  图形    │  网络    │    │
│    │ 服务层   │  服务层  │  服务层  │  服务层  │    │
│    │软总线   │包管理    │窗口管理  │协议栈    │    │
│    │数据管理 │事件通知  │渲染引擎  │蓝牙/WiFi │    │
│    │硬件平台 │帐号系统  │媒体服务  │          │    │
│    └──────────┴──────────┴──────────┴──────────┘    │
├─────────────────────────────────────────────────────┤
│         内核抽象层（KAL）+ 系统库                    │
├─────────────────────────────────────────────────────┤
│                    内核层                            │
│    ┌──────────┬──────────┬──────────┐              │
│    │ LiteOS-M │ LiteOS-A │  Linux   │              │
│    │(MCU级)   │(MPU级)   │(丰富资源) │              │
│    └──────────┴──────────┴──────────┘              │
├─────────────────────────────────────────────────────┤
│         硬件抽象层（HDF + HDI）                      │
├─────────────────────────────────────────────────────┤
│                    硬件层                            │
│    ┌──────────┬──────────┬──────────┐              │
│    │ SoC      │ 传感器   │ 外设     │              │
│    │ (CPU/GPU │ WiFi/蓝牙│ 显示/音频│              │
│    │  /NPU)   │ NFC/GPS  │ 摄像头   │              │
│    └──────────┴──────────┴──────────┘              │
└─────────────────────────────────────────────────────┘

这个分层架构有几个重要的设计原则：

每层职责明确。应用层负责用户交互，应用框架层提供开发模型，系统服务层提供系统能力，内核层管理硬件资源，硬件抽象层屏蔽硬件差异。每层只通过明确的接口与相邻层交互，不跨层调用。

上层依赖下层，下层不感知上层。内核层不知道应用框架层的存在，硬件抽象层不关心上层是什么服务。这种单向依赖使得各层可以独立演进。

关键接口标准化。层与层之间的接口是标准化的、公开的，这使得：

可以替换某一层的实现而不影响其他层（如替换LiteOS-M为LiteOS-A）
第三方可以基于标准接口开发组件或服务
系统具有更好的可测试性和可维护性

下面我们自底向上逐层分析。

4.2 硬件抽象层（HDF + HDI）

硬件抽象层是操作系统与硬件之间的桥梁。开源鸿蒙的硬件抽象层由两个核心部分组成：HDF（Hardware Driver Foundation）和HDI（Hardware Driver Interface）。

4.2.1 HDF（Hardware Driver Foundation）

HDF是开源鸿蒙的驱动开发框架，它要解决的核心问题是：如何让同一个操作系统适配不同的硬件平台，而不需要为每种硬件重写上层代码？

传统Linux的驱动模型：Linux将驱动编译进内核（或作为内核模块），驱动通过内核的API与系统交互。这意味着驱动的开发和内核版本绑定，换一个内核版本可能需要重新适配驱动。

HDF的设计：HDF将驱动从内核中解耦出来，采用"框架+模型"的设计：

复制代码

┌─────────────────────────────────────┐
│            HDF 驱动框架              │
│                                     │
│  ┌─────────┐  ┌─────────┐          │
│  │驱动模型  │  │服务模型  │          │
│  │(Model)  │  │(Service)│          │
│  └────┬────┘  └────┬────┘          │
│       │            │               │
│  ┌────┴────────────┴────┐          │
│  │   HDF 核心框架        │          │
│  │  ┌─────────────────┐ │          │
│  │  │ 驱动管理器       │ │          │
│  │  │ 设备服务管理     │ │          │
│  │  │ 配置管理         │ │          │
│  │  └─────────────────┘ │          │
│  └─────────────────────┘          │
├─────────────────────────────────────┤
│            HDI 接口                 │
├─────────────────────────────────────┤
│            硬件设备                  │
└─────────────────────────────────────┘

HDF的核心特性：

（1）统一驱动模型。HDF定义了统一的驱动模型，驱动开发者只需要实现模型规定的接口。无论底层硬件是什么（WiFi芯片A还是WiFi芯片B），上层的接口是一致的。

（2）配置与代码分离。驱动的配置信息（如硬件参数、设备树信息）写在HCS（Hardware Configuration Source）配置文件中，与驱动的代码分离。更换硬件只需要修改配置文件，不需要修改代码。

（3）用户态驱动。部分驱动可以运行在用户态，而非内核态。这带来了两个好处：一是提高系统稳定性（驱动崩溃不会导致内核崩溃），二是降低安全风险（驱动在受限的环境中运行）。

（4）跨内核支持。HDF在LiteOS-M、LiteOS-A和Linux三种内核上都提供一致的驱动模型。驱动开发者编写一次驱动代码，可以在不同内核上运行（通过KAL适配）。

4.2.2 HDI（Hardware Driver Interface）

HDI是HDF提供给上层服务的接口。上层服务通过HDI调用硬件功能，不需要知道底层驱动的实现细节。

HDI的接口定义使用IDL（Interface Definition Language），编译器根据IDL生成各语言的调用接口。这种设计使得：

接口变更不影响实现（或反之）
不同语言（C、C++、ArkTS）可以使用同一套接口
接口版本管理更规范

HDF + HDI 的整体价值：

对于硬件厂商来说，他们只需要按照HDF模型开发一次驱动，就可以让硬件在所有运行OpenHarmony的设备上使用。对于系统开发者来说，他们通过HDI调用硬件功能，不需要关心底层是什么硬件。这极大地降低了硬件适配和系统开发的成本。

4.3 内核层与内核抽象层

4.3.1 三种内核

开源鸿蒙的内核层包含三种内核，分别面向不同资源级别的设备：

LiteOS-M

LiteOS-M面向MCU（Micro Controller Unit）级设备，资源占用极小：

特性	指标
最小内存占用	<20KB（仅内核）
最小Flash占用	<100KB
启动时间	<100ms
任务调度	抢占式优先级调度
最大任务数	可配置（通常128-1024个）
IPC机制	信号量、互斥锁、消息队列、事件标志
内存管理	静态内存池 + 动态内存分配
中断管理	嵌套中断支持
适用设备	传感器、智能灯泡、智能门锁、温湿度计

LiteOS-M的设计哲学是"够用就好"------只提供RTOS所需的最基本功能，不包含文件系统、网络协议栈、图形界面等。如果设备需要这些能力，它们作为用户态服务运行在LiteOS-M之上。

LiteOS-A

LiteOS-A面向MPU（Micro Processor Unit）级设备，功能比LiteOS-M更丰富：

特性	指标
内存占用	1-10MB
启动时间	<5s
进程管理	支持多进程、虚拟内存、进程间通信
文件系统	支持FAT、JFFS2、NFS等
网络协议栈	完整的TCP/IP协议栈
POSIX兼容	支持部分POSIX接口
适用设备	智能手表、智能手环、智能音箱、IP摄像头

LiteOS-A可以理解为"介于RTOS和Linux之间的操作系统内核"------它比LiteOS-M功能丰富（支持进程、虚拟内存、文件系统），但又比Linux轻量（内存占用更小、启动更快）。

Linux

Linux面向资源丰富的设备，提供最完整的系统能力：

特性	指标
内存占用	50-200MB
启动时间	5-20s
进程管理	完整的Linux进程管理（CFS、RT调度器）
文件系统	ext4、F2FS、NTFS等
网络协议栈	完整的TCP/IP + 高级网络功能
POSIX兼容	完整的POSIX兼容
驱动生态	丰富的Linux驱动生态
适用设备	手机、平板、电视、车载系统

开源鸿蒙中的Linux内核基于社区Linux LTS版本，在此基础上添加了分布式软总线、安全增强等特定补丁。

4.3.2 内核抽象层（KAL）

KAL（Kernel Abstraction Layer）是开源鸿蒙内核层中最关键的设计之一。

问题：三种内核提供了不同的API------LiteOS-M的任务管理API和Linux的pthread API完全不同，LiteOS-A的进程管理API和Linux的也不一样。如果上层系统服务直接调用内核API，就需要为每种内核维护一套代码。

KAL的解决方案：在三种内核之上定义一组统一的抽象接口，上层系统服务只调用KAL接口，KAL再根据当前运行的内核将调用映射到对应的内核API。

复制代码

上层系统服务
    │
    │ 调用KAL统一接口
    ↓
┌─────────────────────────────────┐
│        KAL（内核抽象层）          │
│                                 │
│  KAL_Process_Create()           │
│  KAL_Process_Destroy()          │
│  KAL_Mutex_Lock()               │
│  KAL_Timer_Create()             │
│  KAL_Memory_Alloc()             │
│  ...                            │
└───┬──────────┬──────────┬───────┘
    │          │          │
    ↓          ↓          ↓
┌────────┐┌────────┐┌────────┐
│LiteOS-M││LiteOS-A││ Linux  │
└────────┘└────────┘└────────┘

KAL涵盖的抽象领域：

领域	KAL统一接口	LiteOS-M实现	LiteOS-A实现	Linux实现
任务/进程	KAL_Task_*	LOS_Task*	进程管理	pthread/clone
内存	KAL_Mem_*	LOS_Mem*	kmalloc/mmap	kmalloc/mmap
互斥锁	KAL_Mutex_*	LOS_Mutex*	futex	futex
信号量	KAL_Sem_*	LOS_Sem*	sysvsem	sysvsem
定时器	KAL_Timer_*	LOS_Swtmr*	hrtimer	hrtimer
中断	KAL_Int_*	LOS_Int*	request_irq	request_irq

KAL的设计权衡：KAL的统一接口取的是三种内核的"最大公约数"------只暴露三者都支持的基本功能。如果某个内核有特有能力（如Linux的epoll），上层需要通过其他方式（如条件编译或运行时检测）来使用。这种权衡是合理的------KAL的目标是让大部分代码不需要修改就能跨内核运行，而非完全抹平内核差异。

4.4 系统服务层

系统服务层是开源鸿蒙的核心能力层，向上为应用框架提供系统能力，向下通过KAL和HDF使用内核和硬件资源。系统服务层包含多个子系统，本节介绍最重要的几个。

4.4.1 分布式服务子系统

分布式服务是开源鸿蒙最核心的差异化能力，包含三个主要组件：

分布式软总线（Distributed Soft Bus）

分布式软总线是连接多设备的"神经中枢"，提供：

设备发现：自动发现附近的OpenHarmony设备（通过BLE、WiFi、蓝牙等协议）
设备认证：基于证书的设备身份认证和安全通信
连接管理：统一的连接抽象，屏蔽底层传输协议的差异
数据传输：跨设备的可靠、高效数据传输

分布式软总线的设计理念是"通信即服务"------上层应用不需要关心两个设备之间是通过WiFi、蓝牙还是有线连接的，只需要指定目标设备，软总线自动选择最优的传输路径，并在路径变化时无缝切换。

分布式数据管理（Distributed Data Management）

分布式数据管理负责跨设备的数据同步和一致性：

分布式数据库：支持键值（KV）数据库和关系型（RDB）数据库的跨设备同步
数据同步策略：支持多种同步模式（实时同步、定时同步、按需同步）
冲突解决：当多个设备同时修改同一条数据时，提供冲突检测和解决机制
数据加密：跨设备数据传输的端到端加密

分布式硬件平台（Distributed Hardware Platform）

分布式硬件平台实现跨设备的硬件资源共享：

硬件虚拟化：将远程设备的硬件能力虚拟化为本地设备可以使用的资源
能力注册与发现：设备向网络注册自己的硬件能力（摄像头、屏幕、扬声器、传感器等），其他设备可以自动发现和使用这些能力
硬件池管理：将多个设备的硬件资源抽象为一个统一的"硬件池"，应用可以从池中获取所需的硬件能力

这三个组件构成了开源鸿蒙分布式能力的"三驾马车"：

软总线解决"连接"问题
数据管理解决"数据"问题
硬件平台解决"算力和外设"问题

4.4.2 基础服务子系统

基础服务提供操作系统的通用系统能力：

包管理服务：

应用的安装、卸载、更新
应用包格式管理（HAP/APP格式）
应用签名验证
存储空间管理

事件通知服务：

发布-订阅模式的事件通知
支持进程内、跨进程、跨设备的事件通知
事件优先级和过滤机制

帐号系统服务：

用户帐号管理（创建、删除、认证）
分布式帐号同步（多设备共享同一个帐号）
授权管理（OAuth2.0、权限授予）

系统参数管理：

系统配置参数的读写
参数的持久化存储
参数变更通知

4.4.3 图形与媒体服务子系统

窗口管理服务：

窗口的创建、销毁、布局
多窗口管理（全屏、分屏、悬浮窗）
窗口动画和特效
输入事件的分发

图形渲染服务：

2D图形渲染引擎（Skia/自研渲染引擎）
渲染管线管理
图形硬件加速（GPU渲染）

媒体服务：

音视频编解码（支持H.264、H.265、AAC、MP3等格式）
音视频播放和录制
相机控制
图像处理

4.4.4 网络服务子系统

网络服务提供完整的网络通信能力：

TCP/IP协议栈：完整的网络协议栈，支持IPv4/IPv6
WiFi管理：WiFi连接、热点管理、WiFi直连
蓝牙管理：BLE和经典蓝牙的管理
NFC管理：近场通信
网络连接管理：多网络接口的管理和切换
HTTP/HTTPS：应用层的网络通信协议
WebSocket：全双工的实时通信

4.5 应用框架层

应用框架层是应用开发者直接接触的层，它定义了应用的开发模型、运行机制和与系统服务的交互方式。

4.5.1 Ability框架

Ability是OpenHarmony应用的基本组成单元。每个应用由一个或多个Ability组成。

开源鸿蒙定义了两种Ability（在Stage模型下）：

UIAbility：带有界面的Ability，负责与用户交互。每个UIAbility对应一个独立的任务栈和窗口。一个应用可以有多个UIAbility，每个UIAbility可以包含多个页面（Page）。

ExtensionAbility：特定场景的扩展能力，包括：

FormExtension：桌面卡片（Widget）
WorkSchedulerExtension：后台定时任务
InputMethodExtension：输入法
AccessibilityExtension：无障碍服务
PushExtension：推送服务

4.5.2 ArkTS

ArkTS是开源鸿蒙的主力开发语言。它是基于TypeScript的扩展，在TypeScript的基础上做了以下增强和限制：

增强：

声明式UI语法：通过装饰器（@Component、@Entry、@State等）支持声明式UI描述
状态管理：内置响应式状态管理机制（@State、@Prop、@Link等）
并发模型：提供TaskPool和Worker的并发编程接口
系统API绑定：可以直接调用OpenHarmony的系统API

限制：

禁止使用any类型（增强类型安全）
禁止使用eval等动态特性（保障运行时性能）
限制部分TypeScript高级特性（降低学习成本和运行时开销）

4.5.3 ArkUI

ArkUI是开源鸿蒙的声明式UI框架。开发者通过描述"UI应该是什么样"（而非"如何一步步创建UI"）来构建界面。

ArkUI的核心特性：

声明式语法：

typescript 复制代码

@Component
struct HelloComponent {
  @State message: string = 'Hello OpenHarmony'
  
  build() {
    Column() {
      Text(this.message)
        .fontSize(30)
        .fontWeight(FontWeight.Bold)
      Button('Click Me')
        .onClick(() => {
          this.message = 'Hello World'
        })
    }
  }
}

响应式状态管理：当状态变量（用@State标记）的值变化时，UI自动更新。开发者不需要手动操作DOM或调用刷新方法。

自适应布局：ArkUI提供了多种布局容器（Row、Column、Stack、Flex、Grid等），配合响应式单位（vp、fp）和断点（Breakpoint）机制，自动适配不同屏幕尺寸。

丰富的组件库：ArkUI内置了大量UI组件------文本、按钮、图片、列表、标签页、弹窗、对话框、导航等，覆盖了常见的UI需求。

动画系统：支持属性动画、转场动画和显式动画，开发者可以轻松实现流畅的界面过渡效果。

4.6 应用层

应用层是用户直接使用的软件，包括系统应用和第三方应用。

4.6.1 系统应用

开源鸿蒙的发行版（如HarmonyOS）通常包含以下系统应用：

桌面（Launcher）：应用图标展示、应用启动管理
设置（Settings）：系统配置管理
电话/短信：通信功能
联系人：通讯录管理
相机/相册：拍照和照片管理
浏览器：网页浏览
应用市场：应用分发和管理

4.6.2 应用包格式

OpenHarmony的应用包格式为HAP（Harmony Ability Package）：

复制代码

MyApp.app          ← 应用包（目录）
├── module.json    ← 模块配置（Ability声明、权限等）
├── resources      ← 资源文件（图片、字符串、布局等）
│   ├── base/
│   └── limited/   ← 按设备能力分目录
├── ets            ← ArkTS源代码
│   ├── pages/
│   └── entryability/
├── libs           ← 原生库（C/C++）
└── rawfile        ← 原始资源文件

一个应用可以包含多个模块（Module），每个模块是一个HAP文件。多模块设计的好处是：

按需加载：只在需要时加载对应模块，节省内存
独立更新：模块可以单独更新，不需要重新安装整个应用
灵活组合：不同设备可以安装不同的模块组合

4.6.3 应用安全模型

开源鸿蒙的应用安全模型基于以下机制：

应用沙箱：每个应用运行在独立的沙箱中，拥有独立的文件存储空间、网络身份和运行环境。应用不能直接访问其他应用的数据。

权限管理：应用需要声明所需的权限（如相机权限、位置权限），在安装时或运行时向用户请求授权。权限分为：

normal：普通权限，安装时自动授予
user_grant：敏感权限，运行时需要用户手动授权
system_grant：系统权限，仅系统应用可申请

应用签名：所有应用必须经过签名才能安装。签名确保了应用的来源可信性和完整性。

应用隔离：不同应用之间的进程隔离、数据隔离和权限隔离，防止恶意应用影响系统或其他应用。

4.7 架构设计总结

4.7.1 开源鸿蒙架构的关键设计决策

回顾整个架构，可以总结出几个关键的设计决策：

决策一：多内核 + KAL，而非单内核

选择三种内核而非一种，是因为没有一种内核能同时满足MCU的轻量需求和服务器的丰富需求。KAL的存在使上层代码不需要感知内核差异。

决策二：微内核架构（LiteOS-M/A），而非宏内核

LiteOS-M和LiteOS-A都采用微内核架构设计思想（虽然LiteOS-A的实现介于宏内核和微内核之间）。这是为了获得更好的安全性和可靠性，以及为分布式能力奠定基础。

决策三：分布式能力内建，而非外挂

分布式软总线、分布式数据管理、分布式硬件平台是系统服务层的核心组件，不是应用层的附加功能。这确保了分布式能力的稳定性和性能。

决策四：统一的开发语言（ArkTS），而非多语言并存

ArkTS提供了一致的开发体验，降低了学习成本，同时通过编译时优化保证了运行时性能。

决策五：HDF驱动框架统一硬件适配

通过HDF + HDI，实现了"一次开发驱动，多平台使用"的目标。

4.7.2 与Android架构的对比

理解了开源鸿蒙的架构后，与Android做一个整体对比：

层次	Android	开源鸿蒙
应用层	APK（Java/Kotlin）	HAP（ArkTS）
应用框架	Activity/Service/Broadcast/Content	UIAbility/ExtensionAbility
系统服务	System Server + 各种ManagerService	分布式服务 + 基础服务 + 图形媒体
IPC	Binder（单设备）	分布式软总线（跨设备）
运行时	ART/Dalvik	ArkTS Runtime
内核	Linux	LiteOS-M/A + Linux
驱动	Linux内核模块	HDF框架
硬件抽象	HAL	HDF + HDI

最核心的差异在于分布式能力是系统架构层面的设计，而非附加功能。

4.8 本章小结

关键要点回顾：

分层架构：应用层 → 应用框架层 → 系统服务层 → 内核抽象层（KAL） → 内核层 → 硬件抽象层（HDF/HDI） → 硬件层
HDF + HDI：统一的驱动框架，一次开发驱动，多平台使用，配置与代码分离
三种内核 + KAL：LiteOS-M（MCU级）、LiteOS-A（MPU级）、Linux（资源丰富），KAL提供统一抽象
系统服务层：分布式服务（软总线、数据管理、硬件平台）是核心差异化，辅以基础服务、图形媒体服务、网络服务
应用框架：Ability框架（UIAbility + ExtensionAbility）+ ArkTS + ArkUI，Stage模型是当前主流
架构优势：分布式内建、多内核统一、驱动框架解耦、开发体验一致

从下一章开始，我们将深入第三部分，逐个分析开源鸿蒙的核心特性与实现细节。下一章是第5章：一次开发多端部署。

第04章-开源鸿蒙的架构概览

第4章 开源鸿蒙的架构概览

4.1 整体架构

4.2 硬件抽象层（HDF + HDI）

4.2.1 HDF（Hardware Driver Foundation）

4.2.2 HDI（Hardware Driver Interface）

4.3 内核层与内核抽象层

4.3.1 三种内核

4.3.2 内核抽象层（KAL）

4.4 系统服务层

4.4.1 分布式服务子系统

4.4.2 基础服务子系统

4.4.3 图形与媒体服务子系统

4.4.4 网络服务子系统

4.5 应用框架层

4.5.1 Ability框架

4.5.2 ArkTS

4.5.3 ArkUI

4.6 应用层

4.6.1 系统应用

4.6.2 应用包格式

4.6.3 应用安全模型

4.7 架构设计总结

4.7.1 开源鸿蒙架构的关键设计决策

4.7.2 与Android架构的对比

4.8 本章小结

第4章开源鸿蒙的架构概览