应用模型
在了解什么是HAP、HAR、HSP之前，我们先来了解一下HarmonyOS为开发者提供的应用模型。
文档说明： 应用模型是HarmonyOS为开发者提供的应用程序所需能力的抽象提炼，它提供了应用程序必备的组件和运行机制。有了应用模型，开发者可以基于一套统一的模型进行应用开发，使应用开发更简单、高效。
随着系统的演进发展，HarmonyOS先后提供了两种应用模型：
- Stage模型： HarmonyOS API 9开始新增的模型，是目前主推且会长期演进的模型。在该模型中，由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”，因此称这种应用模型为Stage模型。
- FA（Feature Ability）模型： HarmonyOS API 7开始支持的模型，已经不再主推。
由此我们可以知道，在HarmonyOS Next开发应用中，Stage模型将会是我们主要学习的模型。
应用程序包（Module）
大家应该都了解什么是组件化、模块化的开发模式，都有自己的理解，同样，HarmonyOS应用开发也支持模块化（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私仓和跨应用引用。 |
总结来说，我们项目中的业务模块（Ability类型的Module），可以分为entry和feature两种类型的Module，一个应用中，只能有一个entry类型的Module，但是可以包含多个feature类型的Module，以上这些模块，通过编译后，都会生成一个.hap为后缀的文件，也就是HAP(Harmony Ability Package)。而项目中的公共模块（Library类型的Module），比如static、components等，这些被业务模块共享的Module，根据自身特点，编译后，静态共享Module会生成.har为后缀的文件，也就是HAR(Harmony Archive)，比如static文件夹；而通用业务组件Module，编译后会生成一个.hsp为后缀的文件，即HSP(Harmony Shared Package)，比如components文件夹，对应的，也会生成一个.har文件，为了导出HSP中的通用组件。
