$\mathrm{HarmonyOS}$ 简述

下面就以应用、开发和系统视角来简单阐述 $\mathrm{HarmonyOS}$ 系统的特性和优势，并在此基础上介绍 $\mathrm{APP}$ 结构。

应用视角

$1+8+N$：一个 $\mathrm{OS}$​​ 满足全场景智慧生活。

技术手段：跨端迁移、显示协同、交互协同和算力协同。

服务原子化：将服务拆分，服务可被多个应用共享。借助机器学习等技术，让服务主动为人服务。

$\mathrm{HMS}$ 华为移动服务

华为公司推出的一系列服务的合集，包括华为账号服务、应用内支付服务、推送服务、华为地图和广告服务等。

$\mathrm{HMS}\mathrm{Core}$ 是所有 $\mathrm{HMS}$​ 应用所依赖的基础库。除此之外，其他第三方应用也可调用华为移动服务。

开发视角

• 统一生态，打造超级终端系统；

  

• 一次开发多端部署：提供框架，方便对业务逻辑和界面逻辑进行复用；设计组件化、小型化，支持多种终端设备按需弹性部署；通过编译链关系自动生成组件化的依赖关系，降低硬件设备的开发门槛。

• 应用与服务解耦：应用与服务生命周期既可共享也可独立。

系统视角

$\mathrm{HarmonyOS}$ 是一个多设备互连的分布式操作系统，通过分布式软总线、分布式设备虚拟化、分布式数据管理和分布式任务调度从而达到“硬件互助， 资源共享” 。具体地，操作系统内部分为四层：

• 内核层：可以支持多种不同操作系统；设备驱动采用 $\mathrm{HDF}$ 来统一。
• 系统服务层：核心能力集合，通过框架层对应用程序提供服务；
• 框架层：给用户和开发者提供了语言框架、$\mathrm{Ability}$ 框架和 $\mathrm{UI}$ 框架。
• 应用层：包括系统应用和扩展应用和第三方非系统应用。华为引入了 $Stage$ 模型。

分布式软总线

分布式软总线是多种终端设备的统一基座，为设备之间的互连互通提供了统一的分布式通信能力，能够快速发现并连接设备，高效地分发任务和传输数据。

此外，$\mathrm{HarmonyOS}$ 通过一下手段来保证系统安全性：

• 身份安全：通过零信任模型（全盘质疑并验证）、多因素融合认证（通过不同设备上标识同一用户的认证凭据关联起来，用于标识一个用户）和协同互助认证（信息采集和认证可以在不同的设备上完成）来实现协同身份认证。
• 设备安全：在分布式终端场景下，只有保证用户使用的设备是安全可靠的，才能在源头保证安全。通过安全启动（确保源头是完整且未经篡改的）、可信执行环境（基于硬件的）和设备证书认证（为具备可信执行环境的设备预置设备证书）来保证设备安全。
• 数据安全：$\mathrm{HarmonyOS}$ 围绕数据的生成、存储、使用、传输以及销毁过程进行全生命周期的保护，从而保证个人数据与隐私以及系统的机密数据（如密钥）不泄漏 。

$\mathrm{APP}$ 结构

在开发态，一个应用包含一个或者多个 Module，可以在 DevEco Studio 工程中创建并编译一个或者多个 Module。Module 是 $\mathrm{HarmonyOS}$ 应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个 Module 都可以独立进行编译和运行。Module 分为 Ability 和 Library 两种类型，Ability 类型的 Module 对应于编译后的 $\mathrm{HAP}(\mathrm{Harmony}\mathrm{Ability}\mathrm{Package})$，即静态共享包；Library 类型的 Module 对应于 $\mathrm{HAR}(\mathrm{Harmony}\mathrm{Archive})$，或 $\mathrm{HSP}(\mathrm{Harmony}\mathrm{Shared}\mathrm{Package})$​，即动态共享包。

当编译之后， Ability 类型的 Module 被打包成 $\mathrm{HAP}$（.hap 文件）。$\mathrm{HAP}$ 是应用安装的基本单位，包含了编译后的代码、资源、第三方库和配置文件。.hap 文件通过内部的 module.json5 （ $\mathrm{HAP}$​ 的配置文件）的 type 标签被区分为 Entry 和 Feature 两种类型。Entry 类型的 .hap 是应用的主模块，通常实现应用的入口界面、入口图标和主要的特性功能。Feature 的 .hap 是应用的动态特性模块，通常用于实现应用中的特性模块，对于应用而言是可选的。

Library 类型的 Module 包

$\mathrm{OpenHarmony}$ 提供了两种共享包，$\mathrm{HAR}(\mathrm{Harmony}\mathrm{Archive})$ 静态共享包，和$\mathrm{HSP}(\mathrm{Harmony}\mathrm{Shared}\mathrm{Package})$ 动态共享包。

$\mathrm{HAR}$ 与 $\mathrm{HSP}$ 都是为了实现代码和资源的共享，都可以包含代码、库、资源和配置文件，最大的不同之处在于 $\mathrm{HAR}$ 中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝；而 $\mathrm{HSP}$ 中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。

每一个 $\mathrm{HarmonyOS}$ 应用可以包含多个 .hap 文件，它们合在一起叫做 bundle ，bundleName 是这个应用的唯一标识。在应用上架到应用市场时，需要把应用包含的所有 .hap 文件（即 Bundle）打包为一个 .app 后缀的文件用于上架。在这个 .app 包里包含了一个 pack.info 文件来描述应用包的属性。整个 $\mathrm{APP}$ 结构如下所示：

两个重要配置文件

在基于 $Stage$​ 模型开发的应用项目代码下，都存在一个 app.json5 及一个或多个 module.json5 这两种配置文件。

app.json5 主要包含：应用的全局配置信息，包括应用的包名、开发厂商、版本号等基本信息；特定设备类型的配置信息；

module.json5 主要包含：Module 的基本配置信息，例如 Module 名称、类型、描述、支持的设备类型等基本信息；应用组件信息和权限信息。

module.json5 的主要标签	含义
deviceTypes	标识当前 Module 可以运行在哪类设备上。
pages	标识当前 Module 的 profile 资源，用于列举每个页面信息，取值为长度不超过 $255$ 字节的字符串。
metadata	$\mathrm{HAP}$ 的自定义元信息
abilities	描述 UIAbility 组件的配置信息，包括 launchType
skill	标识能够接收的 Want 的特征。方便应用组件之间传递信息。
requestPermissions	标识应用运行时需向系统申请的权限集合。
distributionFilter	该标签用于定义HAP对应的细分设备规格的分发策略，以便在应用市场进行云端分发应用包时做精准匹配。

更详细全面的标签解释，可参见官方网站上的 module.json5配置文件。

UIAbility 简述

UIAbility 组件是一种包含 UI 的应用组件，主要用于和用户交互。UIAbility 组件是系统调度的基本单元，为应用提供绘制界面的窗口。一个应用可以包含一个或多个 UIAbility 组件。例如，在支付应用中，可以将入口功能和收付款功能分别配置为独立的 UIAbility。

UIAbility 生命周期

整个 UIAbility 的生命周期分为五个部分，即 create、foreground、background、destroy。其中，当应用启动时，UIAbility 进入 create 状态，然后进入 foreground 态。在应用运行期间，会在 foreground 态和 background 上切换。当应用关闭时，则进入 destory 状态，完成 UIAbility 的销毁。具体转换可见下图：

UIAbility 启动模式

UIAbility 实例在启动时具有不同呈现状态。针对不同的业务场景，系统提供了三种启动模式：

• singleton：每次打开只创建一个实例
• standard：每次打开都创建实例
• specified：文档类应用。当打开同一个文件时不重新创建实例；当打开新文件时创建新实例。

在 UIAbility 启动过程中，必须指定一个默认加载页面，否则会出现白屏现象。重写 onWindowStageCreate 方法，使启动时调用 loadContent() 即可，代码如下：

onWindowStageCreate(windowStage: window.WindowStage) {
    // Main window is created, set main page for this ability
    windowStage.loadContent('pages/IndexPage', (err, data) => {
     // write some logs...
    });
  }

$\mathrm{Stage}$ 模型

UIAbility 采用 $\mathrm{Stage}$ 模型。$\mathrm{Stage}$ 模型和 $\mathrm{FA}$ 模型最大的区别在于：$\mathrm{Stage}$ 模型中多个应用组件共享同一个虚拟机，而 $\mathrm{FA}$ 模型中每个应用组件都有自己的虚拟机。$\mathrm{Stage}$ 模型的优势在于：多个应用组件共享同一个虚拟机，可以减少内存占用，提高性能；同时组件之间可以共享数据和状态，提高开发效率。