本节目标掌握大型 HarmonyOS 应用的模块拆分策略理解按业务域、按功能层、按团队边界三种拆分维度的适用场景掌握依赖治理的核心原则能够使用 ohpm 的 override、resolve_conflict 和依赖分析工具控制依赖数量与版本一致性掌握构建优化的关键配置能够通过增量编译、并行构建、HSP 共享和编译缓存缩短构建时间掌握团队协作规范包括代码分层约定、命名规范、提交规范和 Code Review 检查清单掌握多环境配置管理方案能够通过 product/flavor 机制管理开发、测试、生产环境的差异化配置掌握 CI/CD 流水线的搭建方法能够将编译、测试、性能门禁和签名打包集成到自动化流程能够为一个中大型应用设计可维护、可扩展、可协作的工程架构一、模块拆分策略1.1 按业务域拆分按业务域拆分是最直观的拆分方式每个业务域对应一个独立的模块。例如一个电商应用可以拆分为首页模块、商品模块、购物车模块、订单模块、个人中心模块等。每个业务模块内部高内聚包含该业务域的所有页面、组件、数据模型和业务逻辑。适用场景业务边界清晰、团队按业务线划分、需要独立开发和测试的大型应用。核心原则模块之间通过明确定义的接口通信尽量减少直接依赖。业务模块之间不应存在循环依赖可以通过依赖注入或事件总线解耦。1.2 按功能层拆分按功能层拆分是将应用按技术职责分为 UI 层、业务逻辑层、数据访问层和基础设施层。这种拆分方式与架构设计的分层模型一一对应。适用场景技术栈统一、需要严格控制分层边界、追求架构一致性的团队。核心原则上层依赖下层下层不感知上层。UI 层只负责展示和交互业务逻辑层负责规则编排数据访问层负责持久化与网络基础设施层提供通用工具和日志。1.3 按团队边界拆分按团队边界拆分是康威定律在软件架构中的直接体现——系统架构应与组织结构保持一致。每个团队负责的模块可以独立开发、独立测试、独立发布。适用场景多团队协作、需要并行开发、模块间接口稳定的大型项目。核心原则模块的所有权明确接口变更需要经过双方评审。每个模块有独立的负责人和 Code Review 流程。1.4 三种维度的组合使用实际项目中三种拆分维度通常组合使用。推荐的结构是先按业务域拆分为顶层模块每个业务域内部再按功能层拆分为子模块最后根据团队边界确定模块的归属和维护责任。entry/ # 主入口HAP ├── features/ │ ├── home/ # 首页业务域HAR │ │ ├── ui/ # UI 层 │ │ ├── viewmodel/ # 业务逻辑层 │ │ └── data/ # 数据访问层 │ ├── product/ # 商品业务域HAR │ ├── cart/ # 购物车业务域HAR │ └── order/ # 订单业务域HAR ├── commons/ │ ├── base/ # 基础工具HAR │ ├── network/ # 网络封装HAR │ ├── storage/ # 持久化封装HAR │ └── ui-components/ # 通用 UI 组件HAR └── shared/ └── constants/ # 全局常量HAR二、依赖治理2.1 依赖数量的控制依赖数量直接影响构建时间和包体积。每个第三方依赖都会增加编译时间、增大包体积、引入潜在的安全风险。建议遵循以下原则优先使用系统能力HarmonyOS 已经提供了丰富的系统 Kit如网络、存储、媒体、AI 等优先使用系统能力而非引入第三方库。评估依赖的必要性引入一个依赖前评估它是否真的必要是否可以用少量代码自行实现是否有更轻量的替代方案。定期清理无用依赖项目迭代过程中部分依赖可能已经不再使用。定期使用依赖分析工具扫描未使用的依赖并清理。2.2 依赖版本的统一多模块项目中最常见的问题是依赖版本不一致。模块 A 依赖了 lodash 1.0模块 B 依赖了 lodash 2.0打包时两个版本都会被包含导致包体积膨胀和潜在的运行时冲突。使用 ohpm 的override机制强制统一版本// oh-package.json5工程级 { overrides: { lodash: 2.0.0, axios: 1.6.0 } }开启resolve_conflict自动解决冲突// .ohpmrc { resolve_conflict: true }2.3 依赖分析工具使用ohpm list查看工程的依赖树识别重复依赖和版本冲突。使用 DevEco Studio 的 Build Analyzer 分析各依赖的体积占比识别体积大户。2.4 依赖分层的约束在大型项目中需要对依赖关系施加约束避免模块间随意引用导致的架构腐化。推荐使用以下约束业务模块不能反向依赖主入口features 层的模块不能依赖 entry 模块。业务模块之间禁止直接依赖features 层的模块之间如需通信通过 commons 层的接口或事件总线解耦。公共模块不能依赖业务模块commons 层的模块不能依赖 features 层的模块。三、构建优化3.1 增量编译与并行构建HarmonyOS 的模块化编译基于 ES Module 的 Bundleless 编译模式API 10 及以上版本的 Stage 模型工程默认开启。修改单个模块代码无需整包编译构建增量编译构建时间极大减少。hvigor 构建系统默认开启并行构建可以利用多核 CPU 加速构建。在hvigorfile.ts中可以调整并行度配置。3.2 编译缓存DevEco Studio 支持编译缓存将编译产物缓存到本地下次构建时复用。缓存生效的前提是源文件未变化。建议在 CI 环境中配置缓存目录加速重复构建。3.3 HSP 共享减少重复编译在多模块项目中将公共代码和资源抽取为 HSP消除 HAR 导致的重复拷贝。但需要注意大量使用 HSP 替代 HAR会在编译引用这些 HSP 共享包的模块时触发更多的语言编译任务导致编译耗时和编译内存占用增加。需要综合评估包体积收益和编译时间成本。3.4 构建配置优化在build-profile.json5中配置以下选项加速构建{ app: { products: [ { name: default, signingConfig: default, compatibleSdkVersion: 5.0.0(12), buildOption: { strictMode: { caseSensitiveCheck: true, useNormalizedOHMUrl: true } } } ] } }useNormalizedOHMUrl开启后可以优化依赖解析效率。四、团队协作规范4.1 代码分层约定明确各层的职责边界避免职责混淆页面层pages/views只负责 UI 展示和用户交互不包含业务逻辑。通过 ViewModel 获取数据通过事件回调触发业务操作。ViewModel 层viewmodel负责业务逻辑编排、状态管理、数据转换。不直接操作 UI不直接访问数据库或网络。数据层data负责持久化和网络请求提供统一的数据访问接口。不包含业务逻辑。工具层utils提供无状态的通用工具函数不依赖任何业务模块。4.2 命名规范文件命名页面文件以 Page 结尾如 HomePage.ets组件文件以组件名命名如 TodoItem.ets工具文件以功能命名如 DateUtil.ets模型文件以 Model 结尾如 TodoModel.ets。变量命名使用小驼峰如 userName常量使用全大写下划线分隔如 MAX_RETRY_COUNT类名使用大驼峰如 TodoViewModel。接口命名以 I 开头或使用描述性名称如 UserInfo、TodoRepository。4.3 提交规范推荐使用 Angular 提交规范格式为type(scope): subjecttype 类型feat新功能、fix修复、docs文档、style格式、refactor重构、perf性能、test测试、chore构建/工具。scope 范围模块名如 home、cart、network。subject 描述简洁的描述使用中文或英文不超过 50 个字符。示例feat(home): 添加待办搜索功能、fix(cart): 修复购物车数量计算错误。4.4 Code Review 检查清单每次提交前自查以下项目代码是否符合分层约定是否存在跨层调用是否有硬编码的字符串、颜色、尺寸是否处理了异常和边界情况是否使用了正确的状态管理装饰器是否有内存泄漏风险未释放的定时器、未取消的监听是否遵循了命名规范是否有必要的注释和文档五、多环境配置管理5.1 环境差异化的需求一个应用通常需要在开发、测试、生产三个环境中运行每个环境的 API 地址、日志级别、功能开关都不同。硬编码环境配置会导致每次切换环境都要修改代码容易出错。5.2 使用 product 机制在build-profile.json5中定义多个 product每个 product 对应一个环境{ app: { products: [ { name: develop, signingConfig: default, compatibleSdkVersion: 5.0.0(12), buildOption: { arkOptions: { buildProfileFields: { API_BASE_URL: https://dev-api.example.com, LOG_LEVEL: debug, ENABLE_MOCK: true } } } }, { name: release, signingConfig: release, compatibleSdkVersion: 5.0.0(12), buildOption: { arkOptions: { buildProfileFields: { API_BASE_URL: https://api.example.com, LOG_LEVEL: error, ENABLE_MOCK: false } } } } ] } }在代码中通过BuildProfile访问importBuildProfilefromBuildProfile;constAPI_BASE_URLBuildProfile.API_BASE_URL;constLOG_LEVELBuildProfile.LOG_LEVEL;constENABLE_MOCKBuildProfile.ENABLE_MOCK;5.3 配置文件的组织将环境相关的配置集中到一个文件通过 BuildProfile 注入不同值// commons/config/AppConfig.etsexportclassAppConfig{staticreadonlyapiBaseUrl:stringBuildProfile.API_BASE_URL;staticreadonlylogLevel:stringBuildProfile.LOG_LEVEL;staticreadonlyenableMock:booleanBuildProfile.ENABLE_MOCK;staticisDebug():boolean{returnAppConfig.logLeveldebug;}}六、CI/CD 流水线6.1 流水线的核心环节一个完整的 HarmonyOS 应用 CI/CD 流水线包含以下环节代码检查运行 Code Linter 静态检测检查代码规范和潜在问题。编译构建执行hvigorw assembleHap构建 HAP 包开启 Release 模式获取完整优化。单元测试运行 Hypium 单元测试输出测试报告。UI 测试在模拟器或真机上运行 UI 自动化测试。性能门禁使用 DevEco Testing 运行场景化性能测试对比性能基线低于基线则阻断合入。签名打包配置发布签名构建正式 HAP 包。上传分发将 HAP 包上传到 AppGallery Connect 或内部测试平台。6.2 流水线配置示例以下是一个基于 Jenkins 或 GitLab CI 的流水线配置示例stages:-lint-build-test-performance-packagelint:stage:lintscript:-hvigorw codeLinterbuild:stage:buildscript:-hvigorw assembleHap--mode module-p productdefaultunit_test:stage:testscript:-hvigorw test--mode module-p moduleentrydefaultperformance:stage:performancescript:-deveco-testing run--task performance--baseline baseline.jsonpackage:stage:packagescript:-hvigorw assembleApp--mode project-p productreleaseartifacts:paths:-build/outputs/default/*.hap6.3 性能门禁的集成性能门禁是防止性能退化的关键手段。设定性能基线如冷启动 ≤3000ms、页面切换 ≤1000ms、帧率 ≥60 帧每次代码合入前自动运行性能测试低于基线则阻断合入。DevEco Testing 的性能基线管理能力可以自动记录内存占用、CPU 负载等关键指标通过历史数据对比精准定位性能退化问题在性能退化早期发出预警。6.4 构建缓存与并行加速在 CI 环境中配置构建缓存和并行执行可以显著缩短流水线执行时间cache:paths:-.hvigor/cache/-node_modules/-oh_modules/build:stage:buildscript:-hvigorw assembleHap--parallel--daemon七、多元化习题习题 1判断题题目在模块拆分中业务模块之间可以直接相互依赖不需要通过公共模块解耦。答案错误解读业务模块之间禁止直接依赖如需通信应通过 commons 层的接口或事件总线解耦。直接依赖会导致模块间耦合度过高一个模块的修改会牵连其他模块破坏模块的独立性和可维护性。习题 2单选题题目以下哪种拆分维度是康威定律在软件架构中的直接体现A. 按业务域拆分B. 按功能层拆分C. 按团队边界拆分D. 按技术栈拆分答案C解读按团队边界拆分是康威定律在软件架构中的直接体现——系统架构应与组织结构保持一致。每个团队负责的模块可以独立开发、独立测试、独立发布。习题 3多选题题目关于多环境配置管理以下说法正确的有多选A. 使用 product 机制定义多个环境每个 product 对应一套配置B. 通过 BuildProfile 在代码中访问环境配置C. 环境配置应硬编码在代码中以便于管理D. 将环境相关的配置集中到 AppConfig 统一管理答案A、B、D解读使用 product 机制定义多个环境每个 product 对应一套配置选项 A 正确。通过 BuildProfile 在代码中访问环境配置选项 B 正确。环境配置不应硬编码在代码中硬编码会导致每次切换环境都要修改代码容易出错选项 C 错误。将环境相关的配置集中到 AppConfig 统一管理选项 D 正确。习题 4代码填空题题目请补全以下build-profile.json5配置使用override机制强制统一 lodash 的版本为 2.0.0。// oh-package.json5工程级 { ______________: { lodash: 2.0.0 } }答案overrides解读overrides用于强制统一依赖版本。当多个模块依赖同一库的不同版本时使用overrides指定统一使用的版本号避免多版本重复打包导致的包体积膨胀和潜在运行时冲突。习题 5代码改错题题目以下代码存在架构分层问题请指出问题并修正。// features/home/ui/HomePage.etsimport{RdbHelper}from../../../commons/storage/RdbHelper;EntryComponentstruct HomePage{Statetodos:Todo[][];aboutToAppear():void{// 页面层直接访问数据层this.todosRdbHelper.queryAll();}build(){List(){ForEach(this.todos,(todo:Todo){ListItem(){Text(todo.title)}})}}}答案页面层直接访问数据层违反了分层约定。页面层应通过 ViewModel 获取数据不直接操作数据库。修正方案// features/home/ui/HomePage.etsimport{TodoViewModel}from../viewmodel/TodoViewModel;EntryComponentV2struct HomePage{LocalviewModel:TodoViewModelnewTodoViewModel();aboutToAppear():void{this.viewModel.loadTodos();}build(){List(){ForEach(this.viewModel.todos,(todo:Todo){ListItem(){Text(todo.title)}})}}}解读分层架构的核心价值在于职责分离。页面层只负责 UI 展示和用户交互业务逻辑由 ViewModel 层处理数据访问由数据层处理。页面层直接访问数据层会导致职责混淆难以维护和测试。习题 6简答题题目简述大型 HarmonyOS 应用模块拆分的三种维度以及各自的适用场景。答案三种拆分维度包括按业务域拆分每个业务域对应一个独立的模块适用于业务边界清晰、团队按业务线划分的大型应用。按功能层拆分将应用按技术职责分为 UI 层、业务逻辑层、数据访问层和基础设施层适用于技术栈统一、需要严格控制分层边界的团队。按团队边界拆分是康威定律在软件架构中的直接体现每个团队负责的模块可以独立开发、独立测试、独立发布适用于多团队协作、需要并行开发的大型项目。实际项目中三种维度通常组合使用先按业务域拆分为顶层模块每个业务域内部再按功能层拆分为子模块最后根据团队边界确定模块的归属和维护责任。解读模块拆分的核心目标是高内聚低耦合。拆分不是越细越好过度拆分会导致模块数量膨胀、接口复杂度上升、维护成本增加。拆分应基于业务边界、技术边界和团队边界找到合适的平衡点。习题 7简答题题目简述 HarmonyOS 应用 CI/CD 流水线的核心环节以及性能门禁在其中的作用。答案CI/CD 流水线的核心环节包括代码检查运行 Code Linter 静态检测、编译构建执行 hvigorw assembleHap 构建 HAP 包、单元测试运行 Hypium 测试、UI 测试在模拟器或真机上运行 UI 自动化测试、性能门禁运行场景化性能测试对比性能基线、签名打包配置发布签名构建正式 HAP 包、上传分发将 HAP 包上传到 AppGallery Connect 或内部测试平台。性能门禁的作用是防止性能退化设定性能基线如冷启动 ≤3000ms、页面切换 ≤1000ms、帧率 ≥60 帧每次代码合入前自动运行性能测试低于基线则阻断合入。DevEco Testing 的性能基线管理能力可以自动记录内存占用、CPU 负载等关键指标通过历史数据对比精准定位性能退化问题在性能退化早期发出预警。解读性能门禁是 CI/CD 流水线中防止性能退化的关键手段。没有性能门禁代码合入后性能可能悄悄退化等到用户反馈时已经影响大量用户。将性能测试自动化、常态化在性能退化早期就发现并修复问题。八、本节知识点总结模块拆分策略三种拆分维度按业务域拆分业务边界清晰、按功能层拆分技术栈统一、按团队边界拆分多团队协作。实际项目中三种维度组合使用先按业务域拆顶层内部再按功能层拆子模块最后按团队边界确定归属。依赖治理优先使用系统能力评估依赖必要性定期清理无用依赖。使用overrides强制统一版本开启resolve_conflict自动解决冲突。业务模块之间禁止直接依赖公共模块不能依赖业务模块。构建优化模块化编译默认开启增量编译hvigor 支持并行构建。配置构建缓存和useNormalizedOHMUrl优化构建效率。HSP 共享减少重复编译但需评估编译时间成本。团队协作规范代码分层约定明确各层职责页面层不包含业务逻辑ViewModel 层不操作 UI数据层不含业务逻辑。命名规范、提交规范Angular 格式、Code Review 检查清单保障代码质量。多环境配置管理使用 product 机制定义开发、测试、生产环境通过 BuildProfile 在代码中访问配置。环境配置集中到 AppConfig 统一管理避免硬编码。CI/CD 流水线核心环节代码检查、编译构建、单元测试、UI 测试、性能门禁、签名打包、上传分发。性能门禁设定性能基线低于基线则阻断合入防止性能退化。配置构建缓存和并行执行加速流水线。下节预告第11课将进入 ArkUI 应用的安全与合规进阶的学习涵盖数据加密与安全存储、网络安全传输、权限最小化、隐私合规检测以及应用加固方案。