第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硬件抽象层是操作系统与硬件之间的桥梁。开源鸿蒙的硬件抽象层由两个核心部分组成HDFHardware Driver Foundation和HDIHardware Driver Interface。4.2.1 HDFHardware Driver FoundationHDF是开源鸿蒙的驱动开发框架它要解决的核心问题是如何让同一个操作系统适配不同的硬件平台而不需要为每种硬件重写上层代码传统Linux的驱动模型Linux将驱动编译进内核或作为内核模块驱动通过内核的API与系统交互。这意味着驱动的开发和内核版本绑定换一个内核版本可能需要重新适配驱动。HDF的设计HDF将驱动从内核中解耦出来采用框架模型的设计┌─────────────────────────────────────┐ │ HDF 驱动框架 │ │ │ │ ┌─────────┐ ┌─────────┐ │ │ │驱动模型 │ │服务模型 │ │ │ │(Model) │ │(Service)│ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ ┌────┴────────────┴────┐ │ │ │ HDF 核心框架 │ │ │ │ ┌─────────────────┐ │ │ │ │ │ 驱动管理器 │ │ │ │ │ │ 设备服务管理 │ │ │ │ │ │ 配置管理 │ │ │ │ │ └─────────────────┘ │ │ │ └─────────────────────┘ │ ├─────────────────────────────────────┤ │ HDI 接口 │ ├─────────────────────────────────────┤ │ 硬件设备 │ └─────────────────────────────────────┘HDF的核心特性1统一驱动模型。HDF定义了统一的驱动模型驱动开发者只需要实现模型规定的接口。无论底层硬件是什么WiFi芯片A还是WiFi芯片B上层的接口是一致的。2配置与代码分离。驱动的配置信息如硬件参数、设备树信息写在HCSHardware Configuration Source配置文件中与驱动的代码分离。更换硬件只需要修改配置文件不需要修改代码。3用户态驱动。部分驱动可以运行在用户态而非内核态。这带来了两个好处一是提高系统稳定性驱动崩溃不会导致内核崩溃二是降低安全风险驱动在受限的环境中运行。4跨内核支持。HDF在LiteOS-M、LiteOS-A和Linux三种内核上都提供一致的驱动模型。驱动开发者编写一次驱动代码可以在不同内核上运行通过KAL适配。4.2.2 HDIHardware Driver InterfaceHDI是HDF提供给上层服务的接口。上层服务通过HDI调用硬件功能不需要知道底层驱动的实现细节。HDI的接口定义使用IDLInterface Definition Language编译器根据IDL生成各语言的调用接口。这种设计使得接口变更不影响实现或反之不同语言C、C、ArkTS可以使用同一套接口接口版本管理更规范HDF HDI 的整体价值对于硬件厂商来说他们只需要按照HDF模型开发一次驱动就可以让硬件在所有运行OpenHarmony的设备上使用。对于系统开发者来说他们通过HDI调用硬件功能不需要关心底层是什么硬件。这极大地降低了硬件适配和系统开发的成本。4.3 内核层与内核抽象层4.3.1 三种内核开源鸿蒙的内核层包含三种内核分别面向不同资源级别的设备LiteOS-MLiteOS-M面向MCUMicro Controller Unit级设备资源占用极小特性指标最小内存占用20KB仅内核最小Flash占用100KB启动时间100ms任务调度抢占式优先级调度最大任务数可配置通常128-1024个IPC机制信号量、互斥锁、消息队列、事件标志内存管理静态内存池 动态内存分配中断管理嵌套中断支持适用设备传感器、智能灯泡、智能门锁、温湿度计LiteOS-M的设计哲学是够用就好——只提供RTOS所需的最基本功能不包含文件系统、网络协议栈、图形界面等。如果设备需要这些能力它们作为用户态服务运行在LiteOS-M之上。LiteOS-ALiteOS-A面向MPUMicro Processor Unit级设备功能比LiteOS-M更丰富特性指标内存占用1-10MB启动时间5s进程管理支持多进程、虚拟内存、进程间通信文件系统支持FAT、JFFS2、NFS等网络协议栈完整的TCP/IP协议栈POSIX兼容支持部分POSIX接口适用设备智能手表、智能手环、智能音箱、IP摄像头LiteOS-A可以理解为介于RTOS和Linux之间的操作系统内核——它比LiteOS-M功能丰富支持进程、虚拟内存、文件系统但又比Linux轻量内存占用更小、启动更快。LinuxLinux面向资源丰富的设备提供最完整的系统能力特性指标内存占用50-200MB启动时间5-20s进程管理完整的Linux进程管理CFS、RT调度器文件系统ext4、F2FS、NTFS等网络协议栈完整的TCP/IP 高级网络功能POSIX兼容完整的POSIX兼容驱动生态丰富的Linux驱动生态适用设备手机、平板、电视、车载系统开源鸿蒙中的Linux内核基于社区Linux LTS版本在此基础上添加了分布式软总线、安全增强等特定补丁。4.3.2 内核抽象层KALKALKernel 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/mmapkmalloc/mmap互斥锁KAL_Mutex_*LOS_Mutex*futexfutex信号量KAL_Sem_*LOS_Sem*sysvsemsysvsem定时器KAL_Timer_*LOS_Swtmr*hrtimerhrtimer中断KAL_Int_*LOS_Int*request_irqrequest_irqKAL的设计权衡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/IPv6WiFi管理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桌面卡片WidgetWorkSchedulerExtension后台定时任务InputMethodExtension输入法AccessibilityExtension无障碍服务PushExtension推送服务4.5.2 ArkTSArkTS是开源鸿蒙的主力开发语言。它是基于TypeScript的扩展在TypeScript的基础上做了以下增强和限制增强声明式UI语法通过装饰器Component、Entry、State等支持声明式UI描述状态管理内置响应式状态管理机制State、Prop、Link等并发模型提供TaskPool和Worker的并发编程接口系统API绑定可以直接调用OpenHarmony的系统API限制禁止使用any类型增强类型安全禁止使用eval等动态特性保障运行时性能限制部分TypeScript高级特性降低学习成本和运行时开销4.5.3 ArkUIArkUI是开源鸿蒙的声明式UI框架。开发者通过描述UI应该是什么样而非如何一步步创建UI来构建界面。ArkUI的核心特性声明式语法Componentstruct HelloComponent{Statemessage:stringHello OpenHarmonybuild(){Column(){Text(this.message).fontSize(30).fontWeight(FontWeight.Bold)Button(Click Me).onClick((){this.messageHello 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的应用包格式为HAPHarmony Ability PackageMyApp.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开源鸿蒙应用层APKJava/KotlinHAPArkTS应用框架Activity/Service/Broadcast/ContentUIAbility/ExtensionAbility系统服务System Server 各种ManagerService分布式服务 基础服务 图形媒体IPCBinder单设备分布式软总线跨设备运行时ART/DalvikArkTS Runtime内核LinuxLiteOS-M/A Linux驱动Linux内核模块HDF框架硬件抽象HALHDF HDI最核心的差异在于分布式能力是系统架构层面的设计而非附加功能。4.8 本章小结关键要点回顾分层架构应用层 → 应用框架层 → 系统服务层 → 内核抽象层KAL → 内核层 → 硬件抽象层HDF/HDI → 硬件层HDF HDI统一的驱动框架一次开发驱动多平台使用配置与代码分离三种内核 KALLiteOS-MMCU级、LiteOS-AMPU级、Linux资源丰富KAL提供统一抽象系统服务层分布式服务软总线、数据管理、硬件平台是核心差异化辅以基础服务、图形媒体服务、网络服务应用框架Ability框架UIAbility ExtensionAbility ArkTS ArkUIStage模型是当前主流架构优势分布式内建、多内核统一、驱动框架解耦、开发体验一致从下一章开始我们将深入第三部分逐个分析开源鸿蒙的核心特性与实现细节。下一章是第5章一次开发多端部署。