应用与应用程序包
用户应用程序泛指运行在设备的操作系统之上，为用户提供特定服务的程序，简称“应用”。一个应用所对应的软件包文件，称为“应用程序包”。
当前系统提供了应用程序包开发、安装、查询、更新、卸载的管理机制，便于开发者开发和管理应用。同时，系统还屏蔽了不同的芯片平台的差异（包括 x86/ARM，32 位/64 位等），应用程序包在不同的芯片平台都能够安装运行，这使得开发者可以聚焦于应用的功能实现。
应用的多 Module 设计机制
- 支持模块化开发
一个应用通常会包含多种功能，将不同的功能特性按模块来划分和管理是一种良好的设计方式。在开发过程中，我们可以将每个功能模块作为一个独立的 Module 进行开发，Module 中可以包含源代码、资源文件、第三方库、配置文件等，每一个 Module 可以独立编译，实现特定的功能。这种模块化、松耦合的应用管理方式有助于应用的开发、维护与扩展。
- 支持多设备适配
一个应用往往需要适配多种设备类型，在采用多 Module 设计的应用中，每个 Module 都会标注所支持的设备类型。有些 Module 支持全部类型的设备，有些 Module 只支持某一种或几种型的设备（比如平板），那么在应用市场分发应用包时，也能够根据设备类型做精准的筛选和匹配，从而将不同的包合理的组合和部署到对应的设备上。
Module 类型
Module 按照使用场景可以分为两种类型：
- Ability 类型的 Module
用于实现应用的功能和特性。每一个 Ability 类型的 Module 编译后，会生成一个以.hap 为后缀的文件，我们称其为 HAP（Harmony Ability Package）包。HAP 包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或多个 HAP 包，具体包含如下两种类型
(1) entry 类型的 Module：应用的主模块，包含应用的入口界面、入口图标和主功能特性，编译后生成 entry 类型的 HAP。每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个 entry 类型的 HAP
(2) feature 类型的 Module：应用的动态特性模块，编译后生成 feature 类型的 HAP。一个应用中可以包含一个或多个 feature 类型的 HAP，也可以不包含
- Library 类型的 Module
用于实现代码和资源的共享。同一个 Library 类型的 Module 可以被其他的 Module 多次引用，合理地使用该类型的 Module，能够降低开发和维护成本。Library 类型的 Module 分为 Static 和 Shared 两种类型，编译后会生成共享包。
(1) Static Library：静态共享库。编译后会生成一个以.har 为后缀的文件，即静态共享包 HAR（Harmony Archive）。
(2) Shared Library：动态共享库。编译后会生成一个以.hsp 为后缀的文件，即动态共享包 HSP（Harmony Shared Package）。
HAR 与 HSP 两种共享包的主要区别体现在：
HAR
HAR 中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。
注意：编译 HAR 时，建议开启混淆能力，保护代码资产。
HAR 除了支持应用内引用，还可以独立打包发布，供其他应用引用。
HSP
HSP 中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。
HSP 一般随应用进行打包，当前支持应用内和集成态 HSP。应用内 HSP 只支持应用内引用，集成态 HSP 支持发布到 ohpm 私仓和跨应用引用。
Stage 模型应用程序包结构
结构图如下
说明
配置文件
包括应用级配置信息、以及 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 文件。
INFO
在编译 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 等信息。
INFO
App Pack 是发布上架到应用市场的基本单元，但是不能在设备上直接安装和运行。
在应用签名、云端分发、端侧安装时，都是以 HAP/HSP 为单位进行签名、分发和安装的。
选择合适的包类型
HAP、HAR、HSP 三者的功能和使用场景总结对比如下：
HAP
Module 类型: Ability
应用的功能模块，可以独立安装和运行，必须包含一个 entry 类型的 HAP，可选包含一个或多个 feature 类型的 HAP。
HSP(内部使用)
Module 类型: Shared Library
动态共享包，运行时复用。
当前仅支持应用内共享。
当多包（HAP/HSP）同时引用同一个共享包时，采用 HSP 替代 HAR，可以避免 HAR 造成的多包间代码和资源的重复拷贝，从而减小应用包大小。
HAR(外部可以用)
Module 类型: Static Library
静态共享包，编译态复用。
支持应用内共享，也可以发布后供其他应用使用。
作为二方库，发布到 OHPM 私仓，供公司内部其他应用使用。
作为三方库，发布到 OHPM 中心仓，供其他应用使用。
多包（HAP/HSP）引用相同的 HAR 时，会造成多包间代码和资源的重复拷贝，从而导致应用包膨大。
注意：编译 HAR 时，建议开启混淆能力，保护代码资产。