鸿蒙操作系统简介

华为鸿蒙系统（HUAWEI HarmonyOS），是华为公司于2019年8月9日在东莞举行的华为开发者大会（HDC.2019）上正式发布的面向全场景的分布式操作系统，可以创造一个超级虚拟终端互联的世界，将人、设备、场景有机地联系在一起，将消费者在全场景生活中接触的多种智能终端，实现极速发现、极速连接、硬件互助、资源共享，用合适的设备提供场景体验。

2019年8月9日，华为在东莞举行华为开发者大会，正式发布操作系统鸿蒙OS。2020年9月10日，华为鸿蒙系统升级至HarmonyOS 2.0。2021年12月17日，鸿蒙HarmonyOS 2提前完成所有既定产品的正式版本上线，并且已有上百款华为、荣耀设备升级到了鸿蒙HarmonyOS 2正式版。2022年7月27日，华为发布鸿蒙HarmonyOS 3系统。2023年8月4日下午，在2023华为开发者大会上，HarmonyOS 4正式发布。2024年1月18日，华为发布原生鸿蒙操作系统星河版。2024年10月22日，华为原生鸿蒙系统HarmonyOS NEXT 5.0发布，这是中国首个实现全栈自研的操作系统，标志着中国在操作系统领域取得突破性进展。

2021年9月23日，华为官宣鸿蒙系统升级用户已经突破1.2亿，10月22日，搭载鸿蒙OS的设备数量已达1.5亿台。2022年11月4日，搭载HarmonyOS的华为设备已达3.2亿。截至2024年10月20日，搭载HarmonyOS的鸿蒙生态设备已超过10亿台，鸿蒙生态已有超15000个应用及元服务完成上架，覆盖办公、社交、娱乐等18个垂直领域。

HarmonyOS 1.0

在2019年的开发者大会上，华为发布了EMUI 10，同时也宣告了鸿蒙1.0的诞生，华为的全场景理念又向前推进了一步。2019年8月9号，华为正式发布的HarmonyOS 1.0，该系统率先部署在智慧屏上，此时的鸿蒙系统只搭载在家用电器上，尚未搭载导手机系统中，但华为消费业务CEO余承东在发布会上宣布鸿蒙将进行开源。由此可以看出华为对于手机系统的重心已经开始由EMUI转移到鸿蒙系统上了。

HarmonyOS 2.0

与鸿蒙1.0版本相比，鸿蒙2.0在分布式软总线、分布式数据管理、分布式安全等分布式能力上进行了升级，同时发布了自适应的UX（用户体验）框架，让开发者能够非常简单且快速地开发鸿蒙应用程序。

鸿蒙操作系统是一款面向全场景分布式操作系统。鸿蒙操作系统不同于现有的Android、iOS、Windows、Linux等操作系统，它设计的初衷是解决在5G万物互联时代，各个系统间的连接问题。鸿蒙操作系统面向的是1+8+N的全场景设备，能够根据不同内存级别的设备进行弹性组装和适配，并且实现跨设备交互信息。其中，1指的是手机；8代表车机、音箱、耳机、手表/手环、平板、智慧屏、PC、AR/VR；N泛指其他IoT设备。

HarmonyOS 2.0是基于Linux系统来开发自研操作系统的。这样有两大好处：一是可以很好地兼容安卓系统的App，毕竟安卓系统是基于Linux系统来开发的，这样在生态上的问题就解决了很大一部分了。

HarmonyOS 2.0系统整体遵从分层设计，如图1-11所示，从下向上依次为内核层、系统服务层、框架层和应用层。在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统、功能或者模块。

内核层

HarmonyOS 2.0内核层由鸿蒙微内核、Linux内核、Lite OS组成，未来将发展为完全的鸿蒙微内核架构。

HarmonyOS 2.0采用多内核设计，支持针对不同资源受限设备选用不同的OS内核。内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

系统服务层系统

服务层是HarmonyOS 2.0的核心能力集合，通过框架层对应用程序提供服务。该层包含以下几部分。（1）系统基本能力子系统集：为分布式应用在HarmonyOS多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、公共基础库、多模输入、图形、安全、AI等子系统组成。（2）基础软件服务子系统集：为HarmonyOS提供公共的、通用的软件服务，由事件通知、电话、多媒体、DFX、MSDP（组播源发现协议）&DV等子系统组成。（3）增强软件服务子系统集：为HarmonyOS提供针对不同设备的、差异化的能力增强型软件服务，由智慧屏专有业务、穿戴专有业务、IoT专有业务等子系统组成。（4）硬件服务子系统集：为HarmonyOS提供硬件服务，由位置服务、生物特征识别、穿戴专有硬件服务、IoT专有硬件服务等子系统组成。

框架层

框架层为HarmonyOS 2.0的应用程序提供了Java、C、C++、JavaScript等多语言的用户程序框架和Ability框架，如图1-13所示，以及各种软硬件服务对外开放的多语言框架API；同时为采用HarmonyOS的设备提供了C、C++、JavaScript等多语言的框架API，不同设备支持的API与系统的组件化裁剪程度相关。

ACE

ACE全称为Ability Cross-platform Environment，是鸿蒙面向元能力（Ability）开发的跨平台运行环境。ACE是为华为鸿蒙操作系统定制设计的一套针对全场景环境的跨平台应用开发框架。ACE支持目前两种主流语言：Java和JavaScript。未来将支持华为自己的开发语言“仓颉”。

可以把这些IoT终端设备分为富设备和轻设备，对于富设备开发鸿蒙提供了基于Java、C++语言的开发框架，对于一些内存有限，功能有限的轻设备则提供了基于JavaScript的开发框架，这样可以让一些低端硬件配置的IoT设备运行鸿蒙应用程序。

ACE支持的两种UI框架

鸿蒙跨平台运行时（ACE）为Java开发者和JavaScript开发者提供了一站式的开发环境。

1．基于Java的应用开发框架（ACE Java UI）

鸿蒙的应用开发可以基于Java语言+XML的方式进行开发，此方式和安卓类似，如果开发者熟悉Java语言或者Android开发，那么使用此方式可以很快进行应用开发。ACE Java UI框架的架构图如图3-2所示。

2．基于JavaScript的应用开发框架（ACE JavaScript UI）

鸿蒙开发同时还提供了JavaScript形式的开发。JavaScript的语法规则基本遵循ES6的语法规范。如果是前端开发人员，则可以使用HTML+CSS+JavaScript的形式进行应用的开发，但是对于后端一些服务能力，目前只能使用Java语言进行开发，所以对于JavaScript的开发者，依然需要Java语言的辅助。ACE JavaScript UI框架的架构图如图3-3所示。

ACE开发中的核心概念

在学习ACE开发框架前，需要了解ACE中的一些核心概念。

Ability和Slice

Ability是HarmonyOS开发的核心，首先了解什么是Ability，我们用生活中的例子来做一个类比，Ability就好像是一个画板，初始什么都没有，一片空白，我们可以找一张画纸进行绘画，画完的画纸夹在画板上，画板上就会有我们创作的图画了。HarmonyOS中的Ability其实就相当于画板，它用来承载画纸，那么画纸又是什么？标题中还有一个Slice，它就相当于画纸，我们写应用的UI，写完后通过Slice加载布局，就相当于在画纸上绘画，完成后把画纸放在画板上进行展示。

将对应的概念引申到程序中，我们有一个Ability（画板）用来向用户展示新闻，同时这个Ability拥有两个Slice（画纸），一个用来展示新闻标题，另一个用来展示新闻详情。那么我们就需要在这两个Slice中分别画上新闻的标题和详情，然后通过单击或其他交互方式来切换两个Slice，相当于给画板换另一张画纸。

Ability分类

有了上述概念，我们基本知道Ability能做些什么了，但是还要具体了解一下这个核心组件，在HarmonyOS中，Ability可以分为两类，一类叫FA（Feature Ability），另一类叫作PA（Particle Ability），这两类Ability最直观的区别是FA有界面，可以和用户交互，而PA无界面，它提供一些应用运行需要的能力，例如读取数据。这两类Ability在创建的时候都有相应的模板。

Ability的模板种类。

（1）对于FA类型的Ability，Page类型的模板是其唯一的模板类型，这种类型的模板提供了和用户交互的能力。

（2）对于PA类型的Ability，它有三类模板。

● Service Ability：用于提供后台运行任务的能力。

● Data Ability：用于对外部提供统一的数据访问抽象。

● FormAbility：是卡片Ability，是一种界面展示形式。

FA模型的生命周期

在所有Ability中，PageAbility因为具有界面，也是应用的交互入口，因此生命周期更加复杂。PageAbility的生命周期回调如图2-2所示。其他类型Ability的生命周期可参考PageAbility生命周期去除前后台切换以及onShow的部分进行理解。开发者可以在app.ets中重写生命周期函数，在对应的生命周期函数内处理应用相应逻辑。

FA模型的进程线程模型

应用独享独立进程，Ability独享独立线程，应用进程在Ability第一次启动时创建，并为启动的Ability创建线程，应用启动后再启动应用内其他Ability，会为每个Ability创建相应的线程。每个Ability绑定一个独立的JSRuntime实例，因此Ability之间是隔离的，如图2-3所示。

应用层

应用层包括系统应用和第三方非系统应用。HarmonyOS 2.0的应用由一个或多个FA （Feature Ability）或PA（Particle Ability）组成。其中，FA有UI界面，其提供与用户交互的能力，而PA则无UI界面，提供后台运行任务的能力及统一的数据访问抽象。基于FA/PA开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验，如图1-14所示。

鸿蒙应用包结构

鸿蒙应用软件包以App Pack（Application Package）形式发布，它是由一个或多个HAP （HarmonyOS Ability Package）及描述每个HAP属性的pack.info组成。HAP是Ability的部署包，HarmonyOS应用代码围绕Ability组件展开。一个HAP是由代码、资源、第三方库及应用配置文件组成的模块包，可分为entry和feature两种模块类型，如图3-4所示。

entry：应用的主模块。在一个App中，对于同一设备类型必须有且只有一个entry类型的HAP，可独立安装运行。

feature：应用的动态特性模块。一个App可以包含一个或多个feature类型的HAP，也可以不含。只有包含Ability的HAP才能够独立运行。

HarmonyOS 3.0

HarmonyOS 3.1全新推出了应用开发Stage模型，并在ArkTS语言、应用程序框架、Web、ArkUI等子系统能力方面有所更新或增强。

HarmonyOS 3.1开放的功能包括：

· Ability框架新增Stage开发模型，包含Stage模型生命周期管理、调度、回调、上下文获取、鉴权等。同时增强了应用的运行管理能力。

· ArkUI开发框架增强了声明式Canvas/XComponent组件能力，增强了组件布局能力及状态管理能力，优化了部分组件的易用性。

· 应用包管理新增查询应用、Ability和ExtensionAbility相关属性的接口。

· 公共基础类库新增支持Buffer二进制读写。

· Web服务新增支持文档类Web应用的文档预览和基础编辑功能，以及Cookie的管理和存储管理。

· 图形图像新增支持YUV、WebP图片编解码等能力；新增Native Vsync能力，支持自绘制引擎自主控制渲染节奏。

· 媒体服务新增相机配置与预览功能。

· 窗口服务新增Stage模型下窗口相关接口，增强了窗口旋转能力，增强了避让区域查询能力。· 全球化服务新增支持时区列表、音译、电话号码归属地等国际化增强能力。

· 公共事件基础能力增强，commonEvent模块变更为commonEventManager。

· 资源管理服务新增资源获取的同步接口，新增基于名称查询资源值的接口，新增number、float资源类型查询接口，新增Stage模型资源查询方式。

· 输入法服务新增输入法光标方向常量。

应用模型

HarmonyOS应用模型的构成要素如下。

· 应用组件：应用组件是应用的基本组成单位，是应用的运行入口。用户启动、使用和退出应用的过程中，应用组件会在不同的状态间切换，这些状态称为应用组件的生命周期。应用组件提供生命周期的回调函数，开发者通过应用组件的生命周期回调感知应用的状态变化。应用开发者在编写应用时，首先需要编写应用组件，同时还需要编写应用组件的生命周期回调函数，并在应用配置文件中配置相关信息。这样，操作系统在运行期间可以通过配置文件创建应用组件的实例，并调度它的生命周期回调函数，从而执行开发者的代码。

· 应用进程模型：应用进程模型定义应用进程的创建和销毁方式，以及进程间的通信方式。

· 应用线程模型：应用线程模型定义应用进程内线程的创建和销毁方式、主线程和UI线程的创建方式、线程间的通信方式。

· 应用任务管理模型：应用任务管理模型定义任务(Mission)的创建和销毁方式，以及任务与组件间的关系。HarmonyOS应用任务管理由系统应用负责，第三方应用无须关注。

· 应用配置文件：应用配置文件中包含应用配置信息、应用组件信息、权限信息、开发者自定义信息等，这些信息在编译构建、分发和运行阶段分别提供给编译工具、应用市场和操作系统使用。

截至目前，在HarmonyOS中，Ability框架模型结构具有以下两种形态。

· FA模型：API 8及更早版本的应用程序只能使用FA模型进行开发。

· Stage模型：从API 9开始，Ability框架引入并支持使用Stage模型进行开发，也是目前HarmonyOS所推荐的开发方式。FA模型和Stage模型的工程目录结构存在差异，Stage模型目前只支持使用ArkTS语言进行开发。

Stage模型介绍

Stage 模型：是为了解决FA模型无法解决的开发场景问题，方便开发者更加方便地开发出分布式环境下的复杂应用。自 API9 新增的模型。是日后长期演进的模型。

在该模型中，由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”，因此称这种应用模型为Stage模型。

Stage模型将Ability分为PageAbility和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等一系列ExtensionAbility，以便满足更多的使用场景。

Stage模型的设计思想

1 为复杂应用而设计Stage模型简化了应用复杂度：

· 多个应用组件共享同一个ArkTS引擎（运行ArkTS语言的虚拟机）实例，应用组件之间可以方便地共享对象和状态，同时减少复杂应用运行对内存的占用。

· 采用面向对象的开发方式，使得复杂的应用代码可读性高、易维护性好、可扩展性强。

2 支持多设备和多窗口形态Stage模型应用组件管理和窗口管理在架构层面解耦：

· 便于系统对应用组件进行裁剪（无屏设备可裁剪窗口）。

· 便于系统扩展窗口形态。

· 在多设备（如桌面设备和移动设备）上，应用组件可使用同一套生命周期。

3 平衡应用能力和系统管控成本Stage模型重新定义了应用能力的边界，平衡了应用能力和系统管控成本。

· 提供特定场景（如卡片、输入法）的应用组件，以便满足更多的使用场景。

· 规范化后台进程管理：为保障用户体验，Stage模型对后台应用进程进行了有序治理，应用程序不能随意驻留在后台，同时应用后台行为受到严格管理，防止恶意应用行为。

系统定义了四类后台任务：

Stage模型的Ability生命周期

在Ability的使用过程中，会有多种生命周期状态。掌握Ability的生命周期对于应用的开发非常重要。为了实现多设备形态上的裁剪和多窗口的可扩展性，系统对组件管理和窗口管理进行了解耦。Ability的生命周期包括Create、Foreground、Background、Destroy四个状态，WindowStageCreate和WindowStageDestroy为窗口管理器(WindowStage)在Ability中管理UI界面功能的两个生命周期回调，从而实现Ability与窗口之间的弱耦合，如图2-4所示。

Stage模型的Ability启动模式

Ability的启动模式是指Ability实例在启动时的不同呈现状态。针对不同的业务场景，系统提供了3种启动模式：

· singleton（单实例模式）。

· standard（标准实例模式）。

· specified（指定实例模式）。

1 singleton启动模式

singleton是默认情况下的启动模式。每次调用startAbility()方法时，如果应用进程中该类型的Ability实例已经存在，则复用系统中的Ability实例。系统中只存在唯一一个该Ability实例，即在最近任务列表中只存在一个该类型的Ability实例。此时，应用的Ability实例已创建，当再次调用startAbility()方法启动该Ability实例时，只会进入该Ability的onNewWant()回调，不会进入其onCreate()和onWindowStageCreate()生命周期回调。如果需要使用singleton启动模式，将module.json5配置文件中的"launchType"字段配置为"singleton''即可。

2 standard启动模式

在standard启动模式下，每次调用startAbility()方法时，都会在应用进程中创建一个新的该类型的Ability实例，即在最近任务列表中可以看到有多个该类型的Ability实例。这种情况下，可以将Ability配置为standard。如果需要使用standard启动模式，将module.json5配置文件中的"launchType"字段配置为"standard"即可。

3 specified启动模式

在specified启动模式下，在Ability实例创建之前，允许开发者为该实例创建一个唯一的字符串Key，创建的Ability实例绑定Key之后，后续每次调用startAbility()方法时，都会询问应用使用哪个Key对应的Ability实例来响应startAbility请求。运行时由Ability内部业务决定是否创建多个实例，如果匹配有该Ability实例的Key，则直接拉起与之绑定的Ability实例，否则创建一个新的Ability实例。例如，用户在应用中重复打开同一个文档时，启动的均是最近任务列表中的同一个任务，以及在应用中重复新建文档时，启动的均是最近任务列表中的新任务。这种情况下，可以将Ability配置为specified。当再次调用startAbility()方法启动该Ability实例，且AbilityStage的onAcceptWant()回调匹配到一个已创建的Ability实例时，再次启动该Ability，只会进入该Ability的onNewWant()回调，不会进入其onCreate()和onWindowStageCreate()生命周期回调。如果需要使用specified启动模式，将module.json5配置文件的"launchType"字段配置为"specified"即可。

ExtensionAbility机制

不同于页面展示的Ability，ExtensionAbility提供的是一种受限的运行环境。ExtensionAbility组件具有如下特点：

· 运行在独立于主进程的单独进程中，与主进程无IPC（Inter-Process Communication，进程间通信），但共享一个存储沙箱。

· 独立的Context提供基于相应业务场景的API能力。

· 由系统触发创建，应用不能直接创建。

· ExtensionAbility和进程的生命周期受系统管理。

ArkUI开发框架

基于ArkTS的声明式开发范式的方舟开发框架(ArkUI)是一套开发极简、高性能、跨设备应用的UI开发框架，支持开发者高效地构建跨设备应用UI界面。

ArkTS编程语言

HarmonyOS提供了支持多种开发语言的API，供开发者进行应用开发，支持的开发语言包括ArkTS、JS(JavaScript)、C/C++、Java。ArkTS是HarmonyOS优选的主力应用开发语言。ArkTS基于TypeScript（简称TS）语言扩展而来，是TS的超集。这也是ArkTS的原名叫eTS的原因，它是extend TypeScript的简写。ArkTS继承了TS的所有特性，并且ArkTS在TS基础上还扩展了声明式UI能力，让开发者以更简洁、更自然的方式开发高性能应用。

HarmonyOS 4.0

升级内容

新系统为手机 / 平板增加了一个全新功能“实况窗”，为手表添加了“弦月窗”。该功能类似苹果 iOS 中的实时活动，可以在屏幕左上角、锁屏界面实时显示应用的信息，并且可在胶囊和卡片之间切换。

在新系统中，用户可以通过 AI 抠图识别主体，搭配多种艺术背景；结合杂志化设计，让照片变成壁纸；设置全景天气壁纸，将自然天气装进手机，实时感知天气变化；HarmonyOS 4 还带来更生动的 Emoji 表情。

通知中心

鸿蒙 HarmonyOS 4 采用了全新的通知中心，可“置顶”关键信息。

效率工具

超级中转站支持更多应用，双指长按轻松提取文本、图片并拖入中转站；

超级桌面拓展更多场景，不仅支持手游流转智能座舱屏幕，也能支持无人机航拍画面流转至智能座舱；

演示批注功能让 HUAWEI M-Pencil 秒变白板笔，共享内容可圈可点可标注。

AI功能

鸿蒙 HarmonyOS 4 对小艺语音助手带来了 AI 大模型升级。据官方介绍，小艺的手机月活用户已达 2 亿。AI 大模型赋能的 HarmonyOS 4 全新小艺，号称在智慧交互、高效生产力和个性化服务三个方向持续增强。据发布会演示，小艺支持生成复杂场景、快速摘要、文字创作、自然对话、看图说话、图片二创、随口记事提醒、场景化服务组合等。