第3章 开源鸿蒙的诞生与发展

本章目标：理解开源鸿蒙诞生的历史背景、发展脉络，以及它试图解决的核心问题。

---

3.1 为什么需要一个新的操作系统

3.1.1 传统操作系统的局限性

第2章分析了移动操作系统和嵌入式操作系统的发展脉络。到2019年，业界面临一个尴尬的现实：Android和iOS两大生态几乎垄断了智能设备市场，但它们都没有很好地解决一个根本问题——跨设备的统一体验。

Android的局限：

Android是优秀的移动操作系统，但它本质上是面向手机和平板设计的。当它被扩展到其他设备类型时，暴露出明显的问题：

• 系统臃肿：Android的基础系统占用数百MB到数GB的存储空间，对于内存只有几十MB的IoT设备来说完全不可行。即使推出Android Things等裁剪版本，仍然难以适配资源极受限的MCU设备
• 碎片化严重：Android运行在数万种不同型号的设备上，屏幕尺寸、SoC、传感器各不相同。应用适配成本高，用户体验不一致
• 分布式能力不足：Android的设备间通信主要依赖蓝牙、WiFi直连等标准协议，缺乏内建的分布式能力。Google的Nearby Connections API只是应用层的桥接，无法实现真正的"超级终端"
• 实时性不足：Linux内核虽然有RT补丁，但实时性能远不如专门的RTOS。在汽车、工业等需要严格时间确定性的场景中，Android并不适用

iOS的局限：

iOS提供了优秀的用户体验，但它的封闭性是根本性的障碍：

• 生态封闭：iOS仅在Apple自研硬件上运行，无法支持其他厂商的设备。这意味着IoT设备的碎片化问题在iOS生态中不可能解决
• 硬件受限：iOS覆盖的设备类型有限（iPhone、iPad、Apple Watch、Apple TV、Mac），无法覆盖IoT设备的广阔谱系
• 分布式能力有限：虽然Apple推出了Handoff、AirDrop、Continuity等功能，但这些功能在Apple设备之间是外挂式的，不是操作系统内核层面的设计
• 价格门槛：Apple设备定位高端，无法覆盖价格敏感的IoT和嵌入式市场

传统嵌入式OS的局限：

FreeRTOS、VxWorks、QNX等传统RTOS虽然在各自领域表现优秀，但它们面临另一个方向的问题：

• 功能单一：传统RTOS主要提供任务调度和基本通信，缺乏图形界面、多媒体、网络协议栈等上层服务
• 生态封闭：每个RTOS都有自己的API和开发工具，互不兼容，开发者需要为每个平台重新学习
• 不支持分布式：设备之间是孤立的，无法协同工作
• 缺乏智能化：没有AI推理框架，不具备端侧AI能力

3.1.2 新时代的需求

2019年的技术格局提出了三个新的需求，现有的操作系统都无法同时满足：

需求一：全场景覆盖

用户身边的计算设备越来越多样。智能手机、平板、智能手表、智能音箱、智能电视、车载系统、智能家居……这些设备的计算能力从MCU级别到旗舰手机级别，差异巨大。没有任何一个现有操作系统能够同时覆盖这个完整的设备谱系。

理想的状态是：所有这些设备运行"同一个"操作系统——不是功能完全相同的同一个，而是架构统一、接口一致、体验连贯的同一个。

需求二：分布式协同

设备之间的协同不应该是一种"附加功能"，而应该是操作系统架构层面的基本能力。应用开发者不需要关心数据在哪个设备上、计算在哪个设备上执行——操作系统应该透明地管理跨设备的资源调度和数据同步。

用分布式系统的术语来说，操作系统应该提供一个透明的分布式编程模型。

需求三：面向AI演进

端侧AI正在快速发展。AI推理不再完全依赖云端，越来越多的AI能力部署在设备端。操作系统需要为端侧AI提供原生支持——包括AI推理框架、异构算力调度、模型生命周期管理等。

这三个需求，构成了开源鸿蒙诞生的驱动力。

3.1.3 鸿蒙OS与开源鸿蒙的关系

在深入开源鸿蒙之前，需要先厘清一个容易混淆的概念：**鸿蒙OS（HarmonyOS）和开源鸿蒙（OpenHarmony）**是两个不同的东西。

┌──────────────────────────────────────────────┐
│          鸿蒙OS（HarmonyOS）                  │
│          华为公司的商业发行版                   │
│                                              │
│  ┌────────────────────────────────────────┐  │
│  │       开源鸿蒙（OpenHarmony）          │  │
│  │       开源基础                         │  │
│  │  ┌──────────────────────────────┐     │  │
│  │  │  LiteOS-M / LiteOS-A / Linux │     │  │
│  │  │  内核层                      │     │  │
│  │  └──────────────────────────────┘     │  │
│  └────────────────────────────────────────┘  │
│                                              │
│  + 华为闭源增值功能：                         │
│    华为应用市场、华为云服务、Celia语音助手、   │
│    华为移动服务（HMS）、HarmonyOS NEXT特性     │
└──────────────────────────────────────────────┘

关键区别：

维度	开源鸿蒙（OpenHarmony）	鸿蒙OS（HarmonyOS）
性质	开源项目	商业操作系统
运营方	开放原子开源基金会	华为公司
代码	完全开源	基于OpenHarmony + 华为闭源组件
生态	开放生态，多厂商共建	华为生态 + 开放生态
硬件支持	理论上支持所有兼容硬件	主要支持华为/荣耀设备
定位	操作系统的基础能力平台	面向消费者的完整产品

打个比方：OpenHarmony就像Linux内核——它是一个开源的基础软件项目；HarmonyOS就像Ubuntu或Red Hat——它是基于这个基础构建的商业发行版。一个公司可以使用OpenHarmony来构建自己的商业操作系统，而不需要与华为的HarmonyOS有任何关系。

本书重点关注OpenHarmony，因为它是开源的、面向全行业的、技术架构的核心。理解了OpenHarmony，就理解了鸿蒙OS的技术底座。

---

3.2 开放原子开源基金会

3.2.1 基金会的定位

开放原子开源基金会（OpenAtom Foundation）成立于2020年6月，是中国首个开源领域的基金会。它由华为、阿里、腾讯、百度、小米、浪潮、360、OPPO等企业联合发起，接受中国工业和信息化部的业务指导。

基金会的核心使命是：

• 运营开源项目：接受、管理和运营开源项目的代码资产
• 建设开源生态：促进开源社区的发展和壮大
• 推动标准制定：通过开源实践推动行业标准
• 国际化推广：推动中国开源项目的全球影响力

3.2.2 基金会运营的主要项目

开放原子开源基金会运营着多个重要的开源项目：

项目	定位	主要贡献者
OpenHarmony	全场景分布式操作系统	华为
OpenBlockUtils	区块链工具链	多家
Pika	分布式NewSQL数据库	百度
Tupperware	容器编排系统	华为
XiUOS	工业物联网操作系统	中科院

OpenHarmony是基金会运营的旗舰项目之一，也是目前最受关注的项目。

3.2.3 基金会对OpenHarmony的意义

将OpenHarmony捐赠给开放原子开源基金会是一个关键的战略决策：

中立性：操作系统由一个中立的非营利组织运营，而非某个公司。这降低了其他厂商参与的顾虑——他们不用担心被某个竞争对手控制

开放性：任何公司和个人都可以参与OpenHarmony的开发和生态建设，贡献代码、提交需求、参与决策

可持续性：即使华为遇到困难，OpenHarmony项目也能独立存在和发展，不会因为单个公司的状况而中断

标准化：基金会有助于推动OpenHarmony相关的技术标准制定，提升其行业影响力

---

3.3 开源鸿蒙的版本演进

开源鸿蒙自2020年开源以来，经历了快速的版本迭代。以下是关键的版本演进时间线：

3.3.1 版本演进总览

2020.09 ── OpenHarmony 1.0
    │        首个开源版本，LiteOS-M内核
    │        支持WiFi基础能力
    │
2021.06 ── OpenHarmony 2.0
    │        新增LiteOS-A内核
    │        支持标准系统能力（窗口、图形）
    │        方舟开发框架初版
    │
2021.09 ── OpenHarmony 3.0 LTS
    │        标准系统能力完善
    │        方舟开发框架（ArkUI + ArkTS）发布
    │        增强分布式能力
    │
2022.03 ── OpenHarmony 3.1
    │        API 8发布
    │        增强文件管理、窗口管理
    │
2022.09 ── OpenHarmony 3.2
    │        ArkUI跨设备能力增强
    │        分布式软总线优化
    │
2023.04 ── OpenHarmony 4.0 Beta
    │        API 9发布
    │        ArkTS声明式UI成熟
    │        Stage模型正式发布
    │        应用隐私保护增强
    │
2023.10 ── OpenHarmony 4.1
    │        系统安全增强
    │        应用沙箱隔离改进
    │        文件访问权限精细化
    │
2024.01 ── OpenHarmony 4.2
    │        ArkUI-X（跨平台能力）
    │        元服务（免安装、即用即走）
    │        分布式能力进一步优化
    │
2024.09 ── OpenHarmony 5.0（NEXT）
    │        API 12发布
    │        GDM系统（全局设备管理）
    │        系统性能大幅优化
    │        分布式软总线架构升级
    │        开发工具链完善
    │
2025.x  ── 后续版本持续演进中

3.3.2 关键里程碑解读

里程碑一：开源发布（2020年9月）

2020年9月10日，在华为开发者大会上，华为宣布将HarmonyOS的核心基础能力捐赠给开放原子开源基金会，形成OpenHarmony开源项目。OpenHarmony 1.0同日发布。

这次开源的意义不仅在于代码的开放，更在于释放了一个明确的信号：华为不是在独自做操作系统，而是在发起一个面向全行业的开源项目。

里程碑二：方舟开发框架发布（2021年9月）

OpenHarmony 3.0 LTS 发布了方舟开发框架（ArkUI + ArkTS），这是开源鸿蒙生态建设的关键一步：

• ArkTS：基于TypeScript扩展的声明式开发语言，提供了类型安全和编译时优化
• ArkUI：声明式UI框架，支持响应式布局和组件化开发

方舟开发框架的意义在于：它为开发者提供了一个统一的、现代的开发体验，而不是要求开发者学习多个不同的框架来适配不同的设备。

里程碑三：Stage模型发布（2023年4月）

OpenHarmony 4.0 Beta 引入了Stage模型，这是应用开发架构的一次重要演进。Stage模型相比之前的FA（Feature Ability）模型，提供了更清晰的应用生命周期管理、更灵活的组件组织和更强的多进程隔离。

Stage模型的设计借鉴了Android和iOS的优秀实践，同时结合了分布式场景的特殊需求，为跨设备应用开发提供了更好的基础。

里程碑四：OpenHarmony 5.0 NEXT（2024年9月）

这是目前最具标志性的版本更新。5.0版本代表了开源鸿蒙从一个"有潜力的开源项目"向"可商用的操作系统平台"的跨越：

• API 12：提供了更丰富和稳定的API
• GDM系统：全局设备管理，使多设备协同更加智能化
• 性能优化：系统启动速度、应用启动速度、动画流畅度等关键指标大幅提升
• 软总线升级：分布式软总线的连接速度和稳定性显著改善
• 工具链完善：DevEco Studio的调试、测试、性能分析工具更加成熟

这个版本也是华为HarmonyOS NEXT（纯血鸿蒙）的技术基础。HarmonyOS NEXT完全放弃了Android兼容层，全面基于OpenHarmony构建。

3.3.3 版本演进的设计哲学

从版本演进中可以提炼出开源鸿蒙的几个设计哲学：

渐进式发展：开源鸿蒙没有试图一步到位地构建一个完美的操作系统，而是从一个基础框架开始，逐步添加能力。先确保LiteOS内核可靠，再建设应用框架；先支持基本设备类型，再扩展到更多场景。

架构先行：每一轮版本更新都优先完善架构层面的设计（KAL、HDF、Stage模型），而非仅仅添加功能。好的架构是长期发展的基础。

生态同步：在完善系统功能的同时，持续建设开发者生态——开发工具、文档、示例、社区。操作系统的成功离不开生态的支持。

---

3.4 开源鸿蒙的核心设计理念

3.4.1 分布式优先

开源鸿蒙最独特的设计理念是**“分布式优先”（Distributed First）**。

传统操作系统的设计假设是"一台设备 = 一个操作系统 = 一个用户"。系统内的所有资源（CPU、内存、文件）都属于这台设备。

开源鸿蒙的设计假设是"一个用户 = 多个设备 = 一个超级终端"。多个设备在操作系统的视角下是一个逻辑上的整体，设备之间的边界对应用是透明的。

"分布式优先"在架构上的体现：

传统OS的架构视角：
  设备A（手机）  ←→  设备B（平板）  ←→  设备C（手表）
  各自独立，通过协议桥接

开源鸿蒙的架构视角：
  ┌─────────────────────────────────────┐
  │         超级终端（一个逻辑系统）      │
  │                                     │
  │  手机(A)  平板(B)  手表(C)  电视(D)  │
  │    └───────┴───────┴───────┘        │
  │            分布式软总线               │
  │     （内建的、统一的、透明的）        │
  └─────────────────────────────────────┘

这意味着：

• 一个应用可以同时使用多个设备的资源（如用手表的传感器 + 手机的计算能力 + 电视的屏幕）
• 数据在设备之间自动同步，应用不需要关心数据存在哪个设备上
• 用户任务可以在设备之间无缝流转（如在手机上开始编辑文档，在平板上继续）

"分布式优先"不是在传统OS上加一层分布式协议，而是从操作系统内核和系统服务的层面重新设计，使分布式能力成为操作系统的基本能力。

3.4.2 统一体验

**“统一体验”**指的是跨设备的一致性——一致的界面风格、一致的操作方式、一致的数据模型。

实现统一体验的关键技术手段：

ArkTS + ArkUI：统一的开发语言和UI框架。开发者用一套代码和工具开发应用，系统自动适配不同设备的屏幕尺寸、交互方式和性能水平。

资源适配机制：系统根据设备的屏幕大小、内存大小、CPU性能等自动选择合适的资源（图片分辨率、动画复杂度、功能开关等）。

统一的系统服务：无论设备运行的是LiteOS-M内核还是Linux内核，上层应用面对的API是一致的。KAL（内核抽象层）屏蔽了底层内核的差异。

3.4.3 全场景覆盖

**“全场景覆盖”**的目标是用一套操作系统架构覆盖从MCU到手机的完整设备谱系：

┌─────────────────────────────────────────────────────┐
│                  全场景设备谱系                        │
│                                                     │
│  资源极受限    资源受限      资源适中     资源丰富     │
│  (<1MB)      (1-128MB)    (128MB-1GB)  (>1GB)      │
│                                                     │
│  传感器    智能灯泡    智能手表    智能音箱   手机/平板 │
│  智能门锁  温湿度计    智能手环    摄像头    电视/车机 │
│                                                     │
│  ┌──────┬───────┬───────┬───────┬───────┐           │
│  │LiteOS│LiteOS │LiteOS │LiteOS │Linux  │           │
│  │  -M  │  -M   │  -A   │  -A   │       │           │
│  └──────┴───────┴───────┴───────┴───────┘           │
│        ↑         ↑         ↑         ↑               │
│        └─────────┴─────────┴─────────┘               │
│                  内核抽象层（KAL）                     │
│                  统一API接口                          │
└─────────────────────────────────────────────────────┘

三种内核覆盖不同的设备资源范围：

• LiteOS-M：面向MCU级设备，资源占用极小，支持强实时性
• LiteOS-A：面向MPU级设备，提供更丰富的系统能力
• Linux：面向资源丰富的设备，功能最完整

KAL（内核抽象层）在三种内核之上提供统一的API，使上层应用和服务不依赖特定内核。

3.4.4 开放生态

开源鸿蒙的第四个设计理念是开放生态：

• 代码开源：核心代码在开放原子开源基金会的Gitee仓库上公开，任何人可以查看、下载、贡献
• 标准开放：积极参与行业标准制定，推动技术标准的开放
• 生态共建：欢迎所有厂商、开发者和用户参与生态建设
• 多厂商参与：不限于华为，已有小米、OPPO、vivo、荣耀、魅族等多家厂商宣布支持或适配OpenHarmony

---

3.5 开源鸿蒙与其他操作系统的对比

3.5.1 与Android对比

架构层面：

维度	Android	开源鸿蒙
内核	Linux（宏内核）	多内核（LiteOS-M/A + Linux）
内核抽象	无统一抽象层	KAL内核抽象层
IPC机制	Binder（单设备）	分布式软总线（跨设备）
应用框架	Activity/Service/Broadcast/Content	Page/Service/Data Ability
开发语言	Java → Kotlin	ArkTS（TypeScript扩展）
UI框架	View系统 → Jetpack Compose	ArkUI（声明式）
分布式能力	外挂式（Nearby API）	内建式（软总线+数据管理+硬件平台）
设备覆盖	手机/平板/电视/手表/车载	MCU → 手机全谱系

生态层面：

• Android：拥有超过20年的生态积累，应用数百万，开发者社区成熟，但碎片化严重
• 开源鸿蒙：生态建设初期，应用数量较少，但增长迅速。分布式能力是差异化优势

关键差异：Android本质上是一个"面向手机的操作系统+跨设备扩展"，而开源鸿蒙是"面向全场景的分布式操作系统"。这个根本定位的差异决定了两者的架构走向不同。

3.5.2 与iOS对比

架构层面：

维度	iOS	开源鸿蒙
内核	XNU（混合内核）	多内核（LiteOS-M/A + Linux）
应用模型	App + Extension	Ability（Page/Service/Data）
开发语言	Objective-C → Swift	ArkTS
UI框架	UIKit → SwiftUI	ArkUI
分布式能力	Handoff/AirDrop（有限）	分布式软总线（全面）
硬件范围	Apple设备（封闭）	多厂商设备（开放）

生态层面：

• iOS：封闭但精致，用户体验一致性好，应用质量高
• 开源鸿蒙：开放生态，多厂商共建，覆盖设备范围更广

3.5.3 与传统嵌入式OS对比

维度	FreeRTOS	QNX	开源鸿蒙
内核类型	微内核RTOS	微内核RTOS	多内核（RTOS + 通用）
内核大小	~10KB	~100KB	视内核而定
上层服务	基本调度和通信	文件系统、网络等	图形、媒体、分布式等完整服务
分布式	无	有限支持	核心设计目标
AI能力	无	无	集成推理框架
开发框架	C语言	C/C++	ArkTS + ArkUI
设备范围	MCU	汽车、工业	MCU → 手机全谱系

关键差异：传统RTOS是"面向特定场景的专用系统"，开源鸿蒙是"面向全场景的统一系统"。LiteOS-M可以理解为FreeRTOS的增强版（保留了轻量和实时的特性，同时增加了与上层服务的统一接口），但整个开源鸿蒙的架构远超RTOS的范畴。

3.5.4 与其他微内核OS对比

维度	seL4	Fuchsia/Zircon	开源鸿蒙
设计目标	形式化验证的安全内核	通用微内核OS	全场景分布式OS
安全验证	数学证明（最高级别）	无	部分安全机制借鉴seL4理念
分布式	无	内建（Capability-based）	核心设计（软总线等）
设备覆盖	嵌入式	智能设备	MCU → 手机全谱系
实时性	支持	支持	LiteOS-M/A强实时
生态	军工/航空	Google内部	中国全行业
内核数量	单内核	单内核	三内核（KAL统一）

关键差异：开源鸿蒙的独特之处在于"微内核架构 + 全场景覆盖 + 分布式优先"三个特性的组合。seL4追求极致安全但生态有限，Fuchsia追求现代架构但尚未大规模部署，开源鸿蒙则试图在安全性、覆盖范围和生态建设之间取得平衡。

---

3.6 本章小结

关键要点回顾：

1. 开源鸿蒙诞生的根本原因：现有操作系统（Android/iOS/传统RTOS）无法同时满足全场景覆盖、分布式协同、面向AI演进三个需求
2. 鸿蒙OS ≠ 开源鸿蒙：鸿蒙OS是华为的商业发行版，开源鸿蒙是开放原子基金会运营的开源基础项目。理解这个区别很重要
3. 版本演进：从2020年OpenHarmony 1.0到2024年5.0，经历了从基础内核到完整系统的快速演进
4. 四个核心设计理念：分布式优先、统一体验、全场景覆盖、开放生态
5. 差异化定位：与Android（面向手机的OS）、iOS（封闭生态）、传统RTOS（专用系统）相比，开源鸿蒙是唯一面向全场景的分布式操作系统

下一章预告：第4章将深入开源鸿蒙的内部架构——从应用层到硬件抽象层，逐层剖析其架构设计和各层职责。