HarmonyOS 鸿蒙Next应用架构设计：组件化复用与模块化项目案例

问题背景

• 针对App产品存在多个客户端版本的情况下，同时开发多个App时，由于业务目标、用户群体可能存在差异，且需兼顾协同效率与质量稳定性，容易暴露出比单一App开发更复杂的问题
• 多产品App核心问题，本质是"个性需求与共性能力的平衡失控"：
  • 资源分散导致效率低，协同缺失导致体验乱，
  • 版本混乱导致风险高。
  • 无模块化架构设计，项目陷入"开发慢、改不动、问题多"的恶性循环。

安卓开发现状

1. 人力资源分配矛盾：

   • 若多个App并行开发，核心开发人员（如架构师、资深工程师）需同时跟进多个项目，精力被稀释，导致技术决策延迟、关键问题响应变慢。
   • 基层开发人员若按"1个App对应1个团队"划分，会出现"同一项基础功能（如图片上传、异常监控）3个团队各做一套"的情况，重复劳动率高达40%-60%，直接拉长整体开发周期。

2. 技术栈与规范难统一

   • 若多个App由不同团队开发，可能因"团队习惯"采用差异技术方案，导致后续跨App协作（如人员轮岗、问题排查）成本陡增
   • 即使预先制定规范，也可能因"赶进度"出现执行偏差（如命名规则、接口格式不统一），后期需额外投入人力做标准化整改

3. 共性能力重复开发，维护难度翻倍：

   • 多个App必然存在共性能力（如登录、支付、网络请求、数据埋点），若未提前抽象复用，会导致：
     • 同一功能出现多套代码，修复一个共性Bug（如登录接口超时逻辑）需在3多个App中分别修改，漏改概率增加
     • 共性能力升级（如支付渠道新增）需多个团队同步适配，协调成本随App数量呈指数级增长

4. 版本规划与测试压力陡增

   • 多个App的版本迭代节奏可能不同（如A App需每月一更，B App每两周一更，C App紧急上线），测试资源（如测试设备、自动化脚本）需在3个项目间频繁切换，导致测试覆盖率下降，漏测风险升高。
   • 若多个App依赖同一基础组件（如自研的网络库），该组件升级后，需多个App同步完成兼容性测试才能发布，任何一个App的测试延迟都会拖慢整体进度。

5. 线上问题连锁反应

   • 若共性能力（如埋点SDK）存在隐藏Bug，可能导致多个App同时出现数据异常，线上故障排查时需"多线并行定位"，定位时间比单一App问题长2-3倍。
   • 某一个App的紧急发布（如修复崩溃Bug）可能因"打包环境共享""配置文件混淆"影响其他App的发布包稳定性（如误打包旧版本代码）。

6. 业务与扩展性：差异需求失控

   • 多个App的业务差异（如A App需社交功能，B App需电商功能，C App需工具功能）可能要求对共性能力做"定制化修改"（如登录模块为A App新增"第三方社交账号登录"，为B App新增"手机号一键登录"），若修改未抽象成可配置逻辑，会导致共性模块逐渐"臃肿"，最终失去复用价值

鸿蒙解决方案

• 整体架构设计思路：

备注：一个业务功能，即为一个工程（整个工程下的一个文件夹），编译出后是一个HAR/HSP类型的包。多个HAR/HSP组合打包出的包为HAP包。（HAR、HSP、HAP包区别参考：https://developer.huawei.com/consumer/cn/doc/architecture-guides/tools-v1_2-ts_35-0000002343405565）

在鸿蒙生态中，通过ArkTS语言和ArkUI框架的原生支持，可以高效实现"一套工程、多App发布"的架构。具体实现策略：

• 功能模块包模块化设计：可插拔组件化开发。由组件复用提供基础能力，例如：
  • 一键加油、爱车服务、无感支付、在线订单、高德、在线商城等业务功能，每个都由HAR/HSP工程创建，实现业务功能
  • 与业务无关的网络库、埋点SDK、图片加载等，每个都由HAR/HSP工程创建，实现基础功能。由业务功能HAR/HSP包调用，为业务功能提供基础能力
  • 上述业务功能HAR/HSP包，基础功能HAR/HSP包，可自由组合，被HAP工程引入，由HAP工程打包出用户版、商户版、供应商版三个版本
• 工程架构设计，组件复用，实现一套代码库支撑多App
  • 用户版HAP工程打包：创建hapTasks类型的工程（运行出的包为HAP包），将多个需要的多个业务功能包（HAR/HSP工程（文件夹））引入，编码实现用户版的功能。商户版、供应商版也是如此。
  • 用户版打包：需为车主提供便捷的车辆养护、维修、紧急救援等服务，引入一键加油、爱车服务、无感支付HAR/HSP，实现相关业务逻辑后，打包成HAP包
  • 商户版打包：需帮助维修店/4S店高效管理客户和服务流程，引入在线订单、高德HAR/HSP，实现相关业务逻辑后，打包成HAP包
  • 供应商版打包：为配件供应商提供B2B销售渠道和管理工具，引入在线商城、充值相关渠道配置HAR/HSP，实现相关业务逻辑后，打包成HAP包
• 如何打HAP包（多个app的差异化打包）：
  • 上述用户版、商户版、供应商版工程，每个工程需要配置：包名、签名、证书、打包输出的文件夹路径、相关资源（如主题资源、图片资源等）
  • 每个HAP的module.json中，bundleName、bundleType、versionCode、debug、minAPIVersion保持一致；module的name字段互不相同；minCompatibleVersionCode、targetAPIVersion保持一致
  • 配置后，通过执行Hvigor命令，打包成HAP包（Hvigor脚本参考：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/packing-tool#多工程打包指令）

• 解决痛点

1. 模块化设计，代码复用率提升：

   • 基础组件统一维护，避免重复开发（复用率可达70%-90%）。
   • 功能模块通过配置按需加载，无需为每个App单独编写代码，并且可以将可插拔的模块组合打包多个App。

2. 组件复用，开发效率提升：

   • 修改公共组件自动同步到所有App，减少重复测试和发布流程。
   • 新增功能只需在对应模块开发，通过配置快速集成到需要的App。

3. 维护成本降低：

   • 单一工程结构减少代码仓库管理复杂度，团队协作更高效。
   • 版本控制更简单，所有App基于同一代码基线演进。

4. 灵活扩展能力：

   • 新增App只需创建新的配置文件和专属资源，无需复制代码。
   • 功能模块可独立升级，不影响其他App。

• 组件设计思路：

• 组件复用，设计思路：

  1. 基础层组件：网络库、埋点SDK、图片加载等与业务无关联的，放入基础层，可供任何App提供底层能力
  2. 业务层：支付模块、订单、商品详情等，与业务强关联，需要考虑多个App版本的不同差异化能力、公共能力，进一步抽出
     • 例如可选复用的业务功能，作为多个App集成的公共业务
     • 差异化的使用动态Feature包由多个App灵活调用，并且可设计多个Feature包，可插拔给多个App组合使用
  3. 产品层：
     • 根据不同App版本，将公共资源统一管理、特定产品特定资源文件、代码中动态加载资源，封装在不同的App中
     • 每个App就固定使用这些资源、动态加载业务层的业务包，灵活配置不用App版本之间所需要的业务功能
  4. 基础层、业务层功能维护：
     • 每个基础能力、业务模块完全独立开发，无需关心是哪个App来调用，仅需关注本身能力、业务的迭代开发

• 基础组件案例

  • 案例1，验证码组件：

• 案例2，地址选择器组件：

• 核心能力：组件复用

总结

• 鸿蒙一多开发统一工程与模块化架构，解决人力资源分配矛盾与重复劳动问题。
• 依托标准化组件复用，确保共性能力集中维护，解决功能重复开发、维护难的问题。
• 组件化与配置化打包让测试聚焦差异点，缓解版本规划压力与测试资源冲突。
• 统一资源管理与编译脚本精准控制打包，降低线上问题连锁反应概率，保障多App发布稳定性。