鸿蒙应用开发实战【89】— 工程模块化feature模块拆分策略
鸿蒙应用开发实战【89】— 工程模块化feature模块拆分策略本文是「号码助手全栈开发系列」第 89 篇持续更新中…开源社区https://openharmonycrossplatform.csdn.net前言随着项目规模增长单模块的单体架构会让编译变慢、协作困难、代码耦合严重。HarmonyOS Stage 模型天然支持多模块架构通过合理的 module 拆分可以实现关注点分离、并行开发和按需加载。本篇涵盖多模块工程结构对比单体架构、HAR vs HSP 包类型选择、feature 模块拆分原则、entry 与 feature 职责划分、模块间通信方式router 依赖注入、实战目录结构设计。一、为什么需要模块化维度单体架构多模块架构推荐场景编译改动任何代码都全量编译只有改动的模块增量编译 10 页面耦合pages / common / data 混在一起按业务域隔离sms / data / theme 2 开发者团队协作大量冲突每人负责一个 feature 模块 3 人团队复用跨项目复制粘贴模块打成 HAR / HSP 直接引用多项目共享测试跑全部测试只跑改动的模块测试集成 CI/CD二、包类型HAR vs HSPHarmonyOS 提供两种模块包类型特性HAR静态共享包HSP动态共享包编译方式编译时打包到 HAP 内运行时按需加载包体积多模块使用会重复打包唯一实例节省体积安装随主 HAP 一起安装可在 HAP 外独立安装版本管理统一版本可独立升级导出exports 暴露export 暴露适用工具库、theme、utils大型 feature、动态插件项目现状当前使用单 entry 模块 目录分层模式这是中小型项目的最优解。当项目规模增长到 10 页面时可迁移到多 module 架构。三、feature 模块拆分原则3.1 拆分粒度按业务域拆分 → 每个 feature 模块对应一个「子产品」号码助手可能的 module 拆分App ├── entry # 主入口Ability 路由配置 │ ├── pages/ # 页面组件路由分发层不包含业务逻辑 │ └── EntryAbility.ets ├── feature-home # 首页模块统计卡片 应用列表 FAB ├── feature-card # 卡号管理CRUD 详情页 ├── feature-app # 应用管理绑定/换绑/注销 ├── feature-data # 数据模块导入/导出/备份/搜索 ├── common-ui # UI 组件库AvatarBadge / StatusBadge ├── common-theme # 设计令牌颜色/字体/动画/尺寸 ├──>3.2 依赖方向模块依赖必须单向UI → Feature → Dataentry → feature-home / feature-card / feature-app / feature-data ↓ common-ui / common-theme ↓ >四、build-profile.json5 配置4.1 多 module 注册// 根目录 build-profile.json5 { modules: [ { name: entry, srcPath: ./entry }, { name: feature-home, srcPath: ./feature-home }, { name: feature-card, srcPath: ./feature-card }, { name: feature-app, srcPath: ./feature-app }, { name: feature-data, srcPath: ./feature-data }, { name: common-ui, srcPath: ./common-ui }, { name: common-theme, srcPath: ./common-theme }, { name: data-api, srcPath: ./data-api }, { name: data-impl, srcPath: ./data-impl } ] }4.2 HAR 模块的 oh-package.json5//>4.3 主模块中引用 HAR// entry/oh-package.json5 { dependencies: { number-assistant/feature-home: file:../feature-home, number-assistant/feature-card: file:../feature-card, number-assistant/feature-app: file:../feature-app, number-assistant/feature-data: file:../feature-data, number-assistant/common-ui: file:../common-ui, number-assistant/common-theme: file:../common-theme, number-assistant/data-api: file:../data-api, number-assistant/data-impl: file:../data-impl } }五、模块间通信5.1 Router页面跳转import{router}fromkit.ArkUI// entry 模块中统一管理路由router.pushUrl({url:bundle:com.fiona.numberassistant/feature-card/pages/CardDetailPage})5.2 依赖注入通过>//>exportinterfaceCardRepository{findById(id:number):PromiseCardEntity|nullsave(card:PartialCardEntity):PromisenumberdeleteById(id:number):Promisevoid}//>import{CardRepository}fromnumber-assistant/data-apiimport{CardDao}from../../features/data/CardDaoexportclassCardRepositoryImplimplementsCardRepository{asyncfindById(id:number):PromiseCardEntity|null{returnCardDao.findById(id)}// ...}5.3 AppStorage / LocalStorage 跨模块状态// entry 中初始化AppStorage.SetOrCreatestring(currentCardId,)// 任何 feature 模块中读取constcardIdAppStorage.Getstring(currentCardId)六、当前项目目录结构分析号码助手在当前阶段采用目录分层作为模块化的轻量替代ets/ ├── EntryAbility.ets # 入口 ├── common/ │ ├── components/ # 共享组件AppListItem / AvatarBadge / StatusBadge │ ├── theme/ # 设计令牌AppColors / AppFonts / AppAnimations / Size │ └── utils/ # 工具类DisplayUtils ├── features/ │ ├── data/ # 数据层DatabaseService / CardDao / AppBindingDao / SmsCandidateDao / Models │ └── sms/ # 短信解析SmsParser └── pages/ # 所有页面16 个页面按功能命名优势小项目无需额外配置导入路径短。何时拆分当pages/超过 20 个文件、编译时间 2 分钟、需要团队并行开发时。小结原则说明包类型工具库用 HAR大型 feature 用 HSP拆分粒度按业务域拆home / card / app / data依赖方向UI → Feature → Data禁止逆向通信方式router 页面跳转 AppStorage 状态共享 接口注入起步策略小项目用目录分层大项目迁移多 module如果这篇文章对你有帮助欢迎点赞、收藏⭐、关注你的支持是我持续创作的动力相关资源开源鸿蒙跨平台社区https://openharmonycrossplatform.csdn.netHarmonyOS 多模块开发指南https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/multi-moduleHarmonyOS 官方文档https://developer.huawei.com/consumer/cn/doc/HarmonyOS hilog文档https://developer.huawei.com/consumer/cn/doc/harmonyos-references/hilogHarmonyOS testinghttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/unit-test