鸿蒙:分层架构设计理解
·
一、背景
HarmonyOS 应用的分层架构设计基于一套代码工程,支持华为手机、PC/2in1等1+8全场景设备,实现了“一次开发,多端部署”的开发理念。梳理总结下对分层架构设计的更深入理解
二、分层架构设计是什么
鸿蒙的分层架构是三层解耦式架构,核心是“高内聚、低耦合、可复用”
代码示例参考:https://github.com/cheinlu/HarmonyOS-groundhog-charging-system/tree/master/TbsChargeHarmonyOs

common是公共能力层(存放全应用通用的工具、组件、配置等基础能力);feature是基础特性层(封装业务功能模块,如首页、我的等业务模块,);entry是产品定制层(应用主入口,整合功能并适配设备)
三、逻辑模型
分层架构逻辑模型图:

| 架构层级 | 核心功能 | 特点 | 组成部分 |
|---|---|---|---|
| 产品定制层 | 满足不同设备或使用场景的个性化需求,是应用的直接入口。 | UI与交互可灵活调整和扩展;模块独立运作,依赖基础特性层和公共能力层实现具体功能。 | UI设计、资源配置、特定场景的交互逻辑与功能特性。 |
| 基础特性层 | 提供相对独立的功能UI和业务逻辑实现。 | 高内聚、低耦合、可定制、模块化;支持产品的灵活部署。 | 各个独立的功能模块(如应用底部导航栏的每个选项)。 |
| 公共能力层 | 提供公共基础能力,供上层和应用调用。 | 稳定可靠、可复用、确保一致性和可维护性。 | 公共UI组件、数据管理、外部交互、工具库。 |
四、开发模型
分层架构开发模型图:

| 架构层级 | 编译产物与模块类型 | 依赖关系与设计目的 |
|---|---|---|
| 产品定制层 | 编译为 Entry类型的HAP,作为应用主入口。 | 面向多种设备,集成相应功能和特性。可根据不同设备的UX和功能需求,编译生成相同或不同的HAP,并打包成.app文件用于上架。 |
| 基础特性层 | 根据功能需要,编译为: 1. Feature类型的HAP (需Ability承载) 2. HAR包 (无需Ability,非按需加载) 3. HSP包 (无需Ability,需按需加载) |
功能模块化,以支持灵活的部署需求。根据功能是否需前端界面(Ability)或按需加载,选择不同的模块类型。 |
| 公共能力层 | 编译为 HAR包。 | 仅允许产品定制层和基础特性层依赖,不允许反向依赖。旨在提取公共基础能力,提供标准接口,提高复用率和开发效率。 |
五、部署模型

| 组件类型 | 部署角色与功能 | 部署机制与特点 |
|---|---|---|
| Entry类型的HAP | 代表应用的入口点。 | 与Feature HAP一同从.app包中解包,根据设备类型和场景分发部署到相应设备。 |
| Feature类型的HAP | 包含应用的特定功能模块。 | 实现模块化适配与部署,满足不同设备和场景的需求。 |
| HSP | 为HAP提供共享依赖。 | 跟随其依赖的HAP一同被分发和部署到相应设备。 |
六、单Entry集中式架构与分层架构差异
6.1、什么是单Entry集中式架构?
特点:仅通过一个Entry模块承载所有功能,业务逻辑、工具封装、UI组件等全部集中在Entry内,没有拆分出独立的基础特性层(如Feature HAP)或公共能力层(如HAR包),属于比较基础的“扁平式”代码组织方式,更适合小型、功能简单的鸿蒙项目。

6.2、两者区别
| 对比维度 | 单 Entry 集中式架构(无分层) | 鸿蒙分层架构(产品定制层 + 基础特性层 + 公共能力层) |
|---|---|---|
| 模块拆分 | 所有功能集中在一个 Entry 模块,无 HAR/Feature HAP 拆分 | 按职责拆分为 3 层,模块为可部署单元(Entry/Feature/HAR/HSP) |
| 依赖规则 | 无明确依赖约束,代码间直接引用 | 严格遵循 “上层依赖下层,禁止反向依赖”,依赖关系通过工具链强制管控 |
| 多端适配方式 | 靠代码内if-else判断设备类型实现适配 |
靠 “设备专属 Entry + 共享下层模块”,通过配置自动适配多端 |
| 代码复用性 | 组件、工具仅在 Entry 内部复用,无跨模块复用 | 公共能力层组件 / 工具跨层、跨模块复用,减少重复开发 |
| 团队协作效率 | 多人开发易冲突(都修改同一 Entry 代码) | 可按层 / 模块分工(如 A 做公共组件,B 做手机 UI),并行开发无冲突 |
| 维护与扩展成本 | 功能迭代后代码臃肿,改一处易影响全局 | 变更隔离(改 UI 不动业务逻辑),新增功能只需扩展对应层 / 模块 |
| 适用项目规模 | 小型工具类 App、1-2 人短期项目 | 中大型全场景 App、长期迭代项目、团队协作项目 |
更多推荐


所有评论(0)