在鸿蒙下最佳实践的三层架构（products、features、commons）与一多场景下，我们需要对 HAP HAR HSP 三种包概念了解清楚，以下是个人对 HAP HAR HSP 包的理解；
如何创建包
- 右键项目
- New > Module
- Empty Ability 通常创建 HSP （Ability类型的Module：entry 和 feature）
- Shared Library 创建 HSP（Library类型的Module）
- Static Library 创建 HAR（Library类型的Module）
他们的区别
Ability类型的Module
用于实现应用的功能和特性。每一个Ability类型的Module编译后，会生成一个以.hap为后缀的文件，我们称其为HAP（Harmony Ability Package）包。HAP包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或多个HAP包，具体包含如下两种类型。
- entry类型的Module：应用的主模块，包含应用的入口界面、入口图标和主功能特性，编译后生成entry类型的HAP。每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个entry类型的HAP。
- feature类型的Module：应用的动态特性模块，编译后生成feature类型的HAP。一个应用中可以包含一个或多个feature类型的HAP，也可以不包含。
我们可以直接根据当前模块是在 products 还是 features 层来定义它是 entry 还是 feature
Library类型的Module
用于实现代码和资源的共享。同一个Library类型的Module可以被其他的Module多次引用，合理地使用该类型的Module，能够降低开发和维护成本。Library类型的Module分为Static和Shared两种类型，编译后会生成共享包。
- Static Library：静态共享库。编译后会生成一个以.har为后缀的文件，即静态共享包HAR（Harmony Archive）。
- Shared Library：动态共享库。编译后会生成一个以.hsp为后缀的文件，即动态共享包HSP（Harmony Shared Package）。
HAR与HSP两种共享包的主要区别体现在:
如何选择 HAR 还是 HSP
首先 HAR 的缺点很明显，HAR的使用存在打包多份，包膨胀的问题，导致整体应用包的体积很大，HSP可以很好地解决该问题，本文介绍了HAR转HSP的步骤，主要是通过配置项的变更将HAR工程变成HSP工程。
如果有发布独立二三方的需求，可以创建 HAR 包：
HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。
使用场景 作为二方库，发布到OHPM私仓，供公司内部其他应用使用。 作为三方库，发布到OHPM中心仓，供其他应用使用。
除此以外，他还有一些其他约束限制：
- HAR不支持在设备上单独安装/运行，只能作为应用模块的依赖项被引用。
- HAR不支持在配置文件中声明UIAbility组件与ExtensionAbility组件。
- HAR不支持在配置文件中声明pages页面，但是可以包含pages页面，并通过命名路由的方式进行跳转。
- HAR不支持引用AppScope目录中的资源。在编译构建时，AppScope中的内容不会打包到HAR中，因此会导致HAR资源引用失败。
- HAR可以依赖其他HAR，但不支持循环依赖，也不支持依赖传递。
HAR不支持引用AppScope目录中的资源
这导致了一个问题，如果我们在 commons 层里的有一个包里实现了一些基础 UI，那么它将无法访问到 AppScope 下的一些color声明，这个使用我们有 2 种方案：
- 创建一个单独的 HAR，专门放置一些 resource 和 声明，其他 features 引入这个 HAR
- commons 层里的有一个包里实现了一些基础 UI 使用 HSP developer.huawei.com/consumer/cn…
