下载掌阅APP，畅读海量书库
立即打开
在软件开发中，应用程序用来泛指运行在设备操作系统之上，为用户提供特定服务的程序，简称应用。一个应用所对应的软件包文件，称为应用程序包。
HarmonyOS提供了应用程序包开发、安装、查询、更新、卸载管理机制，这些管理机制可以方便开发者开发和管理HarmonyOS应用，说明如下。
· 应用软件所涉及的文件多种多样，开发者可通过HarmonyOS提供的集成开发工具将其开发的可执行代码、资源、三方库等文件整合到一起制作成HarmonyOS应用程序包，便于开发者对应用程序的部署。
· 应用软件所涉及的设备类型多种多样，开发者可通过HarmonyOS提供的应用程序包配置文件指定其应用程序包的分发设备类型，便于应用市场对应用程序包的分发管理。
· 应用软件所包含的功能多种多样，将不同的功能特性按模块来划分和管理是一种良好的设计方式。HarmonyOS提供了同一应用程序的多包管理的机制，开发者可以将不同的功能特性聚合到不同的包中，方便后续的维护与扩展。
· 应用软件涉及的芯片平台多种多样，有x86、ARM等，还有32位、64位之分，HarmonyOS为应用程序包屏蔽了芯片平台的差异，使应用程序包在不同的芯片平台都能够安装运行。
· 应用软件涉及的软件信息多种多样，有应用版本、应用名称、组件、申请权限等的信息，HarmonyOS包管理为开发者提供了这些信息的查询接口，方便开发者在程序中查询所需要的包信息。
· 应用软件涉及的资源多种多样，有媒体资源、原生资源、字符资源以及国际化的资源等，HarmonyOS包管理将不同的资源归档到不同的目录中，并集成资源索引文件，方便应用对资源的查找和使用。
在正式进行HarmonyOS应用／服务开发前，开发者需要掌握应用／服务的一些包结构和基本概念。通常，应用／服务的发布形态为App Pack（Application Package），它是由一个或多个HAP（Harmony Ability Package）包以及描述App属性的pack.info文件组成。
HAP是HarmonyOS应用安装的基本单位，由编译后的代码、资源、三方库及配置文件构成，HAP可以分为Entry和Feature两种类型，说明如下。
· Entry：应用／服务的主模块，可独立安装运行。对于同一类型的设备，App可以包含一个或多个Entry类型的HAP，如果同一类型的设备包含多个Entry模块，需要配置distroFilter分发规则，这样就可以在做应用的云端分发时，对不同规格的设备进行分发。
· Feature：应用／服务的动态特性模块。通常，一个App可以包含零到多个Feature类型的HAP，并且只有包含Ability的HAP才能够独立运行。
HarmonyOS应用开发分成了两种开发模型，分别是Stage模型和FA模型用。其中，FA模型是鸿蒙早期版本就支持的模型，适合工程结构不是很复杂的应用；Stage模型则是API 9新增的模型，是为了解决FA模型无法解决的开发场景而开发的新模型。
FA模型与Stage模型最大的区别在于，FA模型的每个应用组件独享一个虚拟机，多个应用组件共享同一个虚拟机。所以，相比Stage模型，FA模型的应用程序包结构要简单许多，如图1—3所示。
可以看到，FA模型将所有的资源文件、库文件和代码文件都放在assets文件夹中，然后在文件夹内部进一步进行区分，说明如下。
· config.json：应用配置文件，IDE会自动生成一部分模块代码，开发者按需修改其中的配置。
· assets: HAP所有的资源文件、库文件和代码文件集合，内部由entry和js文件夹构成。entry文件夹存放的是资源文件和resources.index文件。
· resources：用于存放应用的资源文件，如字符串、图片等。
· resources.index：资源索引表，由IDE调用SDK工具自动生成。
· js：文件夹中存放的编译后的代码文件。
· pack.info: undle中用于描述每个HAP属性的文件，由IDE工具生成Bundle包时自动生成。
Stage模型基于FA模型的基础概念演化而来，开发者能够使用它开发出分布式场景下的复杂应用，Stage模型应用包结构如图1—4所示。
图1—3 FA模型应用包结构
图1—4 Stage模型应用包结构
可以看到，每个HarmonyOS应用程序都可以包含多个HAP包文件，而HAP则由ets、libs、resources等文件夹和resources.index、module.json、pack.info等配置文件构成，说明如下。
· ets：用于存放应用代码编译后的字节码文件。
· libs：用于存放库文件，库文件是HarmonyOS应用依赖的第三方代码。
· resources：用于存放应用的资源文件，如图片、字符串和颜色等。
· resources.index：资源索引表，由IDE编译工程时生成。
· module.json: HAP配置文件，内容由工程配置中的module.json5和app.json5组成，IDE会自动生成一部分默认配置，开发者按需修改其中的默认配置。
· pack.info：用于描述每个HAP属性的文件，如应用的bundleName和versionCode信息、模块的name、type和abilities等信息。
需要特别说明的是，从API 10开始，HarmonyOS将逐步弃用FA模型，并主推Stage模型，因为相较于FA模型，Stage模型目录管理更加简单方便。
OpenHarmony提供了两种共享包，分别是HAR（Harmony Archive）静态共享包和HSP（Harmony Shared Package）动态共享包。
HAR与HSP都是为了实现代码和资源的共享，都包含有代码、C++库、资源和配置文件。二者最大的不同之处在于，HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同“拷贝”。而HSP中的代码和资源可以独立编译，运行时在一个单独的进程中，代码也只会存在一份，HAR和HSP在App包中的形态如图1—5所示。
图1—5 HAR和HSP在App包中的形态
HAR是HarmonyOS开发中的静态共享包，作用类似于Android开发中的aar包。HAR包含代码、C++库、资源和配置文件，HAR可以实现多个模块或多个工程之间ArkUI组件、资源等代码的共享。不同于HAP, HAR不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。
HSP是HarmonyOS开发中的动态共享包，目的是解决大型项目中多个HAP无法共享同一公共资源代码的问题，作用类似于Android开发中的本地library模块。HSP只能在应用内部其他的HAP或HSP使用，实现应用内部代码和资源的共享。同时，应用内HSP会跟随其宿主应用的App包一起发布，与该宿主应用具有相同的包名和生命周期。
需要说明的是，在应用内使用HSP时，有以下几点约束。
· HSP及其使用方都必须是Stage模型。
· HSP及其使用方都必须使用esmodule编译模式。
· HSP不支持在配置文件中声明abilities、extensionAbilities标签。