鸿蒙HarmonyOS NEXT应用层架构

应用模型

FA模型中，每个应用组件独享一个ArkTS引擎实例，主要在鸿蒙双架构上使用

Stage模型中，多个应用组件共享同一个ArkTS引擎实例

在Stage模型中，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用。Stage模型作为主推的应用模型

应用程序包结构

一个应用通常包含一个或多个Module。Module是HarmonyOS应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行。

Module分为“Ability”和“Library”两种类型：
“Ability”类型的Module编译后生成HAP包。
“Library”类型的Module编译后生成HAR包。
HarmonyOS的应用以APP Pack形式发布，其包含一个或多个HAP包。HAP是HarmonyOS应用安装的基本单位，HAP可以分为Entry和Feature两种类型：

Entry类型的HAP：应用的主模块。在同一个应用中，同一设备类型只支持一个Entry类型的HAP，通常用于实现应用的入口界面、入口图标、主特性功能等。
Feature类型的HAP：应用的动态特性模块。Feature类型的HAP通常用于实现应用的特性功能，一个应用程序包可以包含一个或多个Feature类型的HAP，也可以不包含。

代码工程结构如下：
/application
├── common # 可选。公共能力层, 编译为HAR包或HSP包
├── features # 可选。基础特性层
│ ├── feature1 # 子功能1, 编译为HAR包或HSP包或Feature类型的HAP包
│ ├── feature2 # 子功能2, 编译为HAR包或HSP包或Feature类型的HAP包
│ └── …
└── products # 必选。产品定制层
├── wearable # 智能穿戴泛类目录, 编译为Entry类型的HAP包
├── default # 默认设备泛类目录, 编译为Entry类型的HAP包
└── …

分层架构设计

将应用划分为产品定制层、基础特性层和公共能力层，可以降低层间的依赖性，从而提升代码的可维护性。

逻辑模型

产品定制层的功能模块独立运作，同时依赖基础特性层和公共能力层来实现具体功能。
基础特性层位于公共能力层之上，用于存放基础特性集合。
公共功能层用于存放公共基础能力，集中了例如公共UI组件、数据管理、外部交互以及工具库等的共享功能。应用可以共享和调用这些公共能力。包括公共UI组件、数据管理、外部交互、工具库。

开发模型

从开发模型上可以了解到，Feature类型的HAP，而对于不需要通过Ability承载的功能，根据是否需要实现按需加载，可以选择设计为HAR模块或者HSP模块，编译后对应HAR包或者HSP包。通过对har和hsp的设计，满足组件化的开发，各业务线可以做到相互独立。

通过依赖关系，可以清晰的将业务开发拆分为组件化开发，直接依赖、间接依赖等，通过不同的依赖关系做到业务独立解耦。

部署模型

在部署模型中，每个Entry类型的HAP代表了应用的入口点，而Feature类型的HAP则包含了应用的特定功能模块。允许应用能够以模块化的方式适配和部署，从而满足不同设备和场景的需求。

也可以看到产物为app后缀，有不同的hap包构成，产物支持phone和2in1，在实际操作中我们知道app包是提交应用市场的包，测试和开发阶段只能使用hap后缀的包。

模块化设计

将应用分解为多个功能模块，其中每个模块负责执行特定的功能。提高了代码的可理解性和可复用性，同时降低了系统各部分之间的耦合度。

在HarmonyOS应用开发中，模块化不仅是一个设计原则，更是一种开发实践。它旨在将应用程序拆分为多个功能模块，每个功能模块负责特定的功能或特性。功能模块可以独立开发、编译和部署，也可以在不同的设备上灵活组合和调用。

在实际的业务考虑中以下几种情况：
共享模块：某个功能模块（业务模块或者能力模块）需要在多个应用之间共享其代码逻辑和资源。
按需加载模块：某个功能模块，使用时由用户决定安装时机，动态从应用市场下载安装使用。
多HAP/HSP引用相同HAR包的影响：从性能角度出发，需要减少多HAP/HSP对相同HAR包的引用。