HarmonyOS 鸿蒙Next应用程序框架基础

HarmonyOS 鸿蒙Next应用程序框架基础

应用程序框架基础

1. 应用程序框架

应用程序框架是一种编程框架，用来简化应用程序的开发过程，提高代码的可重用性和可维护性。它可以帮助开发人员更快速、更高效地开发应用程序。应用程序框架通常包括以下内容：

  • 类库：提供应用程序所需的常见功能，减少开发工作量。
  • 组件：定义应用程序的结构和行为，包括视图、控制器、模型等。
  • 生命周期管理：管理应用程序的启动、运行和关闭过程。
  • 服务：提供诸如网络请求、数据存储等基础服务。

2. 应用模型

应用模型是一个应用程序的模型，它是一种抽象描述，用于表示应用程序的不同方面，例如应用组件、进程模型、线程模型、任务管理以及包管理。应用模型提供了一种统一的语言和架构来描述应用程序的各个方面。应用模型的构成要素包括：

  • 应用组件：应用的基本组成单位，是应用的运行入口。
  • 应用进程模型：定义应用进程的创建和销毁方式，以及进程间的通信方式。
  • 应用线程模型：定义应用进程内线程的创建和销毁方式。
  • 应用任务管理模型：定义任务的创建和销毁方式，以及任务与组件间的关系。
  • 应用配置文件：包含应用配置信息、应用组件信息、权限信息等。

应用程序框架可以被看做是应用模型的一种实现方式。应用模型是抽象的，而应用程序框架是具体的实现方式。开发人员可以根据应用模型描述应用程序的结构和行为，然后使用应用程序框架来实现这些描述

3. Module的类型

Ability类型的Module

用于实现应用的功能和特性。每一个Ability类型的Module编译后，会生成一个以.hap为后缀的文件，称为HAP（Harmony Ability Package）包。HAP包可以独立安装和运行，是应用安装的基本单位，一个应用可以包含一个或多个HAP包，包含的HAP包分为以下两种类型。

entry类型的Module

应用的主模块，包含应用的入口界面、入口图标和主功能特性，编译后生成entry类型的HAP。每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个entry类型的HAP，也可以不包含。

feature类型的Module

应用的动态特性模块，编译后生成feature类型的HAP。一个应用中可以包含一个或多个feature类型的HAP，也可以不包含。

Library类型的Module

用于实现代码和资源的共享。同一个Library类型的Module可以被其他的Module多次引用，合理地使用该类型的Module，能够降低开发和维护成本。Library类型的Module分为Static和Shared两种类型，编译后生成共享包。

Static Library

静态共享库。编译后生成一个以.har为后缀的文件，即静态共享包HAR（Harmony Archive）。

Shared Library

动态共享库。编译后生成一个以.hsp为后缀的文件，即动态共享包HSP（Harmony Shared Package）。

HAR：HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。 除了支持应用内引用，还可以独立打包发布，供其他应用引用。

HSP：HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。应用内HSP只支持应用内引用，集成态HSP支持发布到ohpm私仓和跨应用引用。

说明

实际上，Shared Library编译后除了会生成一个.hsp文件，还会生成一个.har文件。这个.har文件中包含了HSP对外导出的接口，应用中的其他模块需要通过.har文件来引用HSP的功能。

4. 发布态包结构

每个应用中至少包含一个.hap文件，可能包含若干个.hsp文件、也可能不含，一个应用中的所有.hap与.hsp文件合在一起称为Bundle，其对应的bundleName是应用的唯一标识（详见app.json5配置文件中的bundleName标签）。

当应用发布上架到应用市场时，需要将Bundle打包为一个.app后缀的文件用于上架，这个.app文件称为App Pack（Application Package），与此同时，DevEco Studio工具自动会生成一个pack.info文件。pack.info文件描述了App Pack中每个HAP和HSP的属性，包含APP中的bundleName和versionCode信息、以及Module中的name、type和abilities等信息。

说明

  • App Pack是发布上架到应用市场的基本单元，但是不能在设备上直接安装和运行。
  • 在应用签名、云端分发、端侧安装时，都是以HAP/HSP为单位进行签名、分发和安装的。

UIAbility组件基础

UIAbility：是HarmonyOS 中的一种应用组件，主要用于提供用户界面（UI）并与用户进行交互

生命周期

Create状态为在应用加载过程中，UIAbility实例创建完成时触发，系统会调用onCreate()回调。可以在该回调中进行应用初始化操作，例如变量定义资源加载等，用于后续的UI展示。

Background状态在UIAbility实例切换至后台时触发，对应于onBackground()回调。

Destroy状态在UIAbility实例销毁时触发。

每个UIAbility都包含了Context属性，UI Ability主要是处理生命周期，对于其他操作UIAbility的方法如startUIActivity（），connectUIAbility（）都是在UIAbilityContext中实现的


更多关于HarmonyOS 鸿蒙Next应用程序框架基础的实战教程也可以访问 https://www.itying.com/category-93-b0.html

2 回复

HarmonyOS的应用程序框架基于原子化服务设计，采用Ability为核心组件。Stage模型是主推的应用模型，包含UIAbility、ExtensionAbility等组件类型。ArkUI框架提供声明式开发范式，支持TS/JS语言开发。应用包格式为.app，使用HAP（Harmony Ability Package）分发。系统提供分布式任务调度能力，支持跨设备迁移。安全机制采用微内核架构，进程间通信通过Binder实现。状态管理使用AppStorage和LocalStorage，支持组件级状态共享。

更多关于HarmonyOS 鸿蒙Next应用程序框架基础的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


HarmonyOS Next的应用程序框架确实为开发者提供了强大的开发支持。关于您提到的几个关键点：

  1. 应用模型和框架的关系很准确 - 模型是抽象描述，框架是具体实现。HarmonyOS Next通过这种分层设计提高了开发效率。

  2. Module类型的设计很实用：

  • Ability类型Module(HAP)作为功能单元确实支持灵活组合
  • Library类型Module(HAR/HSP)的静态/动态共享机制能有效优化资源使用
  1. 发布包结构设计合理：
  • Bundle作为应用唯一标识
  • App Pack作为上架单元
  • 实际安装仍以HAP/HSP为单位
  1. UIAbility的生命周期管理：
  • onCreate/onBackground/onDestroy等回调设计清晰
  • 将UI交互与业务逻辑分离的做法值得肯定

这些基础概念的理解对HarmonyOS应用开发非常重要。建议开发者可以结合实际项目，通过创建不同类型的Module来加深理解。

回到顶部