一、应用程序包概述
在基于Stage模型开发应用之前，开发者需要了解应用的设计机制、应用程序包结构等基础知识。
应用程序框架概述图如下
1.1 应用与应用程序包
用户应用程序泛指运行在设备的操作系统之上，为用户提供特定服务的程序，简称"应用"。一个应用所对应的软件包文件，称为"应用程序包"。
当前系统提供了应用程序包开发、安装、查询、更新、卸载的管理机制，便于开发者开发和管理应用。同时，系统还屏蔽了不同的芯片平台的差异（包括x86/ARM，32位/64位等），应用程序包在不同的芯片平台都能够安装运行，这使得开发者可以聚焦于应用的功能实现。
1.2 应用的多Module设计机制
- 支持模块化开发： 一个应用通常会包含多种功能，将不同的功能特性按模块来划分和管理是一种良好的设计方式。在开发过程中，我们可以将每个功能模块作为一个独立的Module进行开发，Module中可以包含源代码、资源文件、第三方库、配置文件等，每一个Module可以独立编译，实现特定的功能。这种模块化、松耦合的应用管理方式有助于应用的开发、维护与扩展。
- 支持多设备适配： 一个应用往往需要适配多种设备类型，在采用多Module设计的应用中，每个Module都会标注所支持的设备类型。有些Module支持全部类型的设备，有些Module只支持某一种或几种类型的设备（比如平板），那么在应用市场分发应用包时，也能够根据设备类型做精准的筛选和匹配，从而将不同的包合理的组合和部署到对应的设备上。
1.3 Module类型
Module按照使用场景可以分为两种类型：
- Ability类型的Module ： 用于实现应用的功能和特性。每一个Ability类型的Module编译后，会生成一个以.hap为后缀的文件，我们称其为HAP（Harmony Ability Package）包。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）。
说明 实际上，Shared Library编译后除了会生成一个.hsp文件，还会生成一个.har文件。这个.har文件中包含了HSP对外导出的接口，应用中的其他模块需要通过.har文件来引用HSP的功能。为了表述方便，我们通常认为Shared Library编译后生成HSP。
HAR与HSP两种共享包的主要区别体现在：
| 共享包类型 | 编译和运行方式 | 发布和引用方式 |
|---|---|---|
| HAR | HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。注意：编译HAR时，建议开启混淆能力，保护代码资产。 | HAR除了支持应用内引用，还可以独立打包发布，供其他应用引用。 |
| HSP | HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。 | HSP一般随应用进行打包，当前支持应用内和集成态HSP。应用内HSP只支持应用内引用，集成态HSP支持发布到ohpm私仓和跨应用引用。 |
HAR和HSP在APP包中的形态示意图
二、Stage模型应用程序包结构
2.1 开发态包结构
在DevEco Studio上创建一个项目工程，并尝试创建多个不同类型的Module。根据实际工程中的目录对照下面内容进行学习，可以有助于理解开发态的应用程序结构。
2.2 工程目录结构
2.2.1 文件类型
2.2.2 ArkTS源码文件
2.2.3 应用级配置文件
2.2.4 模块级配置文件
2.2.5 工程目录配置文件
2.2.6 资源文件
三、工程结构主要包含的文件类型及用途
说明
- AppScope目录由DevEco Studio自动生成，不可更改。
- Module目录名称可以由DevEco Studio自动生成（比如entry、library等），也可以自定义。为了便于说明，下表中统一采用Module_name表示。
| 文件类型 | 说明 |
|---|---|
| 配置文件 | 包括应用级配置信息、以及Module级配置信息： - AppScope > app.json5 ：app.json5配置文件，用于声明应用的全局配置信息，比如应用Bundle名称、应用名称、应用图标、应用版本号等。 - Module_name > src > main > module.json5 ：module.json5配置文件，用于声明Module基本信息、支持的设备类型、所含的组件信息、运行所需申请的权限等。 |
| ArkTS源码文件 | Module_name > src > main > ets：用于存放Module的ArkTS源码文件（.ets文件）。 |
| 资源文件 | 包括应用级资源文件、以及Module级资源文件，支持图形、多媒体、字符串、布局文件等，详见资源分类与访问。 - AppScope > resources ：用于存放应用需要用到的资源文件。 - Module_name > src > main > resources ：用于存放该Module需要用到的资源文件。 |
| 其他配置文件 | 用于编译构建，包括构建配置文件、编译构建任务脚本、混淆规则文件、依赖的共享包信息等。 - build-profile.json5 ：工程级或Module级的构建配置文件，包括应用签名、产品配置等。 - hvigorfile.ts ：应用级或Module级的编译构建任务脚本，开发者可以自定义编译构建工具版本、控制构建行为的配置参数。 - obfuscation-rules.txt ：混淆规则文件。混淆开启后，在使用Release模式进行编译时，会对代码进行编译、混淆及压缩处理，保护代码资产。 - oh-package.json5：用于存放依赖库的信息，包括所依赖的三方库和共享包。 |
四、编译态包结构
不同类型的Module编译后会生成对应的HAP、HAR、HSP等文件，开发态视图与编译态视图的对照关系如下：
开发态与编译态的工程结构视图
从开发态到编译态，Module中的文件会发生如下变更：
- ets目录：ArkTS源码编译生成.abc文件。
- resources目录：AppScope目录下的资源文件会合入到Module下面资源目录中，如果两个目录下存在重名文件，编译打包后只会保留AppScope目录下的资源文件。
- module配置文件：AppScope目录下的app.json5文件字段会合入到Module下面的module.json5文件之中，编译后生成HAP或HSP最终的module.json文件。
说明 在编译HAP和HSP时，会把他们所依赖的HAR直接编译到HAP和HSP中。
五、发布态包结构
每个应用中至少包含一个.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为单位进行签名、分发和安装的。
编译发布与上架部署流程图
六、选择合适的包类型
HAP、HAR、HSP三者的功能和使用场景总结对比如下：
| Module类型 | 包类型 | 说明 |
|---|---|---|
| Ability | HAP | 应用的功能模块，可以独立安装和运行，必须包含一个entry类型的HAP，可选包含一个或多个feature类型的HAP。 |
| Static Library | HAR | 静态共享包，编译态复用。 - 支持应用内共享，也可以发布后供其他应用使用。 - 作为二方库，发布到OHPM私仓，供公司内部其他应用使用。 - 作为三方库，发布到OHPM中心仓，供其他应用使用。 - 多包（HAP/HSP）引用相同的HAR时，会造成多包间代码和资源的重复拷贝，从而导致应用包膨大。 - 注意：编译HAR时，建议开启混淆能力，保护代码资产。 |
| Shared Library | HSP | 动态共享包，运行时复用。 - 当前仅支持应用内共享。 - 当多包（HAP/HSP）同时引用同一个共享包时，采用HSP替代HAR，可以避免HAR造成的多包间代码和资源的重复拷贝，从而减小应用包大小。 |
HAP、HSP、HAR支持的规格对比如下，其中"√"表示是，"×"表示否。
开发者可以根据实际场景所需的能力，选择相应类型的包进行开发。
| 规格 | HAP | HAR | HSP |
|---|---|---|---|
| 支持在配置文件中声明UIAbility组件与ExtensionAbility组件 | √ | × | × |
| 支持在配置文件中声明pages页面 | √ | × | √ |
| 支持包含资源文件与.so文件 | √ | √ | √ |
| 支持依赖其他HAR文件 | √ | √ | √ |
| 支持依赖其他HSP文件 | √ | √ | √ |
| 支持在设备上独立安装运行 | √ | × | × |
说明
- HAR虽然不支持在配置文件中声明pages页面，但是可以包含pages页面，并通过命名路由的方式进行跳转。
- 由于HSP仅支持应用内共享，如果HAR依赖了HSP，则该HAR文件仅支持应用内共享，不支持发布到二方仓或三方仓供其他应用使用，否则会导致编译失败。
- HAR和HSP均不支持循环依赖，也不支持依赖传递。