目录
应用模型
应用模型是鸿蒙为开发者提供的应用程序所需能力的抽象提炼，它提供了应用程序必备的组件和运行机制。
有了应用模型，开发者可以基于一套统一的模型进行应用开发，使应用开发更简单、高效。
一、HarmonyOS应用模型的构成要素包括：
下面只列出了主要的要素，具体可以看原文章
应用组件
应用组件是应用的基本组成单位，是应用的运行入口。
用户启动、使用和退出应用过程中，应用组件会在不同的状态间切换，这些状态称为应用组件的生命周期。
应用组件提供生命周期的回调函数，开发者通过应用组件的生命周期回调感知应用的状态变化。
应用开发者在编写应用时，首先需要编写的就是应用组件，同时还需编写应用组件的生命周期回调函数，并在应用配置文件中配置相关信息。这样，操作系统在运行期间通过配置文件创建应用组件的实例，并调度它的生命周期回调函数，从而执行开发者的代码。
lxy：这里说的应用组件应该是entryAbility.
应用配置文件
应用配置文件中包含应用配置信息、应用组件信息、权限信息、开发者自定义信息等，这些信息在编译构建、分发和运行阶段分别提供给编译工具、应用市场和操作系统使用。
二、应用模型种类
鸿蒙的应用模型，随着系统的演进发展，鸿蒙先后提供了两种应用模型
FA（Feature Ability）模型： HarmonyOS API 7开始支持的模型，已经不再主推。
Stage模型： HarmonyOS API 9开始新增的模型，是目前主推且会长期演进的模型。
在该模型中，由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”，因此称这种应用模型为Stage模型。
Stage模型与FA模型最大的区别在于：
Stage模型中，多个应用组件共享同一个ArkTS引擎实例(运行ArkTS语言的虚拟机)。
FA模型中，每个应用组件独享一个ArkTS引擎实例。
因此在Stage模型中，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用。
还未理解：stage模型支持多设备和多窗口形态应用组件管理和窗口管理在架构层面解耦
包类型：HAP/HAR/HSP/APP
一、HAP
1、介绍
HAP（Harmony Ability Package）是应用安装和运行的基本单元。
HAP包是由代码、资源、第三方库、配置文件等打包生成的模块包，其主要分为两种类型：entry和feature。
entry：应用的主模块，作为应用的入口，提供了应用的基础功能。
feature：应用的动态特性模块，作为应用能力的扩展，可以根据用户的需求和设备类型进行选择性安装。
应用程序包可以只包含一个基础的entry包(目前大部分app采用的情形，比如大方和惠军生活) ，也可以包含一个基础的entry包和多个功能性的feature包。
2、使用场景
单HAP场景：如果只包含UIAbility组件，无需使用ExtensionAbility组件，优先采用单HAP（即一个entry包）来实现应用开发。虽然一个HAP中可以包含一个或多个UIAbility组件，为了避免不必要的资源加载，推荐采用“一个UIAbility+多个页面”的方式。
多HAP场景：如果应用的功能比较复杂，需要使用ExtensionAbility组件，可以采用多HAP（即一个entry包+多个feature包）来实现应用开发，每个HAP中包含一个UIAbility组件或者一个ExtensionAbility组件。在这种场景下，可能会存在多个HAP引用相同的库文件，导致重复打包的问题。
3、约束
不支持导出接口和ArkUI组件，给其他模块使用
4、我们看一个实际场景
编译Hap：
菜单栏Build - Build Hap(s)/App(s) - Build Hap(s)
查看编译产物：
在 ohos(项目根目录)/entry/build/default/outputs/default/entry-default-signed.hap 目录下可以找到编译产物
二、HAR
1、介绍
HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。
2、使用场景
作为二方库，发布到OHPM私仓，供公司内部其他应用使用。
作为三方库，发布到OHPM中心仓，供其他应用使用。
3、约束限制
HAR不支持在设备上单独安装/运行，只能作为应用模块的依赖项被引用。
HAR可以依赖其他HAR，但不支持循环依赖，也不支持依赖传递。
4、我们看一个实际场景
查看编译产物：
大方的har的编译产物在下面这个目录下(不确定是否是通用逻辑)：
ohos(项目根目录) - har - db.har
三、HSP
1、介绍
HSP（Harmony Shared Package）是动态共享包，可以包含代码、C++库、资源和配置文件，通过HSP可以实现代码和资源的共享。HSP不支持独立发布，而是跟随其宿主应用的APP包一起发布，与宿主应用同进程，具有相同的包名和生命周期。
2、使用场景
多个HAP/HSP共用的代码和资源放在同一个HSP中，可以提高代码、资源的可重用性和可维护性，同时编译打包时也只保留一份HSP代码和资源，能够有效控制应用包大小。
HSP在运行时按需加载，有助于提升应用性能。
同一个组织内部的多个应用之间，可以使用集成态HSP实现代码和资源的共享
3、约束限制
HSP不支持在设备上单独安装/运行，需要与依赖该HSP的HAP一起安装/运行。HSP的版本号必须与HAP版本号一致。
HSP不支持在配置文件中声明UIAbility组件与ExtensionAbility组件。
HSP可以依赖其他HAR或HSP，但不支持循环依赖，也不支持依赖传递。
四、APP
App是个上架概念，多个HAP打包一起上架。
编译App：
菜单栏Build - Build Hap(s)/App(s) - Build App(s)
查看编译产物：
ohos(项目根目录)/build/outputs/offline/offline.app
本质是压缩包
编译app完成后，在build目录下找到编译产物，修改为xx.zip ，解压后即可看到app的目录结构。
工程创建
工程创建流程参考原文章
行者常至，为者常成！