鸿蒙模块化
一、模块化设计理念
在大型软件工程中，模块化是将复杂系统拆解为功能模块，以提高可维护性和可拓展性。在 HarmonyOS 应用开发中，模块化将应用程序拆分为多个功能模块，功能模块可独立开发、编译和部署，也可在不同设备上灵活组合和调用。
二、应用程序包结构概念
在进行模块化设计时，需要考虑HarmonyOS的应用包结构选型，HarmonyOS的应用包结构是为了定义应用的组织方式，通过开发态、编译态、发布态阶段应用程序包的形态，了解到不同包类型对应的使用场景以及使用规则。
三、Ability 应用组件设计
-
根据业务设备及诉求选择和设计 Ability 组件。在多设备背景下，应用形态多样，如手机设备上的多任务应用和大屏设备上的多窗口应用。
-
单 Ability 情况下，可采用单 HAP（HarmonyOS Ability Package，是 HarmonyOS 应用的安装包，用于承载应用的 Ability 组件，可以理解为一个独立的功能单元或者应用模块，它包含了运行应用所需的代码、资源和配置信息等）承载 UIAbility；多 Ability 分两种情况，多窗口类型应用可将模块作为 Feature 类型的 HAP 承载 UIAbility 组件，拓展功能可通过 Feature 类型的 HAP 承载单独的 ExtensionAbility 组件。
四、应用模块化选型
-
共享模块：可将公共能力封装成 HAR（HarmonyOS ArkTS Library，是一种静态共享库，主要用于代码和资源的共享。它可以被多个应用或者模块引用，将公共的代码逻辑和资源整合在一起，方便开发团队在不同的项目中复用代码，减少重复开发的工作量）模块，发布到 OHPM 仓供多个应用使用或贡献给社区。
-
按需加载模块：对于用户月活低的特性可做成按需加载模块，减少包体积和系统资源，有利于架构演进。可设计为 Feature 类型的 HAP 或 HSP（HarmonyOS Shared Package，是一种动态共享库，用于实现按需加载功能模块。它在应用运行时可以根据用户的需求动态地加载相应的功能，使得应用在初始安装时体积更小，并且能够灵活地扩展功能），根据应用组件设计和业务需求选择。
-
多 HAP/HSP 引用相同 HAR 包的影响：会存在 HAR 包中的单例失效，影响应用冷启动性能。可将 HSP 包改成 HAR 包以缩短冷启动阶段耗时。
五、单 HAP 工程
-
不包含按需加载模块：可全部采用 HAR 进行开发设计，好处是节省 HSP 的安装和加载成本、可做类型推断和编译优化、代码工程架构简单。
-
包含按需加载模块：需考虑 App Size（应用大小）与启动性能的平衡，可将公共依赖模块封装在 HSP 模块壳中以优化 App Size，或直接依赖公共 HAR 包以优化性能。
六、多 HAP 工程
-
包含公共能力模块：需在 App Size 与启动性能之间做平衡，可采用性能优先模型（除产品组件中存在 HAP 包之外，其余均是 HAR 包）或 App Size 优先模型（将公共的 HAR 包封装到 HSP 工程中）。
-
不包含公共能力模块：可参考单 HAP 场景。
总之，应用开发者需根据自身技术架构选择适合的工程模块化模型，并根据业务和技术架构的演进而演进，在 HAP、HAR 和 HSP 三种类型中进行选择使用。