鸿蒙PC和App：都在走向 System

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

一个很有意思的现象：

PC 软件 → 移动 App → 鸿蒙应用

看起来是三代完全不同的形态，但底层却在发生同一件事：

架构正在从“页面 / 窗口驱动”，走向“System 驱动”

很多人以为这是鸿蒙才有的变化，其实不是。

这是整个软件世界的演化方向

一、第一阶段：PC 时代 —— 窗口驱动

在传统 PC 应用中（Win32、早期 GUI 框架）：

核心结构是：

窗口（Window） ↓ 事件（点击 / 输入） ↓ 回调处理

典型代码：

onClick(){doSomething()}

特点：

逻辑写在事件里 状态散落各处 没有统一数据源

问题是：

复杂度一上来，代码就开始失控

二、第二阶段：移动 App —— 页面驱动

到了 iOS / Android 时代，结构变成：

页面（Page / ViewController） ↓ 生命周期（onCreate / onAppear） ↓ 业务逻辑

典型写法：

onAppear(){fetchData()}

相比 PC：

有了页面结构 有了生命周期 有了分层意识

但本质仍然是：

页面在驱动一切

问题依然存在：

状态分散 跨页面难同步 逻辑重复

三、第三阶段：前端演进

在 Web / 前端（React / Vue）中，出现了一个重要变化：

状态（State） 驱动 UI

你开始写：

setState({count:count+1})

UI 自动更新。

这一步很关键，因为它引入了：

状态驱动 UI

但仍然缺一块：

状态如何变化？

很多项目仍然是：

UI 里写逻辑

四、第四阶段：鸿蒙 —— System 驱动

在鸿蒙（尤其是 ArkUI）中，这条链终于补齐：

Store（状态） System（规则） UI（展示）

运行模式变成：

输入（用户 / AI） ↓ System（规则执行） ↓ Store（状态变化） ↓ UI 自动更新

这时候：

页面不再是核心，System 才是核心

五、为什么所有架构都在走向 System？

因为它解决了三个“历史问题”。

1、状态失控问题

PC / App 时代：

状态散落在各个页面 / 控件

System 架构：

Store = 唯一状态源

结果：

状态统一

2、逻辑耦合问题

传统：

UI 写逻辑 逻辑绑定页面

System：

逻辑集中在 System UI 只触发

结果：

逻辑解耦

3、扩展困难问题

传统：

新增功能 → 修改多个页面

System：

新增功能 → 新增 System

结果：

可扩展

六、一个本质变化：从“界面系统”到“状态系统”

你可以这样理解整个演进：

旧世界

UI 是核心

新世界

状态是核心

一句话总结：

界面只是“结果”，状态才是“本体”

七、为什么鸿蒙更适合这种架构？

因为 ArkUI 天生具备：

声明式 UI 状态驱动更新 多端统一模型

这意味着：

UI 可以完全“无逻辑” System 可以完全“纯逻辑”

八、多端统一的关键原因

在 PC / App 时代：

多端 = 多套实现

而在鸿蒙：

多端 = 同一个 Store + 多个 UI

所以：

System 架构天然支持多设备一致性

九、AI 的加入，加速了这一趋势

当你引入 AI：

推荐 决策 自动操作

你会发现：

AI 不可能写在 UI

它只能放在：

System

这进一步强化了：

System = 核心层

十、开发者为什么会“卡住”？

因为很多人还停留在：

页面思维

表现为：

逻辑写在 UI 状态写在组件 System 不存在

所以一旦复杂：

直接崩

十一、一个终极认知

当你走完整个演进路径，你会发现：

你写的已经不是：

PC 程序 App 页面

而是：

一个“状态驱动的规则系统”

系统运行的本质是：

输入 ↓ System ↓ Store ↓ UI

总结

从 PC 到 App，再到鸿蒙，本质是一条清晰的演化路径：

窗口驱动 → 页面驱动 → System 驱动

最终统一为：

Store：状态源 System：规则层 UI：展示层

如果用一句话总结：

软件的发展方向，不是“页面越来越多”，而是“规则越来越集中”。