三层解耦之后，鸿蒙 App 的真正瓶颈

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- 第一层变化：复杂度从"代码"转移到"流程"
- 第二层本质：系统开始同时运行"很多件事"
- [第三层症状：Bug 开始变得"无法复现"](#第三层症状：Bug 开始变得“无法复现”)
- 第四层突破口：必须引入"任务视角"
- - 最小任务模型示例
- 第五层工程意义：为什么这是新的瓶颈
- 第六层现实：为什么很多项目停在这里
- 总结

引言

当一个鸿蒙 App 终于完成三层解耦时，团队通常会迎来一段短暂的轻松期：

UI 改动不再牵动业务
状态开始稳定收敛
能力层也逐渐沉淀

很多人会在这个阶段产生一种错觉：

架构问题，好像已经解决了。

但项目只要继续往前走一段，你很快会再次遇到一种熟悉的不安：

功能之间开始互相等待
页面跳转越来越难梳理
异步流程变得难以预测
Bug 不再集中在某一层，而是"跨层游走"

这时候你才会意识到：

三层解耦解决的是"结构问题"，而不是"系统行为问题"。

而真正决定大型鸿蒙 App 上限的瓶颈，其实在更深一层------

任务级复杂度。

第一层变化：复杂度从"代码"转移到"流程"

三层没解耦时，问题是明显的：

代码耦合
依赖混乱
修改全局爆炸

而三层解耦之后，这些问题确实会明显下降。

但新的复杂度开始出现，而且更隐蔽：

代码变干净了，但流程变乱了。

例如一个看似简单的业务链路：

ts 复制代码

await login()
await loadProfile()
await fetchConfig()
enterHome()

从代码看非常清晰。

但在真实系统里，这条链路往往会被撕裂成：

冷启动触发
Token 失效重登
后台恢复再次拉取
多窗口重复初始化

于是你会看到：

同一件事，在系统不同角落被重复执行。

这就是任务复杂度开始浮现的信号。

第二层本质：系统开始同时运行"很多件事"

小型 App 的世界很简单：

同一时刻，只做一件事。

但大型鸿蒙 App 完全不同：

页面在加载
网络在重试
Ability 在切换
后台任务在恢复
多窗口状态在同步

也就是说：

系统真正的状态，不再是"某个 Store 的值"，而是"当前正在运行的所有任务集合"。

如果没有任务模型，你就只能依赖：

if 判断
标志位
临时状态

ts 复制代码

if (this.loading && !this.retrying && !this.restoring)

这种写法的本质是：

用布尔变量，去描述并发世界。

结果一定是------

迟早失控。

第三层症状：Bug 开始变得"无法复现"

这是进入任务复杂度阶段最典型的信号。

Bug 的描述会变成：

偶现白屏
偶现重复请求
偶现页面跳错
低概率卡死

但日志看起来却完全正常。

原因很简单：

问题不在某一行代码，而在多个任务的时序组合。

例如：

ts 复制代码

startLogin()
restoreSession()
fetchConfig()

三段逻辑都正确，但如果执行顺序变成：

restoreSession 完成
startLogin 覆盖状态
fetchConfig 使用旧 token

Bug 就诞生了。

这类问题有个共同特征：

单点排查永远找不到答案。

第四层突破口：必须引入"任务视角"

当系统复杂度上升到这里时，继续优化三层已经没有意义。

真正需要改变的是：

你看待 App 的方式。

从：

"有哪些页面、状态、接口"

转变为：

"系统里现在跑着哪些任务？"

这是一次非常关键的认知跃迁。

最小任务模型示例

ts 复制代码

interface Task {
  id: string
  type: string
  running: boolean
}

ts 复制代码

class TaskManager {
  private tasks = new Map<string, Task>()

  start(task: Task) {
    this.tasks.set(task.id, task)
  }

  finish(id: string) {
    this.tasks.delete(id)
  }

  isRunning(type: string) {
    return [...this.tasks.values()].some(t => t.type === type)
  }
}

有了这层之后，很多问题会突然变简单：

ts 复制代码

if (!taskManager.isRunning('login')) {
  startLogin()
}

这一步的意义不是代码优雅，而是：

系统第一次拥有了"行为层的可观测性"。

第五层工程意义：为什么这是新的瓶颈

因为一旦进入大型系统阶段：

决定稳定性的，不再是单点代码质量，而是任务之间的关系是否可控。

具体表现为三件事：

是否能避免重复执行

没有任务模型：

同一流程可能被触发 3 次。

有任务模型：

同类任务全局唯一。

是否能正确恢复

系统被杀、窗口重建后：

没任务模型 → 重新乱跑
有任务模型 → 按记录恢复

是否能真正调试系统

没有任务视角时：

日志是一堆碎片。

有任务视角时：

日志是一条完整时间线。

第六层现实：为什么很多项目停在这里

因为任务级架构有一个特点：

它不解决"眼前的问题"，却决定"未来还能不能继续演进"。

所以团队常见选择是：

继续堆 if
增加更多标志位
写更多补丁逻辑

短期看能活，长期一定崩。

总结

回头看大型鸿蒙 App 的演进路径，其实非常清晰：

第一阶段：

解决代码耦合 → 三层解耦

第二阶段：

解决系统失控 → 任务模型

而真正的分水岭就在这里：

跨不过任务复杂度，三层再干净也只是"看起来很美"。

因为大型系统的本质，从来不是：

"代码怎么组织"，

而是：

"系统在同一时间，到底在做什么"。