网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多团队第一次做鸿蒙大型项目时，都会遇到一个非常痛苦的问题：

编译越来越慢

刚开始：

点一下 Run
几秒钟启动

项目变大后：

改一行代码
重新编译几十秒

甚至：

一次构建几分钟

最后整个开发体验会变成：

写代码五分钟
等编译十分钟

很多人会以为：

这是鸿蒙工具链的问题。

其实不是，真正的问题通常是：

项目没有建立“增量构建架构”。

因为随着：

• 模块越来越多
• 状态越来越复杂
• AI 能力接入
• 多端适配
• 分布式能力增强

如果整个项目仍然：

全量编译

开发效率一定会越来越差，所以：

中大型鸿蒙项目，最终一定会走向“增量构建”。

一、什么是“增量构建”

一句话解释：

只重新构建“发生变化”的部分。

错误方式（全量构建）

改一个页面
整个项目重新编译

正确方式（增量构建）

改订单模块
只编译订单模块

核心目标

不是：

让编译更快

而是：

减少“不必要的构建”

二、为什么鸿蒙项目特别容易“编译爆炸”

因为很多项目天然会这样写：

所有模块互相引用

例如：

Page 引用 Store
Store 引用 System
System 引用 UI

最后：

形成巨大依赖网

一旦：

一个文件变化

整个项目：

全部失效重编译

这就是很多项目：

后期编译越来越慢

真正原因。

三、真正的问题：依赖边界失控

很多团队会觉得：

代码多 = 编译慢

其实不是，真正的问题是：

模块之间没有边界。

错误结构

任何模块都能互相 import

最后：

依赖树无限扩散

正确结构

领域隔离
模块独立

例如：

user/
order/
payment/
message/

每个领域：

• 独立 Store
• 独立 System
• 独立 Repository

这样：

改单模块
不会影响全局

四、鸿蒙增量构建最核心的原则

原则模块化，这是最重要的一步，推荐结构：

feature/
 ├── user
 ├── order
 ├── payment
 └── message

每个 feature：

独立编译

不要：

所有代码放一起

五、为什么“大一统工程”一定会越来越慢

很多项目早期喜欢：

一个工程写全部

例如：

pages/
utils/
api/
components/

看起来简单，但后面：

模块越来越耦合

最终：

任何改动都会触发全量构建

这是大型鸿蒙项目最典型的问题。

六、真正稳定的鸿蒙模块结构

推荐：

feature-order
feature-user
feature-payment
feature-message

每个 feature：

独立边界

内部：

ui/
store/
task/
system/
repository/

修改订单 UI

只影响：

feature-order

修改支付逻辑

只影响：

feature-payment

七、为什么“状态中心化”会影响构建速度

很多项目：

一个 GlobalStore 管所有状态

例如：

class GlobalStore {

  user
  order
  payment
  message

}

问题：

任何状态变化
都会影响整个依赖树

最终：

增量构建彻底失效

正确方式：领域 Store

例如：

userStore
orderStore
paymentStore

每个领域：

独立状态源

这样：

改单领域
不会波及全局

八、为什么“公共工具库”最容易毁掉增量构建

很多团队喜欢：

utils/

然后：

所有模块都依赖它

问题：

改一个工具函数
全项目重新编译

这是非常典型的问题。

正确做法

拆：

utils-time
utils-network
utils-format

避免：

超级公共库

因为：

公共依赖越大，增量能力越差。

九、ArkUI 为什么特别依赖“组件隔离”

很多页面会这样：

@Builder
buildAll() {

}

最后：

一个页面几千行

问题：

任何 UI 改动
整个页面重新分析

正确做法：

组件拆分：

OrderHeader
OrderList
OrderFooter

每个组件：

独立更新
独立编译

十、真正影响增量构建的，其实是“依赖方向”

错误结构：

UI 引用 System
System 又反向引用 UI

这种：

循环依赖

会导致：

整个依赖图失控

正确结构一定是单向依赖

推荐：

UI
 ↓
Store
 ↓
Task
 ↓
System
 ↓
Repository

核心：

绝不反向依赖

十一、AI 为什么会进一步放大构建问题

因为 AI Native 项目，通常：

模块更多
Task 更多
Runtime 更多

例如：

• Agent Runtime
• Prompt Engine
• Memory Store
• Task Scheduler
• Tool Runtime

如果没有：

模块隔离

后果：

一次改动
全项目重编译

开发效率会瞬间崩掉。

十二、真正成熟的鸿蒙项目，会建立“分层构建”

UI 层

变化最频繁：

高频增量

Store 层

中频变化：

领域增量

Runtime 层

低频变化：

稳定核心层

最终形成：

稳定核心
+
高频业务层

这才是：

真正适合长期演进的结构。

十三、为什么“Task 化”会天然提升增量构建

传统：

页面直接写流程

导致：

流程和 UI 强耦合

Task 架构：

流程独立

例如：

taskCenter.run("创建订单")

页面只负责：

展示状态

这样：

Task 改动
不会影响 UI 编译

十四、为什么“无状态 System”也能提升构建效率

很多项目：

System 持有大量状态

结果：

依赖不断扩散

正确：

System 无状态化

例如：

class OrderSystem {

  async create() {}

}

这样：

System 会非常稳定

构建缓存命中率会更高。

十五、真正优秀的鸿蒙项目，都有一个共同点

不是：

机器配置多高

而是：

依赖结构极其清晰

通常具备：

• Feature 模块化
• Store 分层
• Task 解耦
• 无状态 System
• 单向依赖
• Runtime 稳定层

这些东西：

决定了项目后期还能不能继续快速迭代。

十六、总结

如果用一句话总结：

增量构建，本质上是在“控制依赖扩散”。

很多项目编译慢，并不是因为：

代码太多

真正问题是：

所有东西都互相依赖

过去：

一个 App
像一团代码

未来：

一个 App
像多个独立运行的小系统

只有这样：

增量构建才真正成立

很多鸿蒙项目后期开发效率越来越低，并不是因为：

• ArkUI 太复杂
• AI 太重
• 分布式太难

真正的问题其实只有一个：

架构没有“构建边界”。

记住一句话：

真正优秀的鸿蒙工程，
一定是：

代码可拆分，
依赖可隔离，
构建可增量。

当你真正完成：

• Feature 化
• Store 分层
• Task 解耦
• Runtime 稳定化
• 单向依赖
• 无状态 System

你会明显感觉到：

整个鸿蒙项目的开发速度
突然快了很多