一、应用程序包
一个应用所对应的软件包文件，称为"应用程序包"。
应用程序（.app文件）在流水线或应用市场上被解包为n * Entry类型的HAP + n * Feature类型的HAP，根据设备类型和使用场景将应用/元服务部署到不同类型的设备上，实现多端的统一用户体验。
1、多Module机制
-
支持模块化开发：在开发过程中，我们可以将每个功能模块作为一个独立的Module进行开发。
-
支持多设备适配：一个应用往往需要适配多种设备类型，每个Module都会标注所支持的设备类型。在应用市场分发应用包时，根据设备类型将不同的包合理的组合和部署到对应的设备上。
2、整体架构
- 产品定制层
作为应用/元服务的入口，产品定制层是用户直接互动的界面。产品定制层的各个子目录会被编译成一个Entry类型的HAP。
- 基础特性层
存放相对独立的功能UI和业务逻辑实现。该层的每个功能模块都具有高内聚、低耦合、可定制的特点。对于需要单独应用组件的功能模块，会被编译成Feature类型的HAP。而对于不需要单独应用组件的功能模块，则会被编译成HSP或者HAR包。
- 公共能力层
公共功能层用于存放公共基础能力，集中了例如公共UI组件、数据管理、外部交互以及工具库等的共享功能。将会被编译成HSP或者HAR包。
二、Module类型
分为Ability类型（生成entry和feature的hap）和Library类型（生成hsp和har）
1、Ability类型
编译后会生成一个以.hap为后缀的文件，HAP包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或多个HAP包，具体包含如下两种类型。
-
entry类型的Module：应用的主模块，包含应用的入口界面、入口图标和主功能特性，每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个entry类型的HAP。
-
feature类型的Module：应用的动态特性模块，编译后生成feature类型的HAP。一个应用中可以包含一个或多个feature类型的HAP，也可以不包含。
2、Library类型
用于实现代码和资源的共享，不能单独运行。分为Static和Shared两种类型，编译后会生成共享包。
-
Static Library：静态共享库。编译后会生成一个以.har为后缀的文件，即静态共享包HAR（Harmony Archive）。
-
Shared Library：动态共享库。编译后会生成一个以.hsp为后缀的文件，即动态共享包HSP（Harmony Shared Package）。
HAR与HSP的主要区别：
-
HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。
-
HSP中的代码和资源运行时在一个进程中代码也只会存在一份。
发布和引用：
-
HAR支持应用内引用，还可以独立打包发布，供其他应用引用。
-
HSP随应用进行打包，当前支持应用内和集成态HSP。
3、编译态包结构
4、发布包结构
每个应用中至少包含一个.hap文件，可能不含或包含若干个.hsp文件。一个应用中的所有.hap与.hsp文件合在一起称为Bundle。将Bundle打包为一个.app后缀的文件用于上架，这个.app文件称为App Pack（Application Package）。
三、HAP、HSP、HAR
1、HAP
1.1 基本概念
HAP（Harmony Ability Package）是应用安装和运行的基本单元。
-
HAP包是由代码、资源、第三方库、配置文件等打包生成的模块包，其主要分为两种类型：entry和feature。
-
应用程序包可以只包含一个基础的entry包，可包含0或多个功能性的feature包。
1.2 使用场景
-
单HAP场景：如果只包含UIAbility组件，无需使用ExtensionAbility组件，优先采用单HAP。
-
多HAP场景：如果需要使用ExtensionAbility组件，可以采用多HAP（即一个entry包+多个feature包）来实现应用开发。
2、HAR
2.1 基本概念
HAR（Harmony Archive）包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码，可以被其他应用应用。
2.2 限制条件
-
HAR不支持在设备上单独安装/运行，只能作为应用模块的依赖项被引用。
-
HAR不支持在配置文件中声明pages页面，但是可以包含pages页面，并通过命名路由的方式进行跳转。
-
多包（HAP/HSP）引用相同的HAR时，会造成多包间代码和资源的重复拷贝，从而导致应用包膨大。还会存在HAR包中的单例失效的问题。
-
HAR可以依赖其他HAR，但不支持循环依赖，也不支持依赖传递。
-
由于HSP仅支持应用内共享，如果HAR依赖了HSP，则该HAR文件仅支持应用内共享，不支持发布到二方仓或三方仓供其他应用使用，否则会导致编译失败。
3、HSP
3.1 基本概念
HSP（Harmony Shared Package）动态共享包，可以包含代码、C++库、资源和配置文件，通过HSP可以实现应用内的代码和资源的共享。
3.2 使用场景
-
多个HAP/HSP共用的代码和资源放在同一个HSP中，可以提高代码、资源的可重用性和可维护性，同时编译打包时也只保留一份HSP代码和资源，能够有效控制应用包大小。
-
HSP在运行时按需加载，有助于提升应用性能
3.3 约束条件
-
HSP只能被该应用内部其他HAP/HSP使用，需跟随其宿主应用的APP包一起发布，与该宿主应用具有相同的包名和生命周期。
-
HSP不支持在设备上单独安装/运行,不支持在配置文件中声明UIAbility组件与ExtensionAbility组件。
-
HSP可以依赖其他HAR或HSP，但不支持循环依赖，也不支持依赖传递。
4、HAP、HAR、HSP使用场景
四、应用模块化设计
1、多任务设计
安卓使用习惯是一个App对应一个任务窗口。鸿蒙提供了多任务窗口的设计：每个任务对应一个UIAbility组件实例，并且每个任务可以单独显示一个窗口。用户可以在同个应用不同任务间切换。
使用场景：
-
笔记应用：可让用户将信息从笔记的一页复制到另一页。
-
购物类临时客服界面：可让用户通过任务管理快速从商品浏览页切换回到客服会话界面。
2、模块设计选型
-
共享模块：某个功能模块需在多个app共享。一般编译为har包通过公司私有ohpm仓进行发布和集成。
-
按需加载：动态在应用市场下载安装对应的功能模块。可将该模块设计为Feature类型的hap或者hsp，区别是hap可以包含Ability组件。
-
性能角度：减少多hap/hsp对相同har包的引用。
3、模块设计方案
3.1 单Hap工程
不需要按需加载
可以全部采用HAR进行开发设计。
包含按需加载模块：
方案一：为了最小化App Size，可以将公共依赖模块通过HSP模块壳承载，避免har_C和har_D依赖多份。
方案二：因为公共HSP包需要安装和加载，所以会有一些性能损耗。HSP直接依赖公共的har_C和har_D，启动更快，包size会变大。
3.2 多Hap工程
方案一：feature1和feature2的hap同时引用各种har包，包大小会有影响。
方案二：将公共har包封装到hsp中，然后feature1和feature2去直接引用hsp，多了hsp的依赖壳，对模块加载时长会有影响。