鸿蒙NEXT开发【分层架构设计】应用架构

随着应用规模的扩大和业务需求的复杂化，代码的复杂度相应提升。因此，良好的应用架构设计变得尤为重要，架构设计的目的是让应用更易于维护、扩展和测试。

开发者在应用开发过程中，经常面临以下挑战：

• 代码组织混乱，模块间的耦合度高，导致一个模块的变动可能对其他模块产生影响，从而使代码难以维护。
• 应用的扩展性差，新功能的添加往往需要对现有代码进行大量的修改。

为了解决这些问题，开发者需要关注以下几个方面的架构设计：

• [分层架构设计]：将应用划分为产品定制层、基础特性层和公共能力层，可以降低层间的依赖性，从而提升代码的可维护性。通过分层架构设计进一步明确了每层的职责和层间的交互机制，为开发者呈现了一个清晰且结构化的开发框架。
• [模块化设计]：将应用分解为多个功能模块，其中每个模块负责执行特定的功能。通过模块化设计提高了代码的可理解性和可复用性，使应用的扩展和维护变得更为简便，同时降低了系统各部分之间的耦合度。
• [应用导航设计]：将应用划分为多功能模块后，通过Navigation导航设计，完成业务模块之间的解耦，实现不同业务模块之间的页面跳转交互。

HarmonyOS应用的分层架构设计以一套代码工程为基础，旨在为华为的手机、2in1等1+8全场景设备提供支持，实现了“[一次开发，多端部署]”的开发理念。

HarmonyOS应用的分层架构主要包括三个层次：产品定制层、基础特性层和公共能力层，为开发者构建了一个清晰、高效、可扩展的设计架构。

本文将从[逻辑模型]、[开发模型]和[部署模型]分别介绍应用分层架构设计规则。

逻辑模型

图1 分层架构逻辑模型

• 产品定制层

  产品定制层专注于满足不同设备或使用场景（如应用）的个性化需求，包括UI设计、资源和配置，以及针对特定场景的交互逻辑和功能特性。

  产品定制层的功能模块独立运作，同时依赖基础特性层和公共能力层来实现具体功能。

  作为应用的入口，产品定制层是用户直接互动的界面。为满足特定产品需求，产品定制层可灵活地调整和扩展，从而满足各种使用场景。

• 基础特性层

  基础特性层位于公共能力层之上，用于存放基础特性集合，例如相对独立的功能UI和业务逻辑实现。该层的每个功能模块都具有高内聚、低耦合、可定制的特点，以支持产品的灵活部署。

  基础特性层为上层的产品定制层提供稳健且丰富的基础功能支持，包括UI组件、基础服务等。同时依赖于下层的公共能力层为其提供通用功能和服务。

  为了增强系统的可扩展性和维护性，基础特性层将功能进行模块化处理。例如，一个应用的底部导航栏中的每个选项都可能是一个独立的业务模块。

• 公共能力层

  公共功能层用于存放公共基础能力，集中了例如公共UI组件、数据管理、外部交互以及工具库等的共享功能。应用可以共享和调用这些公共能力。

  公共能力层为上层的基础特性层和产品定制层提供稳定可靠的功能支持，确保整个应用的稳定性和可维护性。

  公共能力层包括但不限于以下组成：

  • 公共UI组件：这些组件被设计成通用且高度可复用的，确保在不同的应用程序模块间保持一致的用户体验。公共UI组件提供了标准化且友好的界面，帮助开发者快速实现常见的用户交互需求，例如提示、警告、加载状态显示等，从而提高开发效率和用户满意度。
  • 数据管理：负责应用程序中数据的存储和访问，包括应用数据、系统数据等，提供了统一的数据管理接口，简化数据的读写操作。通过集中式的数据管理方式不仅使得数据的维护更为简单，而且能够保证数据的一致性和安全性。
  • 外部交互：负责应用程序与外部系统的交互，包括网络请求、文件I/O、设备I/O等，提供统一的外部交互接口，简化应用程序与外部系统的交互。开发者可以更为方便地实现应用程序的网络通信、数据存储和硬件接入等功能，从而加速开发流程并保证程序的稳定性和性能。
  • 工具库：提供一系列常用工具函数和类，例如字符串处理、日期时间处理、加密解密、数据压缩解压等，帮助开发者提高效率和代码质量。

开发模型

图2 分层架构开发模型

• 产品定制层

  产品定制层的各个子目录会被编译成一个[Entry类型的HAP]，作为应用的主入口。该层主要针对跨多种设备，为各种设备形态集成相应的功能和特性。产品定制层被划分为多个功能模块，每个功能模块都针对特定的设备或使用场景设计，并根据具体的产品需求进行功能及交互的定制开发。

  说明

  • 在产品定制层，开发者可以从不同设备对应的应用UX设计和功能两个维度，结合具体的业务场景，选择一次编译生成[相同或者不同的HAP（或其组合）]。
  • 通过使用[定制多目标构建产物]的定制功能，可以将应用所对应的HAP编译成各自的.app文件，用于上架到应用市场。

• 基础特性层

  在基础特性层中，功能模块根据部署需求被分为两类。对于需要通过Ability承载的功能，可以设计为[Feature类型的HAP]，而对于不需要通过Ability承载的功能，根据是否需要实现按需加载，可以选择设计为[HAR]模块或者[HSP]模块，编译后对应HAR包或者HSP包。

• 公共能力层

  公共能力层的各子目录将被编译成HAR包，而他们只能被产品定制层和基础特性层所依赖，不允许存在反向依赖。该层旨在提取模块化公共基础能力，为上层提供标准接口和协议，从而提高整体的复用率和开发效率。

部署模型

图3 分层架构部署模型（不同设备的定制）

应用程序（.app文件）在流水线或应用市场上被解包为n * Entry类型的HAP + n * Feature类型的HAP，根据设备类型和使用场景将应用部署到不同类型的设备上，实现多端的统一用户体验。

说明

当Entry类型的HAP和Feature类型的HAP被分发并部署到相应的设备时，他们所依赖的HSP也会一同被分发并部署到相应的设备上。

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

该部署模型不仅优化了应用的组织结构，也为保持应用在各种设备和场景中的一致性提供了支持。通过按照设备类型和使用场景来区分和部署不同的HAP，能确保无论在何种设备或场景中，用户都能获得统一且高质量的体验。