鸿蒙应用开发涉及到三种应用程序包，分别是hap、har、hsp，首先做个了解：
一、了解应用程序包
1、HAP
HAP（Harmony Ability Package）是应用安装和运行的基本单元。HAP包是由代码、资源、第三方库、配置文件等打包生成的模块包，其主要分为两种类型：entry和feature。
- entry：应用的主模块，作为应用的入口，提供了应用的基础功能。
- feature：应用的动态特性模块，作为应用能力的扩展，可以根据用户的需求和设备类型进行选择性安装。
应用程序包可以只包含一个基础的entry包，也可以包含一个基础的entry包和多个功能性的feature包。
使用场景
- 单HAP场景：如果只包含UIAbility组件，无需使用ExtensionAbility组件，优先采用单HAP（即一个entry包）来实现应用开发。虽然一个HAP中可以包含一个或多个UIAbility组件，为了避免不必要的资源加载，推荐采用"一个UIAbility+多个页面"的方式。
- 多HAP场景：如果应用的功能比较复杂，需要使用ExtensionAbility组件，可以采用多HAP（即一个entry包+多个feature包）来实现应用开发，每个HAP中包含一个UIAbility组件或者一个ExtensionAbility组件。在这种场景下，可能会存在多个HAP引用相同的库文件，导致重复打包的问题。
约束限制
- 不支持导出接口和ArkUI组件，给其他模块使用。
- 多HAP场景下，App Pack包中同一设备类型的所有HAP中必须有且只有一个Entry类型的HAP，Feature类型的HAP可以有一个或者多个，也可以没有。
- 多HAP场景下，同一应用中的所有HAP的配置文件中的bundleName、versionCode、versionName、minCompatibleVersionCode、debug、minAPIVersion、targetAPIVersion、apiReleaseType相同，同一设备类型的所有HAP对应的moduleName标签必须唯一。HAP打包生成App Pack包时，会对上述参数配置进行校验。
- 多HAP场景下，同一应用的所有HAP、HSP的签名证书要保持一致。上架应用市场是以App Pack形式上架，应用市场分发时会将所有HAP从App Pack中拆分出来，同时对其中的所有HAP进行重签名，这样保证了所有HAP签名证书的一致性。在调试阶段，开发者通过命令行或DevEco Studio将HAP安装到设备上时，要保证所有HAP签名证书一致，否则会出现安装失败的问题。
2、HAR
HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。
使用场景
约束限制
- HAR不支持在设备上单独安装/运行，只能作为应用模块的依赖项被引用。
- HAR不支持在配置文件中声明UIAbility组件与ExtensionAbility组件。
- HAR不支持在配置文件中声明pages页面，但是可以包含pages页面，并通过命名路由的方式进行跳转。
- HAR不支持引用AppScope目录中的资源。在编译构建时，AppScope中的内容不会打包到HAR中，因此会导致HAR资源引用失败。
- HAR可以依赖其他HAR，但不支持循环依赖，也不支持依赖传递。
3、HSP
HSP（Harmony Shared Package）是动态共享包，可以包含代码、C++库、资源和配置文件，通过HSP可以实现应用内的代码和资源的共享。HSP不支持独立发布，而是跟随其宿主应用的APP包一起发布，与宿主应用同进程，具有相同的包名和生命周期。
说明：
仅支持应用内HSP，不支持应用间HSP。
使用场景
- 多个HAP/HSP共用的代码和资源放在同一个HSP中，可以提高代码、资源的可重用性和可维护性，同时编译打包时也只保留一份HSP代码和资源，能够有效控制应用包大小。
- HSP在运行时按需加载，有助于提升应用性能。
约束限制
- HSP不支持在设备上单独安装/运行，需要与依赖该HSP的HAP一起安装/运行。HSP的版本号必须与HAP版本号一致。
- HSP不支持在配置文件中声明UIAbility组件与ExtensionAbility组件。
- HSP可以依赖其他HAR或HSP，但不支持循环依赖，也不支持依赖传递。
二、选择合适的包类型
HAP、HAR、HSP三者的功能和使用场景总结对比如下：
| Module类型 | 包类型 | 说明 |
|---|---|---|
| Ability | HAP | 应用的功能模块，可以独立安装和运行，必须包含一个entry类型的HAP，可选包含一个或多个feature类型的HAP。 |
| Static Library | HAR | 静态共享包，编译态复用。 - 支持应用内共享，也可以发布后供其他应用使用。 - 作为二方库，发布到OHPM私仓，供公司内部其他应用使用。 - 作为三方库，发布到OHPM中心仓，供其他应用使用。 - 多包（HAP/HSP）引用相同的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均不支持循环依赖，也不支持依赖传递。
问：har包和hsp包的区别，动态包和静态包的区别，使用场景。
作用都是用于实现代码和资源的共享。同一个Library类型的Module可以被其他的Module多次引用，合理地使用该类型的Module，能够降低开发和维护成本。Library类型的Module分为Static和Shared两种类型，编译后会生成共享包。
●Static Library：静态共享库。编译后会生成一个以.har为后缀的文件，即静态共享包HAR（Harmony Archive）。
●Shared Library：动态共享库。编译后会生成一个以.hsp为后缀的文件，即动态共享包HSP（Harmony Shared Package）。
HAR与HSP两种共享包的主要区别体现在：
使用场景： har包适用用于不同项目下代码和资源共享，可以上传至openharmnony第三方共享仓开源，也可以在公司内搭建私有仓库进内共享。hsp适用于单个项目内容三层架构按功能模块分包，有利于降低打包体积，目前hsp还不能项目间共享。
开发者可以根据实际场景所需的能力，选择相应类型的包进行开发。
介绍完包类型，接下来说说鸿蒙next应用程序包在不同阶段的不同形态，分别对开发态、编译态、发布态的应用程序结构展开介绍。
三、进入开发
1、开发态包结构（开发阶段）
项目结构大概长这样（编译器结构风格和Android Studio很像）：
这里我列举了项目包里面涉及到的必须知道的重要目录（源码，图标，权限配置文件，图片等资源目录、签名等）：
1、ArkTS源码文件
- Module_name > src > main > ets ：用于存放Module的ArkTS源码文件（.ets文件）。
2、配置文件
- AppScope > app.json5 ：app.json5配置文件，用于声明应用的全局配置信息，比如应用Bundle名称、应用名称、应用图标、应用版本号等。
- Module_name > src > main > module.json5 ：module.json5配置文件，用于声明Module基本信息、支持的设备类型 、所含的组件信息、运行所需申请的权限等。
3、资源文件
- AppScope > resources ：用于存放应用需要用到的资源文件（应用图标）。
- Module_name （Entry）> src > main > resources ：用于存放该Module需要用到的资源文件（应用运行的资源，一些jpg，svg，png图片等）。
4、其它重要配置信息
- oh-package.json5 ：用于存放依赖库的信息，包括所依赖的三方库和共享包。
- build-profile.json5 ：工程级或Module级的构建配置文件，包括应用签名、产品配置等。
2、编译态包结构（打包编译阶段）
不同类型的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中。
3、发布态包结构（发布阶段）
每个应用中至少包含一个.hap文件，可能包含若干个.hsp文件、也可能不含，一个应用中的所有.hap与.hsp文件合在一起称为Bundle，其对应的bundleName是应用的唯一标识。
- 补充：bundleName与package：在HarmonyOS中，每个HAP或HSP都有一个bundleName，这是应用的唯一标识符。它确保手机上不能同时安装有两个bundleName相同的HAP。另一方面，package是每个HAP的包结构名称，用于定义代码中的类和资源的路径。同一个App下的所有HAP具有相同的bundleName，但它们的package名称不同。
当应用发布上架到应用市场时，需要将Bundle打包为一个 .app （我认为相当于安卓的.apk）后缀的文件用于上架，与此同时，DevEco Studio工具自动会生成一个pack.info文件。pack.info文件描述了App Pack中每个HAP和HSP的属性，包含APP中的bundleName和versionCode信息、以及Module中的name、type和abilities等信息。
说明：
- App Pack是发布上架到应用市场的基本单元，但是不能在设备上直接安装和运行。
- 在应用签名、云端分发、端侧安装时，都是以HAP/HSP为单位进行签名、分发和安装的。
编译发布与上架部署流程图
关于程序包的内容我在以后讲到进行打包上传到应用市场的时候会再详细说明。