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

第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与开源鸿蒙的关系在深入开源鸿蒙之前需要先厘清一个容易混淆的概念**鸿蒙OSHarmonyOS和开源鸿蒙OpenHarmony**是两个不同的东西。┌──────────────────────────────────────────────┐ │ 鸿蒙OSHarmonyOS │ │ 华为公司的商业发行版 │ │ │ │ ┌────────────────────────────────────────┐ │ │ │ 开源鸿蒙OpenHarmony │ │ │ │ 开源基础 │ │ │ │ ┌──────────────────────────────┐ │ │ │ │ │ LiteOS-M / LiteOS-A / Linux │ │ │ │ │ │ 内核层 │ │ │ │ │ └──────────────────────────────┘ │ │ │ └────────────────────────────────────────┘ │ │ │ │ 华为闭源增值功能 │ │ 华为应用市场、华为云服务、Celia语音助手、 │ │ 华为移动服务HMS、HarmonyOS NEXT特性 │ └──────────────────────────────────────────────┘关键区别维度开源鸿蒙OpenHarmony鸿蒙OSHarmonyOS性质开源项目商业操作系统运营方开放原子开源基金会华为公司代码完全开源基于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.0NEXT │ 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模型相比之前的FAFeature Ability模型提供了更清晰的应用生命周期管理、更灵活的组件组织和更强的多进程隔离。Stage模型的设计借鉴了Android和iOS的优秀实践同时结合了分布式场景的特殊需求为跨设备应用开发提供了更好的基础。里程碑四OpenHarmony 5.0 NEXT2024年9月这是目前最具标志性的版本更新。5.0版本代表了开源鸿蒙从一个有潜力的开源项目向可商用的操作系统平台的跨越API 12提供了更丰富和稳定的APIGDM系统全局设备管理使多设备协同更加智能化性能优化系统启动速度、应用启动速度、动画流畅度等关键指标大幅提升软总线升级分布式软总线的连接速度和稳定性显著改善工具链完善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、荣耀、魅族等多家厂商宣布支持或适配OpenHarmony3.5 开源鸿蒙与其他操作系统的对比3.5.1 与Android对比架构层面维度Android开源鸿蒙内核Linux宏内核多内核LiteOS-M/A Linux内核抽象无统一抽象层KAL内核抽象层IPC机制Binder单设备分布式软总线跨设备应用框架Activity/Service/Broadcast/ContentPage/Service/Data Ability开发语言Java → KotlinArkTSTypeScript扩展UI框架View系统 → Jetpack ComposeArkUI声明式分布式能力外挂式Nearby API内建式软总线数据管理硬件平台设备覆盖手机/平板/电视/手表/车载MCU → 手机全谱系生态层面Android拥有超过20年的生态积累应用数百万开发者社区成熟但碎片化严重开源鸿蒙生态建设初期应用数量较少但增长迅速。分布式能力是差异化优势关键差异Android本质上是一个面向手机的操作系统跨设备扩展而开源鸿蒙是面向全场景的分布式操作系统。这个根本定位的差异决定了两者的架构走向不同。3.5.2 与iOS对比架构层面维度iOS开源鸿蒙内核XNU混合内核多内核LiteOS-M/A Linux应用模型App ExtensionAbilityPage/Service/Data开发语言Objective-C → SwiftArkTSUI框架UIKit → SwiftUIArkUI分布式能力Handoff/AirDrop有限分布式软总线全面硬件范围Apple设备封闭多厂商设备开放生态层面iOS封闭但精致用户体验一致性好应用质量高开源鸿蒙开放生态多厂商共建覆盖设备范围更广3.5.3 与传统嵌入式OS对比维度FreeRTOSQNX开源鸿蒙内核类型微内核RTOS微内核RTOS多内核RTOS 通用内核大小~10KB~100KB视内核而定上层服务基本调度和通信文件系统、网络等图形、媒体、分布式等完整服务分布式无有限支持核心设计目标AI能力无无集成推理框架开发框架C语言C/CArkTS ArkUI设备范围MCU汽车、工业MCU → 手机全谱系关键差异传统RTOS是面向特定场景的专用系统开源鸿蒙是面向全场景的统一系统。LiteOS-M可以理解为FreeRTOS的增强版保留了轻量和实时的特性同时增加了与上层服务的统一接口但整个开源鸿蒙的架构远超RTOS的范畴。3.5.4 与其他微内核OS对比维度seL4Fuchsia/Zircon开源鸿蒙设计目标形式化验证的安全内核通用微内核OS全场景分布式OS安全验证数学证明最高级别无部分安全机制借鉴seL4理念分布式无内建Capability-based核心设计软总线等设备覆盖嵌入式智能设备MCU → 手机全谱系实时性支持支持LiteOS-M/A强实时生态军工/航空Google内部中国全行业内核数量单内核单内核三内核KAL统一关键差异开源鸿蒙的独特之处在于微内核架构 全场景覆盖 分布式优先三个特性的组合。seL4追求极致安全但生态有限Fuchsia追求现代架构但尚未大规模部署开源鸿蒙则试图在安全性、覆盖范围和生态建设之间取得平衡。3.6 本章小结关键要点回顾开源鸿蒙诞生的根本原因现有操作系统Android/iOS/传统RTOS无法同时满足全场景覆盖、分布式协同、面向AI演进三个需求鸿蒙OS ≠ 开源鸿蒙鸿蒙OS是华为的商业发行版开源鸿蒙是开放原子基金会运营的开源基础项目。理解这个区别很重要版本演进从2020年OpenHarmony 1.0到2024年5.0经历了从基础内核到完整系统的快速演进四个核心设计理念分布式优先、统一体验、全场景覆盖、开放生态差异化定位与Android面向手机的OS、iOS封闭生态、传统RTOS专用系统相比开源鸿蒙是唯一面向全场景的分布式操作系统下一章预告第4章将深入开源鸿蒙的内部架构——从应用层到硬件抽象层逐层剖析其架构设计和各层职责。